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
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
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.
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?
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
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
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
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
- /*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
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.
