• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Interesting Microchip WDT Dilemma

Status
Not open for further replies.

MrAl

Well-Known Member
Most Helpful Member
Interesting WDT Microchip Dilemma, mid range series chips like the 12F675.

If the WDT is enabled and the chip is never put to 'sleep', the WDT triggers a reset which causes the code to start over at the very beginning, thus initializing all regesters.

If the chip is put to sleep at regular intervals that are less than the WDT timeout time, then the device will wake up at the current section of code and continue with whatever followed the sleep and a nop. Thus if the timeout period is greater than the time between last wake up and next sleep, it wakes up and continuse with the code and does not reset the chip.

The problem is, if the time between the last wake up and the next sleep is too clsoe to the WDT timeout period it may work many times over again but then one day start resetting the chip because the WDT timeout period decreased due to supply variation or temperature change. This means the time between last wake up and next sleep should be significantly shorter than the WDT timeout period.

Does this sound right or is there a way to disable the WDT somehow without disabling it completely with the OPTION register?
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
There is a section about this in the datasheet for the mid range devices...

upload_2016-9-26_12-18-58.png

It seems like you have no option but to clear the watchdog before AND after the sleep command!!

I have moved to the pic 12f1840 so I have the sw watchdog... I can just switch it off after sleep and switch it back on just before sleep!! Microchip obviously recognized this issue, and put it to rights...
 

MrAl

Well-Known Member
Most Helpful Member
There is a section about this in the datasheet for the mid range devices...

View attachment 101360

It seems like you have no option but to clear the watchdog before AND after the sleep command!!

I have moved to the pic 12f1840 so I have the sw watchdog... I can just switch it off after sleep and switch it back on just before sleep!! Microchip obviously recognized this issue, and put it to rights...
Hi there Ian,

I think it is actually worst than that right, or do i misunderstand this?
It appears that the WDT timeout clock starts right after either the clrwdt or the sleep command. That means that if i do a clrwdt it's not enough because if the timeout period is set for say 100ms and i call a delay of say 200ms right after the clrwdt, the wdt will time out and cause a reset. So what i had to do was insert some clrwdt instructions in various places in the code just to keep the wdt from timing out before i really wanted it too after a sleep command. Does that sound right?

Oh yes that newer chip sounds interesting, very interesting. There is one catch for me though, i would have to purchase a new programmer which i guess is PicKit 3 ? Right now i only have the very first one, the PicKit 1 and that has been sufficient for my needs so far. I had been able to trick it into programming more chips than it was made for, but i doubt those tricks will work with this new chip as it is much more advanced. What is that PicKit 3 selling for these days?

Thanks.
 

NorthGuy

Well-Known Member
This is generally the purpose of WDT. You keep calling clrwdt and if you miss a beat then something is wrong with your program and the chip must reset.
 

MrAl

Well-Known Member
Most Helpful Member
This is generally the purpose of WDT. You keep calling clrwdt and if you miss a beat then something is wrong with your program and the chip must reset.
Hi,

Yes i agree, but that would be like a "mode 0" where you want to make sure that if something goes wrong the chip will reset.
However, if there was a "mode 2" then you have the option to turn that off in places where you know the code cant fail.
I think that is the idea with the newer chip Ian was talking about. I would jump right to that chip but my programmer is not capable. Perhaps i will look into the PicKit 3, but also check the pricing on the newer chip to get an idea what it costs. I also see it has a lot of other functionality too.

Note: i see it's around 1 dollar each, and comes in the 8 pin dip package too. Nice.
PicKit 3 around 50 dollars though, USD.
 
Last edited:

MrAl

Well-Known Member
Most Helpful Member
If the chip has to be woken by the WDT and a external interrupt! what the worst that can happen if you clrwdt after the wake up??
Hi,

If i understand you right, if the chip wakes up and then clrwdt, that's fine, it's what happens next that i think is the problem.
If the program does not get another clrwdt before the wdt timeout period, i think the wdt resets the chip back to address 0000.
If there were any registers initialized then they will get initialized again, which would clear all the data read from anything or generated internally, which of course would only work in some applications.

