Our Board witch MC9S12XET256 when there was electromagnetic signals, would be stay in current dead sometimes, not reset

[hongjianzhang]

A few days before, I push a question about our board with hy64 was influenced by cellphone call, and that mcu could go to reset every time, but today another board with mc9s12xet256 couldn't go to reset sometimes, it reset sometimes and then dead, only reconnect the power can save it.  

We use outside oscillator, and init it at the beginning of main program, and then config the pll module. at last we open the cop watchdog.

I think this state is that: our watchdog was used the first time of the electromagnetic signals disturb and reset, but when the mcu begin to work after reset, before our cop watchdog begin useful there was electromagnetic signals disturb still,and the program go into a illegal address or go into somewhere and couldn't go into normal state. 

I don't understand why the chip designer not open the cop watchdog at the beginning of the reset,  if it was what I said above, how can we avoid such thing? Besides, my opinion of the problem, I can't make sure ,only my thoughts. 

[lama]

Hi,

you are in troubles I have not seen for a long time of existence of these MCUs.

In this case i would suggest to start to create own procedure to locate the source of the issue. In the first approach let's consider the PCB and design is OK. Now it is worth to create simple test code which only solves following.

1) It sets clock and put it onto PE4 by means of NECLK bit setup in ECLKCTL to be sure the clock is correct.

2) The COP is launched directly by HW writing a proper value to FOPT  register placed in FLASH (at $7FFF0E). For more info see "COP configuration" chapter in the reference manual.

3) Do not forget to set suitable period of COP to be sure that loops waiting for some flag will not cause COP overflow.

Of course, do not refresh the COP inside such loops. Otherwise the MCU can freeze in this loop if the required flag is not set.

4) Be sure all interrupts have their routines and unused interrupt are directed to one routine where we can catch unexpected interrupts.

5) COP is correctly recognized, served and processed to be able to see on external pins what is wrong and where the code is in the case of issue.

S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS_v2.0.pdf 

S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS - calculator.xlsx 

I am sorry, I am able to provide you suggestions only. You know, it would be easier to be with you in your lab.

Now, if you see the MCU is still in repeating reset or never-ending loop we should go to HW design review.

Best regards,

Ladislav