Searching \ for '[PIC] ICD-2 Halt On WDT?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=icd
Search entire site for: 'ICD-2 Halt On WDT?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] ICD-2 Halt On WDT?'
2006\08\24@103842 by Harold Hallikainen

face picon face
I THOUGHT there was a setting that would tell the ICD-2 to halt on a WDT
timeout, but cannot find it now in the menus. Does it exist? It appears I
am now and then getting a WDT timeout, but I don't know where in the code.

THANKS!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\24@123630 by WH Tan

picon face
2006/8/24, Harold Hallikainen wrote:
> I THOUGHT there was a setting that would tell the ICD-2 to halt on a WDT
> timeout, but cannot find it now in the menus. Does it exist? It appears I
> am now and then getting a WDT timeout, but I don't know where in the code.

No. If you read again the requirement/limitation of ICD2 as a
debugger:  WDT must be OFF in configuration.


Best regards,

--
WH Tan

2006\08\24@131020 by Harold Hallikainen

face picon face

> 2006/8/24, Harold Hallikainen wrote:
>> I THOUGHT there was a setting that would tell the ICD-2 to halt on a WDT
>> timeout, but cannot find it now in the menus. Does it exist? It appears
>> I
>> am now and then getting a WDT timeout, but I don't know where in the
>> code.
>
> No. If you read again the requirement/limitation of ICD2 as a
> debugger:  WDT must be OFF in configuration.
>


Thanks! The config window actually says "Disabled - Controlled by SWDTEN
bit". So, I think we can have it off in the config bits, but enable SWDTEN
in our code. The ICD could turn this off when we stop the program, then
turn it back on when we run our code.

I dunno, I thought I saw halt on WDT somewhere... Maybe it was back when I
was using the ICE2000.

So... How do you figure out what's causing an occasional WDT timeout? It
would be nice if all these resets were really like interrupt calls and we
could look at the stack right after the processor vectors to zero. In
normal runtime code, we'd reset the stack pointer at startup to avoid
overflows. But, during debug, I'd sure like to know what timed out!

Ideas????

Thanks!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\24@144117 by Paul Hutchinson

picon face
> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu On Behalf Of Harold Hallikainen
> Sent: Thursday, August 24, 2006 1:10 PM
>
> I dunno, I thought I saw halt on WDT somewhere... Maybe it
> was back when I was using the ICE2000.

Yes, the ICE2000 has a halt on WDT setting, very handy.

Paul  

2006\08\24@161522 by Harold Hallikainen

face picon face

>> -----Original Message-----
>> From: .....piclist-bouncesKILLspamspam@spam@mit.edu On Behalf Of Harold Hallikainen
>> Sent: Thursday, August 24, 2006 1:10 PM
>>
>> I dunno, I thought I saw halt on WDT somewhere... Maybe it
>> was back when I was using the ICE2000.
>
> Yes, the ICE2000 has a halt on WDT setting, very handy.
>
> Paul

Thanks! I'm NOT imagining things. I haven't used the ICE2000 in years
since the modules for every new chip are so expensive.

Thinking about the problem I'm having with this system (a few out of a few
thousand just decide to reset now and then), MAYBE there's nothing wrong!
Looking at http://ww1.microchip.com/downloads/en/AppNotes/00828a.pdf , it
appears the WDT timeout period increases with increasing temperature and
decreases with decreasing temperature. There is also a fairly large chip
to chip variation. I've noticed more WDT timeouts overnight than during
the day (though I stuck a unit in the refrigerator for a few hours and
that didn't seem to trigger the timeouts). So, MAYBE my code is taking
just long enough that almost all the time it makes it around before the
WDT times out, but now and then, with a particular chip, at low
temperature, it manages to time out, even though the program has not
gotten stuck.

So, that's my current thinking... I'm going to turn off the WDT on this
unit that has been resetting overnight and let it run for a few days.
First off, I expect no more resets (RCON showed me they were WDT resets).
Second, I hope, I'll find that the system continues to operate properly
(not hung in some loop somewhere). If so, I'll try adding another WDT
reset to the main loop and see how it behaves. I've already got the WDT
scaler set as high as it can go (128 on this chip).

Thanks to the list for all the help!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\24@161705 by Xiaofan Chen

face picon face
On 8/24/06, Harold Hallikainen <haroldspamKILLspamhallikainen.com> wrote:
>
> So... How do you figure out what's causing an occasional WDT timeout? It
> would be nice if all these resets were really like interrupt calls and we
> could look at the stack right after the processor vectors to zero. In
> normal runtime code, we'd reset the stack pointer at startup to avoid
> overflows. But, during debug, I'd sure like to know what timed out!
>
> Ideas????
>

Best idea: to use ICE2000 or ICE4000 or the future Real ICE when it starts
to support your chip.

Other ideas: to identify those places which might lead to watchdog overflow,
clear watchdog one place by one place. Places like long loops, dead loop
waiting for some flags, etc.

Regards,
Xiaofan

2006\08\24@172028 by Bob Axtell

face picon face
Xiaofan Chen wrote:
{Quote hidden}

The main reason that my WDT failed was that I was overrunning my
interrupt routine (took too long
inside the interrupt) so that I would miss a CLRWDT. Scope out your int
routine to see if you are in it too long.

--Bob

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...