s32k312 standby RAM caused the project exception

[luhaiou]

here are the following questions that need your help to analyze.

Our project uses S32K312, which consists of boot and APP projects,
APP project has FreeRTOS system, and the RAM space used by APP project is greater than 120K.
When debugging standby RAM, it is found in the APP project that the data in standby RAM is not saved normally after sleeping wake-up.
The boot jump APP is normal at this time.
At this point the project's ld,map file is attached as an attachment.

The data in standby RAM is not saved properly,
we suspect that there is no standby RAM space reserved in the boot project,
resulting in the standby RAM being initialized in the boot project.
We add the following modifications to the LD file of boot, 

MEMORY
{
int_flash : ORIGIN = 0x00400000, LENGTH = 0x0003FFFC /* 256KB, PBL*/
int_flash_cmp_flag : ORIGIN = 0x0043FFFC, LENGTH = 0x00000004 /* 4B*/
int_itcm : ORIGIN = 0x00000000, LENGTH = 0x00008000 /* 32KB */
int_dtcm : ORIGIN = 0x20000000, LENGTH = 0x00010000 /* 64KB */
int_sram : ORIGIN = 0x20400000, LENGTH = 0x0000DF00 /* 56K - 256B*/
int_sram_fls_rsv : ORIGIN = 0x2040DF00, LENGTH = 0x00000100 /* 256byte */
int_sram_stack_c0 : ORIGIN = 0x2040E000, LENGTH = 0x00001000 /* 4K */
int_sram_no_cacheable : ORIGIN = 0x2040F000, LENGTH = 0x00004000 /* 16kb , needs to include int_results*/
int_sram_array_data : ORIGIN = 0x20413000, LENGTH = 0x00003E00 /* 16k - 512B */
int_sram_results : ORIGIN = 0x20416E00, LENGTH = 0x00000200 /* 512byte */
int_sram_shareable : ORIGIN = 0x20417000, LENGTH = 0x00001000 /* 4k */
ram_rsvd2 : ORIGIN = 0x20418000, LENGTH = 0 /* End of SRAM */
}

MEMORY
{
int_flash : ORIGIN = 0x00400000, LENGTH = 0x0003FFFC /* 256KB, PBL*/
int_flash_cmp_flag : ORIGIN = 0x0043FFFC, LENGTH = 0x00000004 /* 4B*/
int_itcm : ORIGIN = 0x00000000, LENGTH = 0x00008000 /* 32KB */
int_dtcm : ORIGIN = 0x20000000, LENGTH = 0x00010000 /* 64KB */
int_sram_swc : ORIGIN = 0x20400000, LENGTH = 0x00000100 /* 256B */
int_sram : ORIGIN = 0x20400100, LENGTH = 0x0000DE00 /* 56K - 512B*/
int_sram_fls_rsv : ORIGIN = 0x2040DF00, LENGTH = 0x00000100 /* 256byte */
int_sram_stack_c0 : ORIGIN = 0x2040E000, LENGTH = 0x00001000 /* 4K */
int_sram_no_cacheable : ORIGIN = 0x2040F000, LENGTH = 0x00004000 /* 16kb , needs to include int_results*/
int_sram_array_data : ORIGIN = 0x20413000, LENGTH = 0x00003E00 /* 16k - 512B */
int_sram_results : ORIGIN = 0x20416E00, LENGTH = 0x00000200 /* 512byte */
int_sram_shareable : ORIGIN = 0x20417000, LENGTH = 0x00001000 /* 4k */
ram_rsvd2 : ORIGIN = 0x20418000, LENGTH = 0 /* End of SRAM */
}

The test again found that the APP project could not work normally after the power failure and restart,
but when the PE debugger was connected, it was possible to jump from boot to APP work.
The app project has not been modified, only the ld file of the boot project has been modified,
why does it cause the APP to run abnormally?
Please help analyze thank you very much

[Senlent]

Hi@luhaiou

Can you create a new project to test the function of STANDBY RAM alone
I have cope the steps of using standby ram below, you can check if there is anything missing,

below process base on S32K344,it should be same with S32K312

and finally you can refer to the routine of Standby RAM based on S32K344

https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Low-Power-Management-AN-and-demos/ta-p/152772... 

[SHCHOU]

Hi Senlent , 

I use S32K314, follow you standby ram step.

But, I have a question, where should I use the standby_sram_init func from step2. ?

every time power on? or before enter standby?

With just these steps, i can save data in standby ram between run mode and stabdby mode, right?

plz help me, thx.

[luhaiou]

Thanks for your reply, I think it is possible to successfully test the StandbyRAM functionality using a separate project. But now there is an urgent need to fix the anomaly in our project. The app project uses FreeRTOS, DTCM

Is standby RAM  MUST USE 32K ??  I  JUST want use 256 byte.

int_sram_swc : ORIGIN = 0x20400000, LENGTH = 0x00000100 /* 256B */,

0x20400100---0x20408000 is as normal RAM

APP project has use 120K RAM

I tracked down HardFault, and bothered to help analyze the possible causes.Please refer to the picture Thank you so much. Please refer to the picture

[Senlent]

Hi@luhaiou

There is no such limit.

In the link of my last answer, the routine "S32K344_RTC_StandbyRAM_Wkup" allocates 256B of standby ram space for storing data.

[luhaiou]

1.You mentioned that D-cache must be disabled when using standby RAM. Please help analyze why D-cache must be disabled .

2.If I want to set my 256 byte standby RAM as non-cacheable, How will I set up the MPU?

[Senlent]

Hi@luhaiou

Sorry for the late reply as it took a while to research.

1. I found some answers that might explain the problem

"The recommendation is always to initialize all RAM memory before enabling Cache because all cacheable memory could be accessed at any time and could generate this kind of fault if it is not initialized previously. If customer wishes to enable Cache and after initializing Standby RAM then this region should be specified as non-cacheable in order to avoid this behavior."

2. Modify the 256byte standby ram to non-cacheable

you can open "system.c " and modified code like below.

rbar[5]=(uint32)__INT_SRAM_START;//__INT_SRAM_START here is 0x20400000.
rasr[5]=((uint32)0x130C0001UL)|(((uint32)0x08- 1) << 1);//MPU_RASR->SIZE = 0x07->256byte

0x130C0001UL refers to this configuration, here I only modified the SIZE register to 256byte

MPU_RASR register map:CM7 MPU 

[luhaiou]

Thanks for your reply.

1.In order not to affect  “Ram unified section  + stack”, I leave Region 5 unchanged.
Because M7 supports 16 regions, I have added an additional region 14, as shown below,
please evaluate whether this modification is appropriate. 

2.Refer to the M7 document, I am more confused,

and the content of the system.c file does not match, please help explain

/* Init MPU table for memory layout*/
/* Cover all memory on device as background set all memory as strong-order and no access*/
rbar[0]=0x00000000UL;
rasr[0]=0x1004003FUL; 2^32 = 4G entire memory

/* ITCM for cortex M7 if no set it as zero */
rbar[1]=(uint32)__INT_ITCM_START;
rasr[1]=0x0104001FUL; 2^16 = 64K
/*Program flash which would extract from linker symbol*/
rbar[2]=(uint32)__ROM_CODE_START;   int_flash : ORIGIN = 0x00440000, LENGTH = 0x001D4000，APP Project start 0x00440000,is not aligned to the size of the region 4M

rasr[2]=0x060B002BUL; 2^22 = 4M

/*Data flash which would extract from linker symbol*/
rbar[3]=(uint32)__ROM_DATA_START;   s32k3 12  ld file __ROM_DATA_START = 0x10000000,,s32k312 has no this space
rasr[3]=0x16050023UL; /* Device, Non-cache, Share */ 2^18 = 256K

