Good day all. I would like to know if there is a programming technique for preventing a program from locking-up, or getting a program going once
it has become stuck. I Know this is the function of the watchdog timer, but since it is not advisable to use it, is there a way using say an interrupt
to check that all is running well, assuming the interrupt is still running even though the program has freezed up. My device had been running fine for
a few days and then it locked up, I am working to resolve the lockup issue, but it would be nice to have a watchdog type feature just in case. Any Idea
on this. Thanks in advance.
Ondra
Preventing Program lockups
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Preventing Program lockups
Hello Ondra
Yes the watchdog is good to have as an option once your program is designed and fairly stable. Basically once you have the watchdog turned on you have a period of time before the watchdog timer reaches the maximum value and rolls over back to 0. This will cause the device to reset. To keep the device from resetting simply use the following C code: clr_wdt(); somewhere in your main loop. To change the period of time before reset you can adjust the prescalar to the watchdog by writing a byte to the Option_register (I think, I know its one of them anyway probably better to find it in the datasheet). If you have delays in your program then you will have to use my beta custom delay component that will allow you to do the delay without the device resetting. Eg during the delay the clr_wdt function is called automatically for you. This does mean that my delays are ever so slightly off, there is a variable you can use to tweak the delays relative to your clock speed.
Yes the watchdog is good to have as an option once your program is designed and fairly stable. Basically once you have the watchdog turned on you have a period of time before the watchdog timer reaches the maximum value and rolls over back to 0. This will cause the device to reset. To keep the device from resetting simply use the following C code: clr_wdt(); somewhere in your main loop. To change the period of time before reset you can adjust the prescalar to the watchdog by writing a byte to the Option_register (I think, I know its one of them anyway probably better to find it in the datasheet). If you have delays in your program then you will have to use my beta custom delay component that will allow you to do the delay without the device resetting. Eg during the delay the clr_wdt function is called automatically for you. This does mean that my delays are ever so slightly off, there is a variable you can use to tweak the delays relative to your clock speed.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Re: Preventing Program lockups
Thanks Benj. I spent some time looking over the data sheet, and I'm still not clear on how to use the WDT.
I'm using the PIC18F258 chip. I want to set the reset period to them maximum on this chip, It looks like
that's 2.18 minutes.
This is my first time working with this would you be so kind as to outline the steps needed
to get this working.
Thanks in advance.
Ondra
I'm using the PIC18F258 chip. I want to set the reset period to them maximum on this chip, It looks like
that's 2.18 minutes.
Benj wrote:To change the period of time before reset you can adjust the prescalar to the watchdog by writing a byte to the Option_register (I think, I know its one of them anyway probably better to find it in the datasheet).
This is my first time working with this would you be so kind as to outline the steps needed
to get this working.
Thanks in advance.
Ondra
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Preventing Program lockups
Hello Ondra
The Watchdog timer is configured by using the advanced chip configuration window.
Enable the watchdog timer and set the post scalar to 1:128 for the maximum available timeout.
It seems the average watchdog timeout period is 2.3 seconds but can be anywhere between 0.89 and 4.22 seconds due to the nature of the RC oscillator driving the timer. These values are with the post scalar set to the max 1:128.
So in your program you just have to make sure you are calling the C function clr_wdt(); at least every 0.8 seconds to be sure to meet the deadline before reset. This can be done by adding a C code block to your main loop if it is running fast enough or you could create a timer interrupt that will perform the clearing of the watchdog for you.
The Watchdog timer is configured by using the advanced chip configuration window.
Enable the watchdog timer and set the post scalar to 1:128 for the maximum available timeout.
It seems the average watchdog timeout period is 2.3 seconds but can be anywhere between 0.89 and 4.22 seconds due to the nature of the RC oscillator driving the timer. These values are with the post scalar set to the max 1:128.
So in your program you just have to make sure you are calling the C function clr_wdt(); at least every 0.8 seconds to be sure to meet the deadline before reset. This can be done by adding a C code block to your main loop if it is running fast enough or you could create a timer interrupt that will perform the clearing of the watchdog for you.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Re: Preventing Program lockups
Thanks Benj, it sounds easy enough. Though when I looked in the datasheet for the PIC18F258 on page 352 I found this quote: -
The 4 ms period of the WDT is multiplied by a 16-bit
postscaler. Any output of the WDT postscaler is
selected by a multiplexer, controlled by bits in Configuration
Register 2H. Available periods range from 4 ms
to 131.072 seconds (2.18 minutes). The WDT and
postscaler are cleared when any of the following events
occur: a SLEEP or CLRWDT instruction is executed, the
IRCF bits (OSCCON<6:4>) are changed or a clock
failure has occurred.
Does this mean that the reset period can be as long as 2.18 minutes. Is the the 2.3 sec to 4.22 sec you state a limitation of flowcode? Also In the data sheet I could not find a list of the available postscalers is there another way to know the exact time periods of the reset.
Ondra
The 4 ms period of the WDT is multiplied by a 16-bit
postscaler. Any output of the WDT postscaler is
selected by a multiplexer, controlled by bits in Configuration
Register 2H. Available periods range from 4 ms
to 131.072 seconds (2.18 minutes). The WDT and
postscaler are cleared when any of the following events
occur: a SLEEP or CLRWDT instruction is executed, the
IRCF bits (OSCCON<6:4>) are changed or a clock
failure has occurred.
Does this mean that the reset period can be as long as 2.18 minutes. Is the the 2.3 sec to 4.22 sec you state a limitation of flowcode? Also In the data sheet I could not find a list of the available postscalers is there another way to know the exact time periods of the reset.
Ondra
- Benj
- Matrix Staff
- Posts: 15312
- Joined: Mon Oct 16, 2006 10:48 am
- Location: Matrix TS Ltd
- Has thanked: 4803 times
- Been thanked: 4314 times
- Contact:
Re: Preventing Program lockups
Hello Ondra
I was going via this information on the datasheet. Maybe we have different revisions of datasheet.
Watchdog Timeout Period - Min 7ms, Norm 18ms, Max 33ms
Watchdog Postscalar seems to have a max of 1:128 so it is 6-bit, this is also confirmed by PPP which gets its configuration parameters directly from Microchips library of configurations.
So maximum time is 128 x 7ms = 0.89 seconds
This is the kind of length I would expect. Ive never heard of a watchdog allowing for up to 2 or even 1 minute.
Best bet would be to enable the watchdog in a simple program and try to see how long the device runs before it resets. Eg output values to a port with ms delays in between and see where the prog gets to before it resets and starts again. This will give you a good idea of the limit on the timeout.
I was going via this information on the datasheet. Maybe we have different revisions of datasheet.
Watchdog Timeout Period - Min 7ms, Norm 18ms, Max 33ms
Watchdog Postscalar seems to have a max of 1:128 so it is 6-bit, this is also confirmed by PPP which gets its configuration parameters directly from Microchips library of configurations.
So maximum time is 128 x 7ms = 0.89 seconds
This is the kind of length I would expect. Ive never heard of a watchdog allowing for up to 2 or even 1 minute.
Best bet would be to enable the watchdog in a simple program and try to see how long the device runs before it resets. Eg output values to a port with ms delays in between and see where the prog gets to before it resets and starts again. This will give you a good idea of the limit on the timeout.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel