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?