/*DTCM for cortex m7 if no set it as zero*/
rbar[4]=(uint32)__INT_DTCM_START;
rasr[4]=0x01040021UL; 2^17 = 128 K

/*Ram unified section + stack*/
#if !defined(S32K344) && !defined(S32K324)
rbar[5]=(uint32)__INT_SRAM_START;app project int_sram : ORIGIN = 0x20400100,is not aligned to the size of the region
rasr[5]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1);

2^15 = 32K , __RAM_NO_CACHEABLE_SIZE = 0xF; /* 32kbyte in power of 2 */,It is not match my ld file,Refer to the attachment

#else
rbar[5]=(uint32)__INT_SRAM_START;
/*disable subregion 7-8*/
rasr[5]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14); 2^15 = 32K,it is not match my ld file,Refer to the attachment
#endif

/*Ram non-cache section plus int result which is using for test report*/
rbar[6]=(uint32)__RAM_NO_CACHEABLE_START;
rasr[6]= ((uint32)0x130C0001UL)|(((uint32)__RAM_NO_CACHEABLE_SIZE - 1) << 1); 2^15 = 32K,and it is not match my ld file,Refer to the attachment

/*Ram shareable section*/
rbar[7]=(uint32)__RAM_SHAREABLE_START;
rasr[7]=((uint32)0x130C0001UL)|(((uint32)__RAM_SHAREABLE_SIZE - 1) << 1); 2^15 = 32K,and it is not match my ld file,Refer to the attachment
/* Additional configuration for peripheral device*/

/*AIPS_0*/
rbar[8]=0x40000000UL;
rasr[8]=0x13050029UL; 2^21 = 2M

/*AIPS_1*/
rbar[9]=0x40200000UL;
rasr[9]=0x13050029UL; 2^21 = 2M

/*AIPS_2*/
rbar[10]=0x40400000UL;
rasr[10]=0x13050029UL; 2^21 = 2M

/*QSPI Rx*/
rbar[11]=0x67000000UL;
rasr[11]=0x13050013UL; 2^10 = 1K

/*QSPI AHB*/
rbar[12]=0x68000000UL;
rasr[12]=0x030B0035UL; 2^27 = 128M

/*QSPI AHB*/
rbar[13]=0xE0000000UL;
rasr[13]=0x13040027UL; 2^20 = 1M

[Senlent]

Hi@luhaiou

1.I may have miscalculated here,

0x130c000f->00010011000011000000000000001111->MPU_RASR.SIZE = 7->128kb.

for 258KB,no need to subtract 1

rbar[14]=0x20400000;

rasr[14]=((uint32)0x130C0001UL)|(((uint32)0x08) << 1);;

2.The address alignment of the default configuration given by S32 DS should be no problem.

I will summarize the calculation process as follows:

for example:

0x060B002BUL->0b0110000010110000000000101011->MPU_RASR.SIZE = 21->Region size = 2MB

2MB region must be aligned on a multiple of 2MB:

2MB = 2^21->0x00200000

[luhaiou]

1.for 256 Byte,may need to subtract 1,please evaluate whether this is right.

2.default configuration given in system.c , In fact, it is indeed misaligned

1. /*Ram unified section + stack*/
   #if !defined(S32K344) && !defined(S32K324)
   rbar[5]=(uint32)__INT_SRAM_START;
   rasr[5]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1);

        IN app.ld file

        int_sram : ORIGIN = 0x20400100, LENGTH = 0x0000DE00 /* 56K - 512B*/

       __INT_SRAM_START = ORIGIN(int_sram);

      __RAM_CACHEABLE_SIZE = 0xF; /* 32kbyte in power of 2 */

        0x20400100 is not aligned to 2^((0xF-1)+1)= 32K,

       0x0000DE00 is bigger than 2^((0xF-1)+1)= 32K

        Will this have any bad effects?

 3. I change  boot memory section ,I have uploaded the file system.c(system.txt)

