Carving out HardFault error storage location in high RAM via linker script

[CharlieMangold]

STM32CubeIDE Version: 1.12 & STM32G0B0RE

We have had a HardFault error in the field and wanted to use an old technique of storing the info in RAM until after the micro is reset and more stable and then move it into flash. We used the STM32G0B0RETX_FLASH.ld file and modified two spots:

/* Memories definition */
MEMORY
{
  RAM    (xrw)    	: ORIGIN = 0x20000000, LENGTH = 143K
  RAM_FOR_FAULT (rw)	: ORIGIN = 0x20023C00, LENGTH = 1K
  FLASH   (rx)    	: ORIGIN = 0x08000000, LENGTH = 502K
...
}
and
  .faultData :
{
	. = ALIGN(4);
	__faultData_start__ = .;
	*faultData.o (.text .text*)
	__faultData_end__ = .;
	. = ALIGN(4); */
} > RAM_FOR_FAULT /* new RAM for hard faults */

ASSERT( LENGTH(RAM_FOR_FAULT) >= (__faultData_end__ - __faultData_start__), "faultData overflowed !")

Cube's IDE show the sections seems to work:

But once the debugger is loaded there seems to be a lot of random data around the 0x20033C00 memory spot:

Could the stack still be using the chips high RAM address or is there something else we need to do to isolate the highest 1K of RAM?

Thanks...

[CharlieMangold]

If we stop at the beginning of main() and step into the first functions call, it appears to load data onto the stack at about address 0x20023BDC and then start using lower RAM addresses:

So the stack appears to start correctly from main. Is there a difference between a power up condition and a reset where a power up may use those high RAM addresses?

[CharlieMangold]

So at the Reset handler, the stack pointer shows 0x20023C00.

If I fill in random data and run till I hit main(), the random data is still present.

Do power up conditions use the highest RAM addresses? If it only happens on a power up(and Not on a reset), this would work fine for a HardFault problem.

[Tesla DeLorean]

How is data magically going to get into this RAM from the linker?

You'll note that the other RAM content is staged in FLASH, and moved to RAM, and RAM cleared for .BSS by code managing that task in startup.s as it runs from Reset_Handler.

[Tesla DeLorean]

The RAM is volatile. The MCU doesn't clear it at power up, it will be whatever random content the state of the transistor cell happen to be in.

[BarryWhit]

> Do power up conditions use the highest RAM addresses? 

> Is there a difference between a power up condition and a reset where a power up may use those high RAM

> addresses?

Isn't the difference simply that RAM contents are not preserved if you cycle power? due to physics, the contents will randomly decay over time once power is removed. Can you see a difference between a rapid power cycle and a slow one (you need time for the capacitors to discharge, of course).

Or am I misunderstanding your question?

[CharlieMangold]

This is true, but if the linker has worked correctly and high RAM addresses are never used, there should only be random data up there. I've never seen random data look like like the RAM high addresses I'm seeing in the debugger. It is either the Segger debugger or something to do with a power up vs debugger reset difference.

[CharlieMangold]

As I understand the ST G series micro, the RAM should not degrade during a software reset. So if you have a Hardfault, save the data in a unused RAM location and then software reset the micro, the information will be there when you hit main. We have used this technique before but have never done it in a ST micro.

[BarryWhit]

> As I understand the ST G series micro, the RAM should not degrade during a software reset. 

which you tests have confirmed.

> I've never seen random data look like like the RAM high addresses I'm seeing in the debugger.

Which screenshot are your referring to that is unconvincing to you? 

An easy test would be to avoid using the debugger, and just dump that memory over UART upon reset.