topic Re: Writing a flag to Retention RAM in Hardfault Handler in S32K

Writing a flag to Retention RAM in Hardfault Handler

pulkitp — Wed, 22 Jan 2025 11:13:22 GMT

Hi,

I am using S32K322 mcu. I am running Application with Bootloader, my aim is to set a flag in Retention RAM inside the Hardfault Handler so that I can detect the Hardfault in Bootloader.
To achieve this I created a noinit section in SRAM.
/*Noinit section inside sharable region*/
.noinit (NOLOAD) :
{
__noinit_start = .;
*(.noinit) /* Variables explicitly placed in the .noinit section */
. = ALIGN(4);
__noinit_end = .;
} > int_sram_shareable

and then done changes in startup_cm7.s to stop reinitialization of noinit section

RamInit:
/* Initialize SRAM ECC */
ldr r0, =__RAM_INIT
cmp r0, 0
/* Skip if __RAM_INIT is not set */
beq SRAM_LOOP_END

ldr r0, =MCRGM_DES
ldr r1, [r0]
ldr r2, =MCRGM_DES_F_POR
and r1, r1, r2
cmp r1, 0

beq NO_INIT_STANDBY_REGION
ldr r1, =__INT_SRAM_START
ldr r2, =__NOINIT_SRAM_START // Exclude noinit memory region
//ldr r2, =__INT_SRAM_END
b ZERO_64B_RAM

NO_INIT_STANDBY_REGION:
#if defined(S32K310)||defined(S32M274)
ldr r1, =__BSS_SRAM_NC_START
#else
ldr r1, =__BSS_SRAM_START
#endif
ldr r2, =__NOINIT_SRAM_START /* Exclude .noinit */
//ldr r2, =__INT_SRAM_END

ZERO_64B_RAM:
subs r2, r1
subs r2, #1
ble SRAM_LOOP_END

movs r0, 0
movs r3, 0
SRAM_LOOP:
stm r1!, {r0,r3}
subs r2, 8
bge SRAM_LOOP
SRAM_LOOP_END:

Now I am trying to write Flag inside the HardFault handler

__attribute__((section(".noinit"))) volatile uint8_t hardFaultCounter;

void HardFault_Handler(void)

{

hardFaultCounter++;

__asm volatile("dsb 0xF":::"memory");

__asm volatile ("isb 0xF");

while(TRUE)

{

};

}

My problem is it is retaining the value only if I am putting the breakpoint to hardFaultCounter++; and stepping up but without breakpoint it is not retaining.
Please note that It is successfully writing the updated value to the retention RAM, I verified by reading back but It is not retaining the value after reset.
Is Memory Protection Unit is preventing to retain ?

Re: Writing a flag to Retention RAM in Hardfault Handler

Julián_AragónM — Thu, 23 Jan 2025 16:52:11 GMT

Hi @pulkitp,

RAM retention is only supported across functional reset. You mentioned "It is not retaining the value after reset.", are you testing this with the "Power_Ip_PerformReset" function? or with any standby exit options?

Also, there is an existing example for Standby RAM based on S32K312 EVB. Please revise it: Example S32K312 Standby mode & Standby RAM and PAD keeping DS3.5 RTD300 - NXP Community

Best regards,
Julián

Re: Writing a flag to Retention RAM in Hardfault Handler

pulkitp — Fri, 24 Jan 2025 05:51:19 GMT

Hi Julian,

Thanks for the response, In my case the watchdog reset is going to occur if In any case It stuck in Hardfault Handler loop which I am considering a Functional Reset.
Also for debugging purposes I am resetting using debugger also, which I am supposing also a function reset only.
Please let me know if I am doing it wrong.
I am explaining my case below:-
So you can see I am incrementing the hardFaultCounter inside the hardfault handler. suppose hardFaultCounter is 5 and after incrementing it is 6 and if I put the breakpoint there and reset using debugger then hardFaultCounter is the incremented one(which is 6) and correct.
Now if I remove the breakpoint and it went to hardfault and I resume the program using debugger It will stop inside the while loop, value of hardFaultCounter is 6(which is incremented as expected supposing previous it was 5) and then doing debugger reset, the value of hardFaultCounter is coming 5 which should be 6.

Hope I cleared the point.

void HardFault_Handler(void)

{

hardFaultCounter++;

__asm volatile("dsb 0xF":::"memory");// If I am putting breakpoint here then do debugger reset value is coming correct

__asm volatile ("isb 0xF");

while(TRUE)

{

};

}

Re: Writing a flag to Retention RAM in Hardfault Handler

Julián_AragónM — Fri, 24 Jan 2025 16:34:38 GMT

Hi @pulkitp,

When not using the breakpoint, are you attaching to target when running the debugger a second time? Your issue may be that the debugger re-programs the MCU when connecting again.

I am unsure what debugger you are using, but in PEMicro's debug configuration, you can find the Attach to Running Target option inside "Startup":

Best regards,
Julián