Either STM messed up big time or someone can't write datasheets properly. CCMSRAM is faulty.

[JBroo.1]

Why is the stack leaking into the CCMSRAM? First of all, the linker script provided for the G4 is just awful. It combined all three SRAM memories into one general location. Why? Thanks for the manual work I have to do to redefine them.

Second, CCMRAM is defined at 0x1000 0000 with an alias at 0x2000 5800. 10KB of CCM SRAM as specified in the datasheet.

If you allocate an array (int32_t var[8][320]) at 0x1000 0000 to fill up the entire 10KB and you write to all of it with a certain number, immediately after the upper locations are being over written with random garbage which I assume are coming from the main stack. [7][300] to [7][300] will contain random garbage.

Either the CCM SRAM is not 10KBytes like STM32 claims or there is a hardware issue which causes memory overlaps. The stack pointer (_estack) is defined at 0x20008000 which is at the end of the CCMRAM, yet it leaks backwards. (The code does nothing that would make the stack underflow either, it's an infinite loop that does nothing).

Anyone care to explain? I've never seen this before on previous STM chips.

[TDK]

_estack points to the END of the stack. The stack grows in size downward. Probably your stack is overflowing the space allocated to it and flows past the CCMRAM region. Not sure what you mean by stack "underflow". If your program does nothing, how is the stack leaking?

[JBroo.1]

My bad I was thinking of them the other way around. Yeah it overflows into CCMRAM without doing anything. There are no interrupts except SysTick. It's a fresh project, I am not using STM32CubeIDE, I am using the linker script that comes with the STM32CubeG4 files.

[TDK]

It sounds like your linker script might be allocating your int32_t[8][320] in such a way that it overlaps memory being used for the stack. Might help if you posted your linker modifications and how you've defined the array.

[S.Ma]

Add in your init to write a specific non zero value at the first and last memory entry of your array.

Go debug mode and place a breakpoint before starting main.

Open core registers and see the stack pointer value

Open memory view and see the stack begin and end

Also check your array first and last byte values are non zero.

Run manually few main loops and check again.

[Ozone]

Check the map file in this regard.

Many toolchains and RTOSs have a runtime stackcheck option. But you can do it basically yourself.

Just fill the whole stack with a specific pattern in the startup code, and check the area afterwards.

Polular patterns are 0xDDDD, 0xAAAA, 0x5555, 0xCAFE or 0xDEADBEEF...

[RMcCa]

Looks like its doing what its supposed to do. Your array fills up the entire segment which is shared with the stack, so the systick isr will over write some of your data at the end of segment. The max size of the array should be the segment size minus the min_stack_size as defined in the linker script.​