2020-10-02 02:20 AM
Hallo everyone,
I have set up Segger Ozone with a Segger J-Trace to initialize the uC. When connecting to the debuggee the clock configuration, the gpio config as well as the FMC configuration is done. After that OZone loads the programm to the external RAM, sets up SP an PC and the MPU for the region to allow code execution and then jumps to the Reset Handler.
All this is working with a bare programm toggleing a pin in the while(1).
When I try to integrate FreeRTOS I can do the basic init.
But in the SVHandler (vPortSVCHandler) I get an Unaligned memory access at the following position:
" ldmia r0!, {r4-r11, r14} \n" /* Pop the registers that are not automatically saved on exception entry and the critical nesting count. */
I striped this down to:
"ldr r0, [r4] \n"
"ldr r0, [r5] \n"
"ldr r0, [r6] \n"
"ldr r0, [r7] \n"
"ldr r0, [r8] \n"
"ldr r0, [r9] \n"
"ldr r0, [r10] \n"
"ldr r0, [r11] \n"
"ldr r0, [r14] \n"
The error occures on r14 (LR).
What I did so far was :
If I set the linker script to internal Flash the programm runs just fine.
The FreeRTOS code/port is generated with STM32CubeMX 5.6.0.
I appreciate any help, thank you.
Best regards
2020-10-02 05:59 AM
That doesn't look like remotely equivalent code.. that's you're real problem
The first example check the alignment of R0
The second example LR will be ODD because it's THUMB CODE
2020-10-04 09:20 AM
Hi Clive1,
thank you for your input. Yes I know ldmia is loading data from the address in r0 to the registers in the list while incrementing the address. What I wanted to show with this was, that I get an error when accessing LR. I will test this again with more appropriate code but what I was wondering about is why I get the unallined error when executing from external RAM but not from internal flash.
The things I listed under done so far should have solved this?
Do you have any ideas/hints where I can have a look?
Thanks
2020-10-04 09:37 AM
Not really got much confidence in the GNU/GCC inline assembler
Show a disassembly of what the CPU is actually executing, show the registers at the fault
Perhaps provide as a buildable demonstration
2020-10-10 03:18 AM
Hi Clive,
thanks for your response.
I solved the problem,it seems it was a combination of the fmc settings and the mpu.
When I switched the address region form 0xC0000000 to 0x60000000 without activating the mpu for this region the rtos is working fine.
I will stick with this configuration for now, but it is strange that this combination leeds to such a problem.
Regards and thnaks for the thought-provoking impulse