SPC5602 Remembering the reasons for a reset

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

SPC5602 Remembering the reasons for a reset

Jump to solution
818 Views
aero72
Contributor III

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?

1 Solution
637 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

Yes the RGM will keep content of registers after destructive reset.

You can clear it by SW or you can execute Power On Reset which will reset also RGM module.

Have a look in debugger after SWT trigger reset. After reset you can read F_SWT flag. Otherwise there is no way to find out what was the reset source.

Peter

View solution in original post

2 Replies
637 Views
aero72
Contributor III

Dear Peter,

Many thanks for your response - attaching a debugger is difficult because it can influence the SWT behaviour (i.e. you don't get the SWT reset if the debugger is attached).

However, I have managed to prove that the RAM copy is being written correctly - looks like there's a bug in the compiler when reading that memory unless I address it directly using an explicit pointer rather than its semi-friendly structure name.

If I force the reset, then attach the debugger and use that to read the memory I can see that the RAM copy of RGM.DES.R = 4 which corresponds to the F_SWT bit.

It's a compiler fault. Thanks for your confirmation that the DES keeps its state through the reset. 

0 Kudos
638 Views
petervlna
NXP TechSupport
NXP TechSupport

Hi,

Yes the RGM will keep content of registers after destructive reset.

You can clear it by SW or you can execute Power On Reset which will reset also RGM module.

Have a look in debugger after SWT trigger reset. After reset you can read F_SWT flag. Otherwise there is no way to find out what was the reset source.

Peter