AnsweredAssumed Answered

SPC5602 Remembering the reasons for a reset

Question asked by Andrew Smith on Oct 25, 2017
Latest reply on Oct 25, 2017 by Andrew Smith

So following my question about the SWT configuration a few days ago, I have made some good progress....I am able to cause my application to reset on demand by making it 'forget' to refresh the SWT.

 

I can see the micro throw a reset (albeit it is very short - 500us) - the code restarts.

 

The application is in 2 parts, a bootloader and a main application. There is a structure of shared memory that the kernel can write to for the main application to pick up and act on later. At reset, the bootloader runs, detects the presence of a main application, and jumps to it.

 

The bootloader includes software to read and clear the RGM.FES and RGM.DES registers. I had expected that the F_SWT would be set in the RGM.DES register in this condition - the software itself takes a copy of the register, writes it into that structure in RAM for the main code to read it later, and then clears the registers.

 

I wondered whether the RGM.DES is volatile and would be cleared by the SWT reset, so I have also copied the FCU.FFFR in the same way.

 

All of these registers are read as zero in RAM - implies no fault.

Would you expect RGM.DES to have F_SWT set following a SWT timeout, and would that register's state be preserved through the reset that will take place?

Outcomes