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

[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]

So I added a memcpy call at the start of main() to clear all the CCMRAM to 0 and the problem is gone as long as I compile with "optimise most", and not for speed!

What's curious is that compiling for maximum speed (O3) causes the float failures to appear... very weird, a bug in CMSIS V.1.4.5 ? I did try to upgrade CMSIS but there were so many errors due to changes and I haven't the time to modify so much code.

[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?

[Tesla DeLorean]

Check startup.s make sure it's clearing all the regions as expect. ST's GNU/GCC implementation in incredibly sloppy. Tools like Keil and IAR have table driven initialization of statics that the linker builds for them.

I seem to recall CCMRAM having a clock on the F4, also not DMA accessible

[NEdom.1]

As far as I know, CCM has only one limitation: DOES NOT support DMA.

If you are to use “O3" compiling option, be careful with the optimized code's behavior. In "O3" mode, some variables may be accessed directly from register rather than the memory. If you are using an RTOS and the data is accessed by multi-task, you should be careful when using "O3".

[Robmar]

Thanks, I'll take a look at that. Disabling strict aliasing on the release build has allowed the Ofast optimization to work, I suppose some sort of issue in our code could cause memory pointer issues that might affect pointer aliasing, but then why would alias work in O3 most optimized mode?

[Robmar]

I compiled in debug with O3fast optimization and to my surprise, after a build clear, then compile, it allows me to debug.

In O3 optimize everything works as expected, but in O3fast, where its been failing in release, a parameter input into a routine is being inexplicably change:-

**** O3fast optimisation: sampleRateDecim passed in == 12000
 
a_buffer passed in is in CCM RAM, this is it´s structure definition:-
 
typedef  float32_t audio_block_t[AUDIO_BLOCK_SIZE];
 
typedef struct
{
    // Stereo buffers
    iq_buffer_t     iq_buf;
    float32_t       agc_valbuf[IQ_BLOCK_SIZE];
 
    audio_block_t   a_buffer[2];
 
    demod_sam_param_t sam;
    iq_correction_data_t iq_corr;
} AudioDriverBuffer;
 
AudioDriverBuffer section (".ccm") adb;
 
 
static void DemodPostprocessing(float32_t (*a_buffer)[AUDIO_BLOCK_SIZE], const size_t blockSize, const size_t blockSizeDecim, const uint32_t sampleRateDecim)
{
    const uint8_t  dspActive = ts.dsp.active;
    const uint8_t dmodMode = ts.dmodMode;
 
    if (!dsp.inhibit)	// dsp.inhibit == 0
    {
        if ((dspActive & DNOTCH_ENABLE) && (dmodMode != DEMOD_CW) && !((dmodMode == DEMOD_SAM) && (sampleRateDecim == 24000)))
        {
            *** Note: not called as sampleRateDecim == 24000 is false
			NotchFilter(blockSizeDecim, a_buffer[0]);     // Do notch filter
        }
    }
 
    *** FAIL: sampleRateDecim no longer == 12000 !!!

[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.