MEMORY
{
int_flash : ORIGIN = 0x00400000, LENGTH = 0x0003FFFC /* 256KB, PBL*/
int_flash_cmp_flag : ORIGIN = 0x0043FFFC, LENGTH = 0x00000004 /* 4B*/
int_itcm : ORIGIN = 0x00000000, LENGTH = 0x00008000 /* 32KB */
int_dtcm : ORIGIN = 0x20000000, LENGTH = 0x00010000 /* 64KB */
int_sram_swc : ORIGIN = 0x20400000, LENGTH = 0x00001000 /* 4K */
int_sram : ORIGIN = 0x20401000, LENGTH = 0x0000DF00 /* 56KB - 256B , Static data sections and heap section */
int_sram_fls_rsv : ORIGIN = 0x2040EF00, LENGTH = 0x00000100 /* 256B , base not used */
int_dtcm_sram_stack_c0 : ORIGIN = 0x2040F000, LENGTH = 0x00001000 /* 4K , Stack section of core 0 */
int_sram_no_cacheable : ORIGIN = 0x20410000, LENGTH = 0x00005F00 /* 24KB - 256B, Non-cacheable section */
int_sram_results : ORIGIN = 0x20415F00, LENGTH = 0x00000100 /* 256B , Result section */
int_sram_shareable : ORIGIN = 0x20416000, LENGTH = 0x00002000 /* 8KB , Shareable section */
ram_rsvd2 : ORIGIN = 0x20418000, LENGTH = 0 /* End of SRAM */
}

I only changed the partition range of different RAM,Why it causes boot project a hardware interrupt?

The error occurs with systen.c before the main function

[Senlent]

Hi@lihaiou

I am also not familiar with these modules, welcome to continue the discussion

1. Indeed, I didn't see this detail, this confused me for a while
2. You may have misunderstood me, I mean there is no problem with the default link file and the MPU configuration in system.c
3 .I did a test and modified the linker and system.c according to your method. Some parts of the MPU configuration you provided are wrong, so I made some modifications.

[luhaiou]

Hi @Senlent

Thank you for your continued support, thank you very much.

Depending on the modifications you provide, boot is ok. I have one more question to ask.

It is about MPU Region Base Address.

my boot project  sram address is 0x20401000，size 64k,N=log2(64K)=16.

0x20401000 is not aligned to 64K.

I think the misaligned parts will be discarded inside the MPU. I want to confirm with you if this idea is true.

[Senlent · Accepted solution]

Hi@luhaiou

Your calculation is correct, this is indeed wrong, my original idea is to first set the starting position of 0x20400000 as:

    /*Ram unified section  + stack*/

#if !defined(S32K344) && !defined(S32K324)

    rbar[5]=(uint32)0x20400000;

    rasr[5]=((uint32)0x030B0001UL)|(((uint32)0x10 - 1) << 1);//64k

#else

    rbar[5]=(uint32)__INT_SRAM_START;

    /*disable subregion 7-8*/

    rasr[5]=((uint32)0x030B0001UL)|(((uint32)__RAM_CACHEABLE_SIZE - 1) << 1)|(1<<15)|(1<<14);

#endif

Then set the 4K region from 0x20400000 to 0x20401000 as:

  /*standby ram*/

    rbar[14]=(uint32)__STANDBY_SRAM_START;//0x20400000 ,length = 0x00001000

    rasr[14]= ((uint32)0x130C0001UL)|(((uint32)0x0C- 1) << 1);

I think the above settings should be correct, and there will be no alignment problems.

In addition

     there seems to be no problem here even if it is not aligned. I have read some answers and their explanation is:

“In general, RAM accesses on Cortex-M7 based devices do not have to be aligned in any way. The Cortex-M7 core can handle unaligned accesses by hardware（but I don't know how it works）. Usually, variables should be naturally aligned because these accesses are slightly faster than unaligned accesses.”