Debug code falsely seeing memory as 0 until I break in the debugger

[Robmar]

Schrodinger's Memory: In debug my STM32F407VG Discovery code is seeing zeros in an array loaded using DMA (which is working), but if I break and single step, the code suddenly see's the values. Super weird! I´m using STM32CubeIDE which was fully updated 2 days ago.

int16_t in[32]; // Buffer which receives samples from the ADC via DMA (good data values arrive)

int16_t inC[32];

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)

{

uint32_t iC = 0;

// This code runs in debug with >0 values in in[0] and the loop doesn´t break. If I add a break point

// and single step it breaks out immediately. I rebooted but it stays the same.

// If I remove the 0 loop, it runs and sometimes the buffer has zeros but mostly good values.

// HAL_ADC_ErrorCallback() is not called.

while(in[0] == 0) {

iC++; } // Wait for data to appear. Shouldn't be needed.

memcpy((void*)inC, (const void*)in, sizeof(inC)); // Copy to processing buffer

}

[Robmar]

This is one of the weirdest things I've seen, the debug code is reading memory array values as all zeros until I single step, then it works.

[TDK]

Memory is not updated during execution. It is updated when you pause/break. (True but not the issue here.)

Define "in" as volatile if it can be modified outside of the process (e.g. with DMA). This forces the compiler to read the memory each time it is accessed. Otherwise the compiler can simplify your loop and only check the value once.

volatile int16_t in[32];

When single stepping, the value is updated by DMA before you check it for the first time. When running, it is not yet updated and the loop continues forever.

[Robmar]

The code was failing to get the memory for the zero test, please look at the code.

It was stuck in the test loop I wrote.

Only when I added a breakpoint at that point while running did it exit the loop because then it was able to get the correct values.

I already experimented with volatile, had no affect.