cancel
Showing results for 
Search instead for 
Did you mean: 

Weird STMCubeIDE debug behavior - global structs showing up as all zeros but the code acts as it they are populated with data as they should be!

MStra.3
Associate III

I have a project on an STM32F4 that consists of a Bootloader and Main application. Both of these apps read an external Flash to retrieve configuration data. The Bootloader is looking to see if Main had previously uploaded new FW to the Flash and if so, it re-flashes the STM flash with the new application. It then modifies the flag in the external flash so we don't try to re-flash the STM flash again. At this point it then jumps to the Main application (whether it reflashed or not).

The issue is that the Config data read during the bootloader is shown in the debugger correctly, but once the application jumps to the Main application and it reads the configuration data again, it shows as all zeros in the debugger. However, the code executes as if the configuration data is correct (all zeros is not valid so it would normally set them to valid values but it doesn't execute that code indicating that they were valid).

Both of the Config structures end up in the same RAM location according to the debugger but in Main I can view that memory location and it is all zeros...

And ideas?

Mike.

1 ACCEPTED SOLUTION

Accepted Solutions
MStra.3
Associate III

So I figured this out. My Bootloader and Main used Global variables with the same name (they were both using a module for accessing non-volatile memory). The Debugger does not like that. The variables end up in different memory locations but the Debugger can't figure that out. I changed the variable names in the Bootloader and now it behaves as expected.

Mike.

View solution in original post

1 REPLY 1
MStra.3
Associate III

So I figured this out. My Bootloader and Main used Global variables with the same name (they were both using a module for accessing non-volatile memory). The Debugger does not like that. The variables end up in different memory locations but the Debugger can't figure that out. I changed the variable names in the Bootloader and now it behaves as expected.

Mike.