9S08DZ32: How to handle writes to SRS for proper watchdog (COP) reset?

[Cantalis]

Hello,

what is the proper way (after enabling the watchdog mechanism in the registers SOPT1 and SOPT2) to write to SRS in order to (periodically) reset the COP watchdog?

In the data sheet rev.4 for 9S008DZ60 family I read: "Writing a 0x55-0xAA sequence to this address clears the COP watchdog timer".

Does this mean the timer is reset in the moment the second byte is written to SRS?

Or does timer reset occur *each time* one of these bytes is written?

As far as I understand it right now it only matters that an endless sequence of 0x55/0xAA/0x55/0xAA....(as long as the time which elapses between the byte-writes does not exceed the COP timeout) has to be written to SRS. I went through many posts in this forum but I did not find an answer to my question above.

I also tried all this on a real system but all I get is endless COP resets no matter how I implement the writes to SRS. So I suspect that I have a faulty understanding of how SRS need to be written to.

Thanks for any help.

Regards

-Roland 

[Lundin]

SRS = 0x55;
SRS = 0xAA;

If your code looks like that, the problem isn't related to the COP write sequence.

[Cantalis]

Thank you for the messages I received so far. Yes, my code contains:

SRS = 0x55;
SRS = 0xAA;

but at first I thought what might happen if an interrupt gets in between the two writes (but that seems to be of no influence - the only important issue is that both bytes have to be written in the correct order and that the timer only gets cleared after the second byte is written).

My initialization for the watchdog timer is 8192 cycles (COPT=01) and 2 MHz internal bus clock. That leads to 8192 x 0.5µs = 4.096 ms watchdog timeout.

I have narrowed my focus to my startup code. The first thing after reset is to initialize SOPT2, then SOPT1, and after that I start the oscillation mode with external XTAL. As soon as the XTAL is running and an additional RAM check is done I proceed to the first sequence 55/AA to be written to SRS. Because the whole startup *might* need more than 4ms the watchdog times out before the first 55/AA sequence is reached.

I will do some more measurements to determine the start up timing. The code as it is now followed the Freescale recommendation to write to SOPT2/SOPT1 as early as possible because the frist write does a "lock in" of the values (no second write possible).

I do not know if 4ms is a typical watchdog time-out or if I should lengthen that to the next value which would be appr 32ms. (the old application on a 68HC05 I am currently porting to 9S08DZ even had 1,8ms)

[bigmac]

Hello,

The COP timer should definitely be reset prior to enabling the external crystal.  The crystal startup time may well exceed 4 ms, and may be hundreds of milliseconds for a low frequency crystal. If you loop until the FLL is locked, the COP timer should also be reset within this wait loop.

Also keep in mind that the initial COP timeout period will be determined by the POR default bus frequency, so could actually be initially a significantly shorter period.  This would apply during the initialisation process for global and static variables.  However, this should be problematic only if you had a large number of variables and/or large arrays to be initialised.

The choice of COP timeout period will depend on the application.  Since you are using an external crystal, there would seem little point in choosing a short timeout period.  Personally, I would consider 32 ms to be more appropriate than 4 ms in this case.

Regards,

Mac

[Cantalis]

bigmac,

thanks for your remarks. My application is automotive and the external Xtal is 16MHz. I do not use any internal FLL/PLL scheme - everything is derived from the Xtal frequency. I found that after reset also the memory check/init is time consuming and this prohibits short watchdog timeouts like 4ms. Because I want to follow the rule to set the COPT2/COPT1 bits as soon as possible after reset the only choice is 32ms timeout (or even longer)

You write:

>>Since you are using an external crystal, there would seem little point in

>>choosing a short timeout period.

What are your thoughts when you say that external Xtal and short timeouts do not fit together?

Best regards

-Roland

[bigmac]

Hello Roland,

---

Cantalis wrote:

You write:

>>Since you are using an external crystal, there would seem little point in

>>choosing a short timeout period.

What are your thoughts when you say that external Xtal and short timeouts do not fit together? 

---

The only reason that I can see for having a short COP timeout period would be to hasten the recovery period in the event of a temporary fault.  However, the crystal startup period (even for a 16 MHz crystal) will occupy a few milliseconds.  So little would be gained with a short COP timeout period, compared with other reset events.

After a reset, operation will commence using the FLL output and internal oscillator.  The external crystal is then selected.  So the crystal startup period would apply following all resets. 

I see that the default COP timeout period after a POR is approximately 1 second (using the 1 khz oscillator). This would mean that COP timeout during ANSI initialisation of global variables would be highly unlikely.

Regards,

Mac

[peg]

Hello Roland,

I don't actually have any experience with this as the devices I use are "write anything" to SRS. Usually just implemented with a STA SRS (write whatever happens to be in A).

The datasheet says "in this order" so I would take this as doing a write of 55 immediately followed by AA for each reset. Alternatively writing 55 then AA does not really have an order to it. Also note that it does say that writing anything else will immediately cause a reset. Another pointer is the phrase "write sequence is done".

Also watch out for the windowed mode of operation where the COP reset can only be made in the last 25% of the timeout period

Also be careful of the "write-once" registers when setting up.

Message Edited by peg on 2009-12-03 08:29 PM