The best way to recover from a WDT ?

Folks,

I'm designing some low cost house alarm systems.
I've done a number of uP projects which are powered for a few hours at a time but never anything operating 24/7.
I would appreciate some advice on the best method to recover from a WDT timeout.

If the alarm is armed, then it must recover in that mode.
My first idea is to save the state of the armed status bit to eeprom each time it changes.
This won't "wear out" the eeprom.
Should the WDT trip, the code will automatically re-arm the alarm.
I'd not write a single bit status to the eeprom byte, but rather a 0 or 11111111b for a little extra security should a bit fail in the eeprom.

Is there a better method of recovering ?

Regards
Malcolm(t)

You could add an external FRAM memory.

Or even a single bit store with a resistor and capacitor connected to a single i/o pin.

Normally, have the pin set as out, high or low for armed / disarmed.
The watchdog presumably sets pins as input on reset, so you can read the high or low level back from the cap during the initialisation section of the program.

The series resistor can be eg. 470 Ohms, to limit the peak current when the output state changes.
Even a fairly small cap like 0.1uF should hold a valid level for quite a while when connected only to a high impedance input.

If it's a WDT reset then you should be able to detect that and your variables should still be valid, except for the ones auto initialized. However, you might also get a brown out reset which is (should be) also detectable and your variables may be corrupt. Another possible solution would be to add an I2C RTC chip such as the DS1307 and use the 56 bytes of NV ram on that chip to store states etc and add the time. Personally, if I got a WDT reset then I'd try and track down the bug.

Mike.
Edit, what chip and language are you using?

Thanks for the replies.

I'm planning on using a PIC16F628 or 648, the code will probably be written is BASIC with the Oshon compiler.
Mainly because I have used it for years and like their emulator. I've had very few hassles getting the emulated code running in the chip, the code seems to be sufficiently compact. I may use a MikroC compiler.

I'm in South Africa, there are wide variations in our AC power quality. Many areas get frequent power cuts, plus dips and spikes.
The reason for the WDT was mainly due to interference from mobile phones rather than poor code.
I think a little reading up on the PIC's brown out detection is needed.

One question... is there a reason to avoid the pic eeprom memory ?
With the minimum read/write cycle spec being 1,000,000, working on 10 cycles per day, this gives a minimum life of 273 years.

Cheers
Malcolm(t)

As it's a pic chip I'd use the internal EEPROM. Make sure there's a big capacitor on the supply and monitor the AC (low voltage) before the bridge rectifier so you know when the power fails. Like you point out, 273 years life span is more than enough. However, I prefer a different method. I'd use two bits for each write and advance a pointer each time, the default would be 11 for "not written yet" I'd write 01 for set and 10 for not set. At powerup you can search through the EEPROM for a none 11 pair and use that as the current setting. This means that even if the write gets interrupted a valid state exists. Once the 128 bytes of EEPROM are used you write 0xff back to all of it. Even if this operation gets interrupted, you can detect this at next powerup as either, the EEPROM will be full or the first byte will be 0xff and some others not. Not sure if I've explained what I mean very well.

Mike.

MalcolmT said:

Thanks for the replies.

I'm planning on using a PIC16F628 or 648, the code will probably be written is BASIC with the Oshon compiler.
Mainly because I have used it for years and like their emulator. I've had very few hassles getting the emulated code running in the chip, the code seems to be sufficiently compact. I may use a MikroC compiler.

I'm in South Africa, there are wide variations in our AC power quality. Many areas get frequent power cuts, plus dips and spikes.

Click to expand...

If you're building an alarm it should have a battery backup anyway - no point in an alarm if it can be disabled by killing the power.

MalcolmT said:

I'm planning on using a PIC16F628 or 648

Click to expand...

Why don't you use a newer, faster and cheaper chip with more functionality and lower power?

Microchip recommends users replace the '628 with a '628A and then users of '628A to consider a more current chip.
Also, I remember some notice about Microchip 18-pin devices having some issue with using a programming pin in your circuit. I. Think there is a tech note or errata note on the issue.

gophert said:

Why don't you use a newer, faster and cheaper chip with more functionality and lower power?

Microchip recommends users replace the '628 with a '628A and then users of '628A to consider a more current chip.
Also, I remember some notice about Microchip 18-pin devices having some issue with using a programming pin in your circuit. I. Think there is a tech note or errata note on the issue.

Click to expand...

Thanks for the heads up.
I've just double check, It is the "A" version I'll be using.
I'll do a search for the tech note and read it up.

Much appreciated

Regards
Malcolm

MalcolmT said:

Thanks for the heads up.
I've just double check, It is the "A" version I'll be using.
I'll do a search for the tech note and read it up.

Much appreciated

Regards
Malcolm

Click to expand...

If you're limiting yourself to 18 pin?, the 16F1847 is a nice chip, and absolutely wipes the floor with the 16F628a.

Nigel Goodwin said:

If you're limiting yourself to 18 pin?, the 16F1847 is a nice chip, and absolutely wipes the floor with the 16F628a.

Click to expand...

Hi Nigel,

Thanks for the hint on the 16F1847.
The main reason for skipping it is I'm currently limited to a vintage programmer.
An upgrade is in the pipeline.
Interestingly none of the component suppliers around Jo'burg (with the exception of RS) stock the 16F1847.
And as you rightly say, it certainly wipes the floor, with spec's and price ( from RS).
RS can be pricey for run of the mill parts when compared to the local suppliers I use. But their PIC's can be cheaper and delivery isn't bad considering much of their stock comes in the from the UK.

Moving off topic a little. I'm a retired automation engineer. Mainly worked with Allen Bradley systems since the early 80's.
I go right back to their original PLC system.
It must be 20 years since I last had PCB's made, today I collected my first set of boards made from gerber files.
I still have my plotter for the old 2:1 artwork, and a few weeks ago threw out some PCB letraset I'd had since Adam was a lad.

I'll defiantly see whats needed to move up to the modern uC's. The weekend I'm teaching the wife to solder.
We're getting cracking on car and motorbike alarms ( two variations of each), low(ish) tech, in easily hidden 5x7cm enclosures.
Once they're on their way, I'll dig deeper into the 16F1847 and see how I can use the new features.

Thanks again
Malcolmt

MalcolmT said:

Hi Nigel,

Thanks for the hint on the 16F1847.
The main reason for skipping it is I'm currently limited to a vintage programmer.
An upgrade is in the pipeline.
Interestingly none of the component suppliers around Jo'burg (with the exception of RS) stock the 16F1847.
And as you rightly say, it certainly wipes the floor, with spec's and price ( from RS).
RS can be pricey for run of the mill parts when compared to the local suppliers I use. But their PIC's can be cheaper and delivery isn't bad considering much of their stock comes in the from the UK.

Click to expand...

If you can get RS, then you can probably get Farnell - and Farnell 'may' be slightly cheaper, but also keep a much better range of more later PIC devices.

If you're thinking of making a higher specified alarm system (nice displays etc.) I can recommend the 18F27K42, which is a 28 pin DIP device (also available as 40 pin) with a whopping 128K of program memory!