SPC5602 Remembering the reasons for a reset

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

SPC5602 Remembering the reasons for a reset

ソリューションへジャンプ
1,092件の閲覧回数
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 解決策
911件の閲覧回数
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

元の投稿で解決策を見る

2 返答(返信)
911件の閲覧回数
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 件の賞賛
返信
912件の閲覧回数
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