S32K3 Standby RAM data modified before Reset_Handler

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K3 Standby RAM data modified before Reset_Handler

52 Views
Jason07
Contributor II

Hello,

When I debug S32K344 with PE Micro, I found that an array(__attribute__ ((section(".standby_data"))) volatile uint32_t WkupSourcestatus1[64];) located in the standby RAM section  is unexpectedly modified when entering main(). Then, as shown in the attached video, I manually modified the registers to reinitialize the standby RAM area. The data was correctly initialized to 0, and after entering main(), everything ran fine. However, after a reset, when I enter the Reset_Handler, the data in the WkupSourcestatus1 array is modified again. Why is this happening? I noticed that a large number of 0x5AA55AA5 values appear in the array. Is this related to the SBAF_BOOT_MARKER? I tested this on another board and the phenomenon is the same.

8.png8.png

Then I switched to using J-Link for debugging and found that no abnormality occurs during a reset while debugging. However, after a debug session is restarted, all data in the standby RAM area becomes 0xDEADBEEF. Is this expected behavior?

S32K344

S32DS3.6.4

RTD700

PE v.6.0.8

 

BR,

Jason

Tags (2)
0 Kudos
Reply
0 Replies
%3CLINGO-SUB%20id%3D%22lingo-sub-2406767%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ES32K3%20Standby%20RAM%20data%20modified%20before%20Reset_Handler%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2406767%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3E%3CSPAN%3EWhen%20I%20debug%20S32K344%20with%20PE%20Micro%2C%20I%20found%20that%20an%20array(__attribute__%20((section(%22.standby_data%22)))%20volatile%20uint32_t%20WkupSourcestatus1%5B64%5D%3B)%20located%20in%20the%20standby%20RAM%20section%20%26nbsp%3Bis%20unexpectedly%20modified%20when%20entering%20main().%20Then%2C%20as%20shown%20in%20the%20attached%20video%2C%20I%20manually%20modified%20the%20registers%20to%20reinitialize%20the%20standby%20RAM%20area.%20The%20data%20was%20correctly%20initialized%20to%200%2C%20and%20after%20entering%20main()%2C%20everything%20ran%20fine.%20However%2C%20after%20a%20reset%2C%20when%20I%20enter%20the%20Reset_Handler%2C%20the%20data%20in%20the%20WkupSourcestatus1%20array%20is%20modified%20again.%20Why%20is%20this%20happening%3F%20I%20noticed%20that%20a%20large%20number%20of%200x5AA55AA5%20values%20appear%20in%20the%20array.%20Is%20this%20related%20to%20the%20SBAF_BOOT_MARKER%3F%20I%20tested%20this%20on%20another%20board%20and%20the%20phenomenon%20is%20the%20same.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%228.png%22%20style%3D%22width%3A%20891px%3B%22%3E%3Cspan%20class%3D%22lia-inline-image-display-wrapper%22%20image-alt%3D%228.png%22%20style%3D%22width%3A%20891px%3B%22%3E%3Cimg%20src%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F394990i5FC8B0B13E29EF08%2Fimage-size%2Flarge%3Fv%3Dv2%26amp%3Bpx%3D999%22%20role%3D%22button%22%20title%3D%228.png%22%20alt%3D%228.png%22%20%2F%3E%3Cspan%20class%3D%22lia-inline-image-caption%22%20onclick%3D%22event.preventDefault()%3B%22%3E8.png%3C%2Fspan%3E%3C%2Fspan%3E%3CSPAN%20class%3D%22lia-inline-image-caption%22%20onclick%3D%22event.preventDefault()%3B%22%3E8.png%3C%2FSPAN%3E%3C%2FSPAN%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3EThen%20I%20switched%20to%20using%20J-Link%20for%20debugging%20and%20found%20that%20no%20abnormality%20occurs%20during%20a%20reset%20while%20debugging.%20However%2C%20after%20a%20debug%20session%20is%20restarted%2C%20all%20data%20in%20the%20standby%20RAM%20area%20becomes%200xDEADBEEF.%20Is%20this%20expected%20behavior%3F%3C%2FP%3E%3CP%3ES32K344%3C%2FP%3E%3CP%3ES32DS3.6.4%3C%2FP%3E%3CP%3ERTD700%3C%2FP%3E%3CP%3EPE%20v.6.0.8%3C%2FP%3E%3CBR%20%2F%3E%3CP%3EBR%2C%3C%2FP%3E%3CP%3EJason%3C%2FP%3E%3C%2FLINGO-BODY%3E