stm32 C Global Variables do not have their initialized values

[Nabs]

Was working on an EVAL board stm32G474RE which has FLASH of 512K and RAM of 128K. Everything was working fine on the EVAL board. Now we received the actual hardware which is a stm32g474CBU. Very similar to the EVAL board but the FLASH 128K and RAM of 128K.

Very few changes were required for the new micro like the linker file. But started noticing a strange behavior where some of the global variables that were initialized in the code, did not have their values. As in the moment the program is downloaded and I hit the breakpoint in the main function, the values for the global variables are not there and just 0xFFs.

It appears that the values of the global variables were not even copied from the flash to the .data section of the memory.

text      data    bss       dec      hex

59416 11528  26768   97712 17db0

Any ideas. As I mentioned before, the code works perfectly on the EVAL board which has pretty much the same micro.

[TDK]

Initialization of global variables is done in the startup_*.s file.

If you have messed with linker settings, including assigning variables to different linker sections, this can break the initialization.

Note that linker scripts and startup scripts are typically chip-specific. They may be different even if your C code is the same.

You can also set a hardware watchpoint to break when a specific memory value changes. If you do this for one board, you can understand where precisely that variable gets initialized and use that to understand why it isn't happening for the other board.

[Nabs]

The linker script file that I am using was generated from the CubeMX. I did not change any setting. 

As a test I compiled code with the same linker script and startup code... and ran it on the EVAL board, and it worked fine. Only when I run it on the actual hardware, does the code fail. The startup and linker script file for both the micro are exactly the same. The only difference is that in the linker scrip file for thbe EVAL board the flash size is set to 512K and the actual hardware (stm32474cbu) has the linker script file wheere the FLASH size is set to 128K

 

[Tesla DeLorean]

Then you'll need to debug this as part of your bring-up task.

The code in startup.s should use symbols generated via the linker script to scope the size of the initialization data staged in FLASH, and zero out the BSS memory

See >RAM >AT FLASH directives.

Review the .MAP, unpack / disassemble the .ELF

Debug from ResetHandler, ie uncheck "run to main()" type options, and walk the code in.

Linker file isn't presented, so don't know if that's broken or not. Type are processed in a linear fashion, and they are deceptively complex and awkward.

[Pavel A.]

@Nabs Can you rebuild and test the EVB firmware with link script of the actual (128K) MCU?

 

[Roger SHIVELY]

Hello @Nabs ,

There has been a case created to resolve this question and we will be reaching out to you directly.

Regards,
Roger

[Nabs]

Ok guys so we have this figured out. 

So basically we had a hardware problem, where the debugger header on the board had pin 8 and pin 10 shorted. 

What we noticed was that when I tried the program the STM32, it only programmed the first bank of the FLASH which was 64K. My code is less than that. But after flashing the code, it then proceeds to flash .data section (which is all the global variables that have been initialized. In my case it was around 11K. So it only flashed whatever it can on the firs bank and then did not flash the second bank. 

Now when I ran the code, it would run fine except the moment the code tried to access any global variables that should have been flashed on the second bank, was all empty and the whole thing crashed. 

Once pin 8 was disconnected from pin 10 (which was the reset line), then it just started working and the second bank was also being flashed properly. I am not sure why pin 8 was causing this issue to us but the matter is resolved :)