rtos and watchdog

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Hello all,

I've searched the forum posts for an answer to my question but there doesn't seem to exist any.

I've designed a solar powered remote temperature sensor by using 16f628 and DS1822. To give it a try, i've used the CCS RTOS for the first time. The program works fine, reading the temp from DS1822 and printing it on a 5x7 dot matrix led display (which is located sideways) by using smaller fonts that 2 can fit side by side on the display.

the power is supplied from a very small solar panel, stored on a 1.2V nimh AA type cell. The 1.2v is switched up to around 3-5v to run the micro.

the power is very unstable, so i'm having reset issues. The MCLR is enabled and connected to VDD by a 4k7 resistor.

To have a proper reset, i've used the watchdog in my previous designs and they perfectly work for years.

But in the RTOS, the system seems constantly resetting itself and restart_watchdog() seems to be useless. my wd period is 2304ms.

is there something wrong with the RTOS-WATCHDOG couple?
_________________
www.endtas.com

Wayne_ · Joined: 10 Oct 2007 Posts: 681

So you have a system which worked for years, so what is the difference ?
You are trying to use the RTOS system and it does not work!
You say you have reset issues BUT if the hardware is the same as the system that worked for years then this should be OK ! NO ?
Your original system, if suffering from reset issues may have been written to account for it and save/load data for reset recovery.
An RTOS system does not recover from a reset, it resets.
Using the Watchdog is only good for recovering from hung software (stuck in a loop) due to bad coding or a hardware problem. This does not resolve reset issues unless it is the watchdog that is causing the reset, inwhcih case you need to look at your software to find out what part of it is taking up soooo much time.

You need to try and find out if it is the watchdog which is causing the reset or as I suspect the hardware.

If it is the watchdog then you have a loop or interrupt which does not allow for the watchdog to be reset. Are you using the RTOS correctly. I am assuming it is not an interrupt driven RTOS but a task driven one. Each task will need to reset the watchdog or release RTOS control to another task which does kick the WD before the WD resets.

hobiadami · Joined: 17 Oct 2006 Posts: 35 Location: City of Concrete

Matro · Guest

An RTOS should provide its own "software" watchdog that should be used instead of the hardware watchdog of the PIC.

Matro

Wayne_ · Joined: 10 Oct 2007 Posts: 681

"so a programmer must be careful with how much processor time a task uses for execution"

Unless you specify the max parameter in the #use TASK settings then a task may take longer to execute than the RTOS rate. You either need to ensure your task yields processing to the RTOS to allow the WD kicker to run or you need to kick the WD in the task.

If you specify max then the compiler will work out the timings of the task and inform you of a problem.

It seems also possible that another task may start running just before the WD task is set to run. If this task then takes too much time (which is valid) the WD will be late and it will have reset.

You will need to check your timing.
BUT, you may still find it is not the WD resetting the device. You can check the reset cause by checking a flag on the pic. The first reset should be power on, reading the flag at the next reset will tell you if it was the WD.

Do any of your tasks have infinite loops in them ?
Do any of your tasks have large loops or delays ?

1 option, Double the rate of the WD task to see if this helps.