Know list of issues with STM32CubeIDE in release code after power-loss reboot

[Robmar]

..

[Robmar]

Is there a know list of issues with STM32CubeIDE in release code after power-loss reboot?

Our app is getting NaN's in the float's processing after reboot from power-down (**CCM memory is used for the floats), we've been through the code looking for the usual unitialised variables, but would be useful to know if there are any issues or things to do following a power fail.

We are locking an unlocking the RTC RAM STM32F407V on Discovery, and not seeing any RAM corruption.

We're using CMSIS DSP, this is were the issue seems to be, in this or the floating point support.

A hard reset always resolves the loss of float math. It works for a few second after power-fail reboot, but then we get NaN's occuring. Hard to debug as we can't see how to reconnect the debugger as is possible in other IDEs.

[Bob S]

For CubeIDE v1.7 (I don't have the newer version handy) and STLink, to create a debug config that will connect to a running system:

• Open the project
• From the "Run" menu select "Debug Configurations"
• In the left pane expand "STM32 Cortex-M C/C++ Application" if not already expanded.
• Right-click on your existing debug configuration and select "Duplicate"
• Click on the new config to start editing it
• In the "Main" tab, update the name to something meaningful (I put "resume" at the end of the name). Set "Built" to "Disable auto build" (this presumes the source and ELF files match what is running).
• In the "Debugger" tab, change the "reset behavior" to "none". And in the "Misc" section un-check "Verify flash download" (optional, I think, see next step)
• In the "Startup" tab, in the "Load Image and Symbols" section, double-click the (one) line to edit it. Uncheck the "download" box. Hit "OK". Then uncheck the "set breakpoint at" and "resume" boxes.
• Click on "Apply" to save all these changes.

You should be able to use this debug profile to connect to the running system. It MAY connect and halt the CPU, but it does not change the execution address. So you can click on "run" and the CPU will continue where it left off.

If you are using the JLink debugger, the steps are similar, but the fields in the "Debugger" tab are slightly different. But similar enough you should be able to figure them out.

[Robmar]

Thanks Bob, that's a big help, worked immediately!

[Pavel A.]

Hi,

There is no such thing as power-loss reboot in STM32F4. You can get either a reset caused by brownout detector, or caused by watchdog, or caused by sleep/low power transition when it is disabled. Or a hardware (NRST pin) or software reset.

Otherwise there's only one power-on reset.

You can tell the reason of the last reset by bits in a special PWR register at the next start.

If some external memory makes troubles, maybe it does not receive enough power when the MCU starts too early. In this case wait until the voltage reaches the level needed by the external chip. Only then initialize it.

[Robmar]

haha I mean when the user pulls the plug, sort of causes a sudden power-loss.

On powering back up the app works for 6 seconds approx., then get NaN errors on CMSIS IIR filter calls, I have verified the block size and State arrays match, input data is good, weird.

If the board is them reset manually or programatically it recovers.

Maybe I have an unitialised variable, can't find one but otherwise what could cause this???

[Robmar]

Does CCM have any special restrictions or conditions?

The float variables that get corrupted after a power-down then later power-up in our app are in CCM memory for faster access.

Using compiler optimisation for max speed the code that restores corrupted floats fails (in debug everything works unfortunately!), but if we compile for O3 "Most optimised", it does restore the corrupted variables and begins working again. But why would that be, random memory differences, an unitialised variable affected by the compile options???

Float processing fails a few seconds after power-up from a power-fail. But a reset while up and running restores everything perfectly.

Using CMSIS DSP filter functions, the State variables are cleared during initialisation. What's confuses is how this works in debug, works after a reset, but not from power-up.

[Pavel A.]

Ah so there's no external memory. Well. Life is short and there's too many strange things.

If your code works well after reboot: detect the reset reason as mentioned above; if it was a pure power-on reset then do software restart (call NVIC_SystemReset).

[Robmar]

Yes, one day the reason will become clear... for now the hack seems to solve it, but I don't much like hacks​

[waclawek.jan]

If you are working on 'F407, it has a discontinuous memory (SRAM1+SRAM2, and CCMRAM are separated). Maybe you expect variables in some of the memories to be zeroed after reset, while the startup code zeros/initializes only one of the two areas.

JW

[Robmar]

All variables are cleared, or should be, but its a very large program, hopefully I'll find why this happens. Worth clearing all areas though as a test

[Robmar]

I now have "optimize for speed/Ofast" working by disabling strict aliasing. Strange that strict aliasing works in "optimize most" but not in Ofast, theoretically it should apply equally to both optimisation models, no?

[FLeon.4]

After a power-loss reboot in STM32CubeIDE, there isn't a known list of specific issues. However, it's important to ensure proper initialization of variables, including floats, and review compatibility with CMSIS DSP library. Unexpected behavior in floating-point processing or data corruption could occur due to an undefined state after a power loss. Debugging can be challenging, but adding debug statements or using logging techniques may help trace the issue.