CM4F Assertion in port.c after update to V11.0.1

Kernel
21

I’ve narrowed it down a bit further. To me, it seems like one of the “dsb” calls clears the register. I’ve modified the code like this, disabling interrupt processing after sleeping:

vPortSuppressTicksAndSleep()
…
xModifiableIdleTime = xExpectedIdleTime;
configPRE_SLEEP_PROCESSING( xModifiableIdleTime );

        __asm volatile("mov %0, r7" : "=r" (test5257));
        if( xModifiableIdleTime > 0 )
        {
            __asm volatile ( "dsb" ::: "memory" );
            __asm volatile ( "wfi" );
            __asm volatile ( "isb" );
        }
        configPOST_SLEEP_PROCESSING( xExpectedIdleTime );
        
        //don't enable interrupt processing here, just to be sure...
        //__asm volatile ( "cpsie i" ::: "memory" ); <-----------------
        __asm volatile ("nop" ::: "memory");
        __asm volatile ( "dsb" );
        __asm volatile ( "isb" ); // <---------------------------------

        __asm volatile("mov %0, r7" : "=r" (test5258));

using this code, “test5258” contains the value “0” → cleared. When i patch the hex file and replace the last “isb” call with a 4 byte “nop”, the register contains the correct value.

At this point, I don’t think this is a FreeRTOS problem. I think I will post a question in the arm community forum…

22

Hi @mwagner,

Thanks for the detailed analysis.

Since the issue is related to r7 register and based on:

it makes wonder if frame pointer is at play here. Can you please check if you are using -fno-omit-frame-pointer compiler flag and somehow r7 is getting corrupted between function calls.

According to Optimize Options (Using the GNU Compiler Collection (GCC)), -fomit-frame-pointer is enabled by default at optimisation level O1 or higher.

23

we’re not using the -fno-omit-frame-pointer flag.

24

Probably a long shot, but there is an STM32 erratum “Wrong instruction fetches from flash memory upon wakeup from Sleep or Stop mode when debug in low-power mode is enabled” that I ran into a while back with symptoms just like yours. The MCU was executing wrong instructions in the first 8 machine instructions after waking from sleep. It might affect your MCU too. Which specific MCU are you using? Feel free to PM me.

25

Thanks, had a look at this. It’s for STM32F4xx, and noted “The issue affects only debug mode and has no effect on real applications.”. We’re using a STM32F302 and the problem also occurs without the debugger connected, so I would rule this out.

26

I’ve placed a post in the arm community forum: Cotex M4 + FreeRTOS -- CPU register cleared after wfi/sleep mode - Architectures and Processors forum - Support forums - Arm Community