Global variable overlaps with stack.

[BigBrick]

Hi.

I am absolute noob with stm32 and i am currently trying to connect GY-GPS6MV2 module to RobotDyn STM32 Mini(STM32F103C8T6).  I have connected GPS module to pins and set up USART1 in asyncronous mode. I have done everethyng according to official example on how to work with USART1 using DMA. In the interrupt handler i wrote small piece of code to copy data from rx buffer to linked list. But from here things have gone really weird, because in the debugger i see, that my global variable(nmea_head, this is first node in linked list) is allocated in the same memory area where irq handler stack resides(See attached screenshots). What am i doing wrong?

Here you can see, that SP for HAL_UART_RxCpltCallback is at 0x20000104

This is definition of global variable nmea_head. On the right side you can see, that it was placed on the address 0x20000110. This address overlaps with stack frame of HAL_UART_RxCpltCallback, so my variable gets corrupted. What am i doing wrong?

This  happens prior to any calls to malloc or free, and i am not accessing this variable from anywhere else, so there should not be any race conditions.

[BigBrick]

I checked memory with STM32CubeProgrammer

0x20005000 is correct value for _estack and 0x080006f9 is address of ResetHandler

So this should mean, that chip should start directly at Reset_Handler without any prior bootloader and msp/sp values should be 0x20005000, right? Because when i break at reset handler i see something different:

[BigBrick]

I ckecked memory during after reset:

This is why i have invalid SP/MSP. But where does this value come from?

[KnarfB · Accepted solution]

Looks like the MCU is booting from system memory. The next address (initial PC) is in the System Memory Area (0x1FFFF000-...) with the internal boot loader. Maybe such a little stack space is okay for that boot loader.

The board should have a BOOT0 pin/jumper that must be set to low for booting your code from user flash area (0x08000000-...)

Whats written in the project linker script file (.ld)?

[Andrei Chichak]

There's a few more conflicting things, being a self-professed noob and using malloc and free and linked lists on a processor with 20K of RAM.

Start at the start, get an LED to blink, then work up to getting anything going with the UART in polled mode, then move on. You have to get your mind around new tools, concepts, and flying without a net. If you're worrying about what is getting loaded into the SP at startup, you're doing it wrong.

The NMEA strings are not of a known length, so doing DMA or interrupts that fire on a particular length are going to mess you up since you don't know what the length is.

But for a self-professed noob to be diving directly into the deep end, with all of the bells and whistles in use, is just asking for a disappointing time.

[BigBrick]

Thank you, setting BOOT0 jumper to low fixed it.