The max prescaler value is 128 which gives a wdt timeout period of about 2.3 seconds, but we have to realize that is not an exact time period it could vary considerably according to the data sheet. That's part of the issue, but the main issue is that say we have the following pseudo code:

initialize [ox0000]
startmain [ox0050]
LoopA
clrwdt
codeblock[0x0060] [takes from 1 to 3 seconds to execute the entire code, modifies reg AK]
sleep [about 2 seconds of sleep]
nop
clrwdt
goto loopA

In the above, a register AK is initialized to 0x00, the prescaler is set to max which is 128 which is about 2 seconds. Then start main.
We enter the loop, clrwdt, then exectute the code block, then sleep. When it wakes up it does a clrwdt, then loops again.
But that only works if codeblock takes from 1 to near 2 seconds to execute.

If codeblock takes 3 seconds, this is what happens:
Enter loopA, clrwdt, wdt timer starts. codeblock takes 3 second, but never gets to finish because wdt times out and causes a reset after about 2 seconds, so it jumps back to initialize, which makes register AK zero again when it should have the last value given to it in codeblock.

That's the way i understand it anyway. What happens in the MPLAB IDE is the wdt keeps timing out and stopping the code execution at some unusual place and a warning comes up on the screen that states that the wdt timed out. That's if the time between clrwdt instructions is longer than the wdt timeout period. If i insert more clrwdt's i get no interruptions, unless of course it reaches a sleep instruction.

What this means for longer delay function calls (like maybe 500ms several times is that just before the call i have to do a clrwdt, but if the delay is longer than about 1.5 seconds i have to incorporate a clrwdt right in the delay loop so it keep clearing it to prevent the reset.

It's too bad they did not make that an interrupt vector. That way i could detect that it was the wdt and just return back to the code when needed. I dont know yet if this is possible using the restart 0000 vector. That's the worst choice i think.
Maybe there is some way around this though.
 
Last edited:

MrAl

Well-Known Member
Most Helpful Member
I take it you can't place a clrwdt in the codeblock function to ensure this doesn't happen?

Hello again Ian,

Well, yes i can do that, and that's effectively what i ended up doing. But it is a little tricky because i have to make sure that the time between clrwdt's is short enough and that makes it just a little bit more trouble to write the code. I can put it in my delays too and then i have to adjust the delays if they have to be precise.

I guess i was hoping for a better way. The only other way i can think of is to use a timer to generate an interrupt and have that execute a clrwdt, but that would tie up a timer too.

The real kicker is what i am doing now is using a somewhat long time for the wdt, like 2 seconds. But if i had to have a shorter wdt timeout period like 0.1 seconds then i'd really have to be careful to call clrwdt frequently enough.

I see the newer chip you mentioned has four wdt modes. That seems better. One of them allows turning off the wdt when not needed and turning it back on when needed. That's the ultimate :)

You know what is funny though. So many bits to be set in the 12F675 and they coouldnt add ONE more bit in a register to control the wdt enable. Strange. I guess they did not think about this back then.
 

MrAl

Well-Known Member
Most Helpful Member
Hi,

Oh ok then i guess what i am seeing is the neanderthal version in the evolution of the PIC :)
Makes sense.
 

MrAl

Well-Known Member
Most Helpful Member
Hi again,

Oh yes, that 1572 chip looks interesting too. Nice features, but what's up with that FIVE bit DAC? 5 bits? I would think 8 bits would be the min, and 10 bits would be nice, and 12 bits really nice. The ADC is 10 bits.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
I never really have an issue with 10bit ADC..... I use the speed of the device to interpolate up to XXX times more..

I know some will say that it isn't "proper" and 10 bit is still 10 bit, but I don't find that... I oversample 24 times, then I get really good stable results... My voltages don't change much so I really can use the noise to steady my outputs..

The 5 bit ADC is really only for voltage referencing... If you want an 8 bit DAC then the pic16f17xx is for you..
 

MrAl

Well-Known Member
Most Helpful Member
Hi,

Oh that chip sounds good too. Know any with 12bit ADC and maybe 12bit DAC too?
 

MrAl

Well-Known Member
Most Helpful Member
Hi,

Oh ok, well i guess i am still stuck with external little dev boards for that stuff then or raw chips. Thanks.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top