2024-03-07 12:45 AM
STM32F765II uses dual bank mode for firmware upgrade, setting nDBANK=0 and nDBOOT=0,BOOT_ADDR0=0x2000(0x08000000), use ST-LINK Utility。
In bare core, my code running correctly. update the firmware in bank1 and bank2 all successfully.
When add FreeRTOS 10.2.1 use CubeMX, my code failed in prvStartFirstTask function "svc 0" instruction. when I change the nDBOOT to 1, freertos can correctly run.
I checked the SVC_Handler in startup_stm32f765xx.s and FreeRTOS's port.c , they are correct. In debug mode, svc 0 cause reset, but the breakpoint in SVC_Handler cann't reach.
I was wondering if it was an issue with the interrupt vector table. Referring to the description in AN2606, in dual boot mode, there should be no need to consider the issue with the interrupt vector table.
However, my problem looks like a problem with the interrupt. Has anyone encountered this problem before, thanks!
Solved! Go to Solution.
2024-05-07 03:43 AM
Hello @C-Robert
The behavior you're experiencing suggests that there might be a problem with the interrupt vector table or the way the interrupts are being handled when FreeRTOS is added to your application.
The following steps may prove helpful in resolving the issue:
Vector Table Offset: When using dual bank mode with FreeRTOS, ensure that the vector table is correctly set for the active bank. FreeRTOS will typically use the vector table located at the start of the bank where the application is loaded. You need to set the vector table offset register (VTOR) to point to the correct location.
SCB->VTOR = FLASH_BANK1_BASE | VECT_TAB_OFFSET; // Adjust as necessary for your application
Stack Alignment: FreeRTOS requires the stack to be 8-byte aligned. Check that the initial stack pointer for the tasks and the interrupt stack are correctly aligned.
Debugging: Use a debugger to step through the code and monitor the VTOR register before the svc 0 instruction is executed. Ensure that it points to the correct vector table for the active bank.
Clock Configuration: Double-check the clock configuration for both banks. An incorrect clock configuration can cause issues when starting FreeRTOS.
FreeRTOS Configuration: Review the FreeRTOSConfig.h file to ensure that the configuration is appropriate for your system, especially the definitions related to interrupts and stack sizes.
By carefully reviewing these areas, you should be able to pinpoint the cause of the issue. It's crucial to ensure that the vector table is correctly configured and that the SVC handler is set up to handle the svc 0 instruction without being preempted or blocked by other configurations.
2024-05-07 03:43 AM
Hello @C-Robert
The behavior you're experiencing suggests that there might be a problem with the interrupt vector table or the way the interrupts are being handled when FreeRTOS is added to your application.
The following steps may prove helpful in resolving the issue:
Vector Table Offset: When using dual bank mode with FreeRTOS, ensure that the vector table is correctly set for the active bank. FreeRTOS will typically use the vector table located at the start of the bank where the application is loaded. You need to set the vector table offset register (VTOR) to point to the correct location.
SCB->VTOR = FLASH_BANK1_BASE | VECT_TAB_OFFSET; // Adjust as necessary for your application
Stack Alignment: FreeRTOS requires the stack to be 8-byte aligned. Check that the initial stack pointer for the tasks and the interrupt stack are correctly aligned.
Debugging: Use a debugger to step through the code and monitor the VTOR register before the svc 0 instruction is executed. Ensure that it points to the correct vector table for the active bank.
Clock Configuration: Double-check the clock configuration for both banks. An incorrect clock configuration can cause issues when starting FreeRTOS.
FreeRTOS Configuration: Review the FreeRTOSConfig.h file to ensure that the configuration is appropriate for your system, especially the definitions related to interrupts and stack sizes.
By carefully reviewing these areas, you should be able to pinpoint the cause of the issue. It's crucial to ensure that the vector table is correctly configured and that the SVC handler is set up to handle the svc 0 instruction without being preempted or blocked by other configurations.
2024-09-13 07:06 AM
Guys, I'm just here to tell you how I solved this problem.
Basically, it was a problem related to VTOR (Vector Table Offset). When initializing the code, the value contained in VTOR was always 0x100000 (system memory bootloader address).
What I hadn't realized was that my SystemInit function (system_stm32f7xx.c file) wasn't making the following assignment:
SCB->VTOR = VECT_TAB_BASE_ADDRESS | VECT_TAB_OFFSET;
This was happening because USER_VECT_TAB_ADDRESS was not defined at the beginning of the file.
So, I just uncommented the line #define USER_VECT_TAB_ADDRESS and everything worked perfectly!
Here's the log to help anyone who needs it.