STM32F750Z Unaligned memory access when executing from external RAM.

[Sgrml.1]

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 :

• setting up an mpu region for the entire external RAM
• resetting UNALIGN_TRP in the ccr register
• swwapped memory mapping in fmc (SYSCFG->SWP_FMC)
• added compiler flag -mno-unaligned-access

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

[Tesla DeLorean]

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

[Sgrml.1]

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

[Tesla DeLorean]

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

[Sgrml.1]

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