STM32H7 unexpected fluctuations of a constant float / double variable

[LMICH.3]

Hello,

I am currently having a problem with a float / double variable, involved in a Timer interrupt, within a Nucleo H743ZI2 MB1364E.

Considering the variable ‘double test_fluctuation_variable’, declared at the very top of the main.c, this variable is updated (and hold constant) inside a timer function as:

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

{

test_fluctuation_variable = (double) 2.0;

…

}

Depending on the initialization value of this variable, two cases are observed in the debug mode:

* In the case ‘double test_fluctuation_variable = 0’, the variable unexpectedly fluctuates: see video ‘STM32H7_fluctuation_with_ZeroInit’ of the debug mode attached;

* In the case ‘double test_fluctuation_variable = 0.1’, the variable remains stable to the expected assignation: see video ‘STM32H7_constant_with_Init’ of the debug mode attached.

It seems that the initialization value may create a different 'behaviour' of the variable even if it is set as constant; this variable is only used one time in this particular timer function. This problem also occurs if this variable is assigned in the main while(1) loop...

The following peripherals are running: FDCAN, RS232 and ADC.

The current software configuration is: 

• CubeIDE Version: 1.11.2 Build: 14494_20230119_0724 (UTC)
• STM32H743ZITx / STM32Cube FW_H7 V1.11.0
• MacOS Ventura 13.2 (22D49)

Thank you in advance

Best regards,

Loïc

[KnarfB]

Maybe a bug in Live Expressions? Can you observe the effect by other means like when debugging is paused or using STM32CubeMonitor?

hth

KnarfB

[LMICH.3]

Hello and thank you for the answer!
Indeed, I « discovered » this problem using STM32CubeMonitor, since it is my very favorite tool to investigate problems in my code. Hence, I suspected first a bug with STM32CubeMonitor and a friend of mine, very familiar with the debugger, helped me to investigate further…
Best,
Loïc

[KnarfB]

Interesting, I still believe that this is a Heisenbug caused by observation. Don't have your board at hand, but on a M4 the line

test_fluctuation_variable = (double) 2.0;

is compiled to a single str.d instruction (store doubleword), so there is no much room for failure here.

The code might indeed depend on the value of that constant.

If you strip down to a minimal example and permanently test for the correct value in the main loop, will that ever fail? Or output to UART or such.

Using the FPU in an IRQ handler might have issues, see here for Cortex-M4 https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/10-useful-tips-to-using-the-floating-point-unit-on-the-arm-cortex--m4-processor but I don't see the FPU used in your code snippet.

hth

KnarfB

[S.Ma]

The SWD Debug interface can steal one bus cycle to read 32 bit aligned chunk.

double is 64 bits, so 2 bus probes times apart will be done.

There is no "latch" to lock the second half of th 64 bit data to read.

If this data is updated or corrupted by the SW, the watch or monitor value will be glitchy.

First, make sure that any interrupt that WRITES this variable wraps it with an interrupt saved and disabled, modify, restore interrupt level.

Second, either you copy your double to a float for monitoring with less granularity (32 bit), or you complexify the implementation by cloning regularly the value and set a flag, then the monitor read the value if the flag is set, then clears it.

Last millenium was 16 bit value for 8 bit microcontroller, Next century will be 128 bit value for 64 bit cores ?