cancel
Showing results for 
Search instead for 
Did you mean: 

STM32G474 - using upper 16kB of CCM-SRAM breaks debugging

Albi G.
Senior

Hi guys,

I have a crazy curiosity at my hands. The STM32G474 is a "category 3" device, therefore it has 128kB of RAM with the upper 32kB being CCM-SRAM. It is really nice that it is all addressable in one continuous block.

When i use the upper 16kB of the CCM-SRAM my debugger (using OpenOCD) breaks. The program works, I can stop the programm, but i cannot resume after a debug break. I inevitably jump to the NMI-Error handler. So something must have gone wrong.

Strangely, I can circumvent this annoying debugging problem by adjusting the Linker-Script to:

MEMORY /* WORKING CONFIG */
{
/* used for ISR Vector table */
CCMRAM (xrw)	: ORIGIN = 0x20000000+96k+16k, LENGTH = 4K 	
/* used for Stack (will start in CCM-Ram) and heap */
RAM (xrw)      	: ORIGIN = 0x20000000, LENGTH = 96k+16k		
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 256K
}

(using just 16kb of the CCM-Ram)

However if the stack resides in the upper 16k of CCM-SCRAM by using, for example, 18kb of CCM-ram:

MEMORY /* BROKEN CONFIG */
{
/* used for ISR Vector table */
CCMRAM (xrw)	: ORIGIN = 0x20000000+96k+18k, LENGTH = 4K 	
/* used for Stack (will start in CCM-Ram) and heap */
RAM (xrw)      	: ORIGIN = 0x20000000, LENGTH = 96k+18k		
FLASH (rx)      : ORIGIN = 0x8000000, LENGTH = 256K
}

I have the debugging problem.

I mean - i can confirm that the CCM-RAM is there.. after all the program is working and explicitly testing some addresses in the upper 16k of the CCM-ram does work after all:

However the debugger seems to have a hard time accessing it.

This might be a problem with OpenOCD or a hardware problem inside the STM32G4.

I am using STLink-V2 via SWD. I think an important part of the problem is that the IDE tries to load the contents of the stack variables. So CCM-ram is accessed through the debugger.

Recommendations on how one should tackle the problem are welcome!

0 REPLIES 0