AVR-Chat

Even more fun..

I decided to trap this condition at boot, and force the WDT off in code.

I'm uploading a file, MADWDT.PNG that shows a screen cap.
At the first breakpoint, I'd run the code, and let it reset on it's own.
The contents of Temp (R24) at that point was 0x00, which says that the chip has no idea why it got reset! AFAIk that shouldn't even be possible.

At the second breakpoint, you can see that I've set up the WDT in a fairly normal fashion. Disabled, slowest clock, and interrupt enabled rather than reset. But on the right, the clock prescaler does not match what I programmed, the WDT is enabled, (though it DID take the WDIE).

In ASM, I would have done it slightly differently, loading up the values first, then setting WDCE, and loading the values in the next instruction, but this is close enough since I have four cycles to get there.  In simulation, this WDT code works fine.

If I step this through with the ICE, I can see it load up the values and attempt to set the WDT, but it isn't happening. 

If I let it run, it will not hit the breakpoint I have on the WDT interrupt vector, it just ends up back at the initial breakpoint with 0 in MCUSR again. 

Again, the only reason I'm doing any of this at this point, is that somehow the WDT is always enabled, despite my erasing the chip, explicitly setting the "always on" fuse to off, and not enabling the WDT in code till after all other inits, just before main.

Yet more fun with tools..I've noticed two new things in the last couple days.

1: WDT always on, even though the chip is NOT programmed for this.
Do a build and run, or reset, and notice that the WDE bit is on at reset.
Go out of debug, into programming, check the fuses, and WDT always on
is NOT set.
Then SET the fuse, and Reset the fuse, no help.
Erase the chip.. No help..


2: Do a build and run, and after the chip is programmed, it boots up
running the previous software version(!) indicated by a screen message
that does not exist in the current build.  I verified this by checking
the hexfile for the text.

Sometimes, completely exiting studio, resetting the target, and
powering off the ice will "fix" these for a while, sometimes not.

Can anyone suggest a workaround?
Target is a 20 MHz M644.


-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

At 01:03 AM 9/04/2009, you wrote:
>Even more fun..

The craziest thing that happened to me this week with the
JTAG Ice Mk2 is that the new code would NOT upload into the
chip, the old code kept on running happily for a good half hour.

This was working code (yep in C...). The embarrassing thing is that
the last time I did any work on the project I must have switched
to simulator (got vague recollection of this) for some reason.

Switching back to JTAG Ice Mk2 "FIXED" all my problems........
Not saying that you are as crazy as me but..

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

> Switching back to JTAG Ice Mk2 "FIXED" all my problems........
> Not saying that you are as crazy as me but..

No. I'm definitely in the emulator.
I've switched over to sim to verify that my WDT code works, which it does.
The emulator is loosing control of the target frequently, and appears
to not load the firmware properly at times.

I have other emulators, serial based Jtags, both Atmels and clones,
that act in similar ways.


Look at the pic I uploaded.  How do you get to that state of the
WDTCSR bits having just executed the code shown?


-- 
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.

--- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...> wrote:
> Do a build and run, or reset, and notice that the WDE
> bit is on at reset.
It is worth noting that on many (perhaps all) newer devices, the WDE bit is not affected by reset, no matter the source.  Once you turn it on it stays on until you execute the procedure to turn it off.  I know that the mega644, mega644P, mega1284P, mega1280, mega1281 and mega328P are like this but the mega32 is not.

You can determine if your device is among those that act this way by checking the datasheet description of the register containing the watchdog enable bit.  Where it gives the "initial value" you'll see either "0" or "X" where the latter means that the bit is not cleared in response to a reset.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

> You can determine if your device is among those that act this way by checking the datasheet description of the register containing the watchdog enable bit.  Where it gives the "initial value" you'll see either "0" or "X" where the latter means that the bit is not cleared in response to a reset.

Right, but if I click it off in studio, or program it off in code, it
should STAY OFF till I turn it back on.


-
There is no computer problem which cannot be solved by proper
application of a sufficiently large hammer.