Dragon problem coming back out of debugWire

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have had a problem with my Dragon. I am using ATMega328p devices.

I have a ZIF socket soldered to the Dragon. I have short jumpers to the ISP header.

The Dragon works fine interfacing to the uC with ISP. It has no problem setting fuses, reading them back, or reading the Device ID.

But about half the time when I go into debugWire mode and try to come back to ISP mode, I lose the ability to communicate to the uC. Cycle the power by unplugging and re-plugging the USB cable. I close and restart Studio 4. But nothing can communicate to the uC. I try to just start debugging (assuming that it is still in dW mode) but that fails too.

I have to HVPP the device. It appears that somehow the fuses are set to use an external oscillator, but I never changed the fuse after setting them initially in ISP mode, and selected the 8MHz internal osc without the CKDIV.

What might be causing this problem and how do I prevent it from happening again? It is a pain in the neck to set all the 21 wires for HVPP!

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Recently there was this thread: https://www.avrfreaks.net/index.p...
Simular issues. Hmmmm.

Time to investigate.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dont know if this is any consolation, but I just did a project with a mega48 in DW connected to the dragon. While I was running debugwire I had no issues. Code worked fine once I ironed out the bugs, but I was unable to change anything to release from debugwire. Since the part was a DIP, I just threw it in my STK500 and HVPP the puppy back to factory, enabling ISP and then dumped in the code without setting enable DW

Not a solution, but misery likes company....sometimes ;)

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I asked David Prentice for help. In the mean time I will do some tests with a Mega88 (closest I have to your Mega48, Jim) and an old style Dragon.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From Spamiam's post it appears that his AVR lives on the Dragon rather than on an external pcb. I presume this means lots of spaghetti to hardware on a breadboard.
This may have reliable comms between the Dragon and AVR, but horrible for the external connections.

Quite honestly, debugWire works very well. You follow the Studio prompts religiously to enter or leave debugWire. Note that if your AVR is powered by the Dragon, Studio 5 can NOT leave dW. Studio 4 should be ok.

It is very easy to panic when you forget which mode you are in. You should never need to HVPP.

If you do get stuck, just use a new AVR. The dW AVRs are not expensive. Mail 'dead' ones to a neighbour with a STK500 or rig up a Dragon for HVPP.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David.

My findings so far:
1. Connecting the Dragon to the PC through a USB-hub proved to be a problem. AS4 couldn't start a debug session: it reports it cannot connect to the Dragon. So I skipped the hub and used a direct USB connection: problem solved.
2. On my targetboard was a 1k resistor in series with the /Reset-line. No problem for ISP, but a stopper for dW. The 10k pull-up seems no problem.

As David suggested: follow the prompts from AS4. It it says: "Cycle power to the target", then DO so.

I will give it some more testing.

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So far I tried two methods:

Method1:
1. Program target using ISP of Dragon.
2. Close the ISP window. Windows chimes twice: the first (quint down) disconnects the Dragon's ISP mode, the second one (quint up) for re-connecting to Dragon.
3. Goto Debug, Select Platform and device ... choose Dragon and your AVR, hit Finish
4. Now click the green triangle in the titlebar. Windows responds with
"AS4 response1.png" as attached.
5. Now you need to choose the radio-button of "Use SPI to enable debugWIRE interface" ; now click OK (sidenote: SPI is a confusing term: should be ISP)
6. Cloink. Windows shows "AS4 response2.png"
7. Cycle the power to the target as it asks you to do. And then (not earlier) press OK.
8. The lights on Dragon do blinky blinky, AS4 opens debug windows.

We are fine. And can set breakpoints and stuff

To get out of dW mode: don't click the blue square: that will stop debug mode. Instead do this:
1. Go to Debug menu, choose "AVR Dragon options ... ", first tab. See "Dragon options.png"
2. click "Disable debugWIRE"

Attachment(s): 

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

Last Edited: Thu. Mar 15, 2012 - 01:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Max = 3 pictures, so I continue here)

3. see "Need ISP.png"
4. Hit OK. Two chimes once more.
5. Windows shows leaving "debugmode.png"
6. Hit OK
7. Hit OK

Note that I did not remove the ISP cable. If the SPI-pins are used in your program, you do need to disconnect the ISP connector and connect just the three wires needed for dW: Vcc, Gnd and /Reset. Simply follow AS4's prompts.

The second method just involves setting the dW fuse when still ISP programmer mode. Procedure is quite simular.

While writing this procedure, I went into dW mode and exited dW mode several times: no problems.

Crucial: To get out of dW mode: don't click the blue square :!: :!:
Instead do this:
1. Go to Debug menu, choose "AVR Dragon options ... ", first tab. See "Dragon options.png"
2. click "Disable debugWIRE"
etc ... as described in the previous post.

Bedtime here. I hope it helped.

Attachment(s): 

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tips Nard, but you did not need to for me at least.

It's good to know the better way though so this tidbit is going into the jgmDESIGNS help folder I have.

@spamiam,
If you need a bunch of chips reset I have an stk500 so I would be more than happy to reset them for you

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It's good to know the better way
Which way did you do it?

I simply do "Build and Run" (1st time and EVERY subsequent time after fixing bugs or adding more code).

The 1st time when using a new chip or a chip where DW is disabled the "AS4 response1.png" and "AS4 response2.png" come into play, then nothing else until I decide to stop debugging (1 minute, 1 hour, one day, one month, one year...never) then "Dragon options.png" comes into play.

Tha..tha..tha..that's all folks.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The King's method is what most people would use. i.e. Start project, debug. When the project is perfect, leave debugWire mode.

Problems arise when you have no coherent plan.
Either enter/debug/leave every day you are debugging.
Or enter/... debug ... /forget about it.

A handy tip might be: put a sticky label on your DIP chip when you enter dW. Remove when you leave dW.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Thanks for the tips Nard, but you did not need to for me at least.
I know. But these things intrigue me. And it may be helpfull for SpamIam and tomjoad2000 (from another thread)

jgmdesign wrote:
It's good to know the better way though so this tidbit is going into the jgmDESIGNS help folder I have.
Hahaa .... You have such a folder too :) I couldn't do without.

Cheers

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I usually get into and out of debugwire mode as Nard indicated. When I saw I was having trouble getting out of dW mode, I did simply put the M328P on the ZIF socket on the dragon. I did use jumpers, about 8cm long which has not been a problem in the past. I then tested the system simply by setting fuses on the HVPP recovered chip to 4.7V brownout, 8 MHZ internal oscillator, uncheck the CKDIV bit. After setting the fuses, I still had perfect ISP communication. I could then go INTO dW mode without trouble, I could program and re-program, and debug with no problem. Then when I told it to leave dW mode as Nard indicated. After it tried to leave dW mode, I then got the error saying it was having trouble communicating.

Later today I am going to cannibalize a hard disk parallel cable and convert it into a parallel programming jumper.

I have NOT been using a powered hub and I thought thatg maybe it could be a voltage brownout issue.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tony,

Quote:
I could then go INTO dW mode without trouble, I could program and re-program, and debug with no problem. Then when I told it to leave dW mode as Nard indicated. After it tried to leave dW mode, I then got the error saying it was having trouble communicating.
Do you want to investigate this further ? We could compare HW revision and SW versions f.i.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I note that you said you are using Studio4. This should leave debugWire even if you power your AVR with the Dragon. I recommend a real USB port.

If you use Studio 5, you cannot leave debugWire if you are powered by the Dragon.

The 'leaving' process involves issuing a dW command and then an SPI command without a power-down.

In its wisdom, Atmel powers down the Dragon in Studio5. External power to the AVR should work fine.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is correct. I am using Studio V4.something, I think it is 4.18, but I have to check. I have not used this particular computer for the dragon before. It is running Windows XP. I will try it on my other computer which has done Dragon debugging, but it was recently upgraded to Windows 7, and I am not sure wheter I used the dragon on the dragon on that computer with w7 too. I will try it out. The parallel programming jumper was made last night. I will be able to HVPP these chips pretty easily now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using AS4 4.18 too, WinXPSP3.

Do you power the target from the Dragon ? How much current does it take ?
If you're done with the subject, just say so and I will not bother you anymore.

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I am not done with the subject. But I am starting to suspect that either I have several oddly damaged chips, or the Dragon is malfunctoning.

I got my cannibalized disk drive parallel cable working well for HVPP. I could then quickly repair a bricked uC.

I found that when I have an unbricked chip, I can program and set fuses perfectly and repeatedly. But when I go into debug wire, and get the message to cycle the power on the target (by unplugging the USB cable of the Dragon), then when I repower the Dragon, it cannot start debugging. It re-asks to either retry or enable dQ via "spi". Both those options fail. ISP no longer works either. I cang get into programming mode to re-enable ISP.

When I do HVPP I see that debug wire and ISP are both enabled in the fuses (as they ought to be, I think). The resto fo teh fuses are correct as well. If I clear the dW fuse, then I can get the uC to communicate via ISP again.

I only am drawing a few mA from the Dragon because I only have the m328P sitting in the ZIF socket on the Dragon. I have nothing else powered by the Dragon.

So, I think I have something wrong with the Dragon!??

I verified that I am indeed running studio 4.18 and it is a PC running windows XP. It is a first generation Dragon.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But when I go into debug wire, and get the message to cycle the power on the target (by unplugging the USB cable of the Dragon), then when I repower the Dragon, it cannot start debugging.

When did it ask you to unplug the Dragon?

It is the AVR that needs its power cycling.

As you have noted, the AVR is correctly in dW mode.
You could have equally well switched off your PC and bench for a good night's sleep.

In the morning, your Debug session would have started immediately (without any prompts).
This same happy situation would continue for months on end a la Samperi.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem solved :)

You've defenitely got excellent teaching qualities, David ! Thanks.

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, well, I wish my problem were so simple. I have traced down the exact setting that causes problems. The problem is the brown-out detection. If I set it to anything other than the 4.7 volt level, then I can enter and leave debug no problem.

If it is set to 4.7 for the brownout, then it enters dW mode, and the fuses are properly set as seen in HVPP mode. But Studio says it can not communicate with the M328P device. When I reset the brownout fuse to 2.7V in HVPP mode but leave everything else untouched, then it will work properly in dW mode.

I tried it on 2 different computers and with a powered USB hub. All with the same results.

When I read the "hardware" voltage of the Dragon in the "connect to the programmer" window, it tells m that it reads 5.0v. Apparently the m328 disagrees! I have removed and reset all the jumper wires to test for a bad connection, esp on the VCC and GND wires.

No change.

So, I just have to run the device with the 2.7v brownout for now. DO you think that the Dragon is the problem? Multiple uC's exhibit the same behavior.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

4.7V??? I think the highest is 4.3V.

So what is your VCC? If the Dragon says 5V then IT IS reading 5V from pin 2 of the ISP header?
What is that connected to?

I have used the Dragon with 5V supplies (BOD4.3V) and 3.3V supplies (BOD2.7V).

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am no fan of powering a target from the Dragon or even the STK600. And always make sure that the Dragon is powered BEFORE the powered target is connected to it. And I think that may be the reason that I never had any problems with my Dragon.

Tony, do you have proper decoupling on the powerpins of the targetAVR ? 8cm is small in the human-sized worls, but with the high slewrates on the signals it is a lot.

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
4.7V??? I think the highest is 4.3V
.
Oh, yes, sorry. I meant 4.3V.

Quote:
So what is your VCC? If the Dragon says 5V then IT IS reading 5V from pin 2 of the ISP header?
What is that connected to?

Pin 2 of the header goes to one of the VCC pins on the VCC/GND header on the Dragon. Another VCC pin on that header goes to the target VCC pin at pin7 as per the Dragon connection diagram for the m328p.

Quote:
do you have proper decoupling on the powerpins of the targetAVR ?

I do not have any decoupling on the power pins when the uC is in the ZIF socket mounted to the Dragon.

I tested the voltage at the VCC header on the Dragon, and it is the expected 5.0v as reported by the dragon itself.

I can try powering the target, in the ZIF socket, from an external 5V and see what happens. I have not had this trouble before, even with the same jumpers and no decoupling, but I have not done a LOT of dW debugging....

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Powering the target system through the dragon is a major no no. I believe the techinical term is 'potential POOF'

I have powered target systems with my STK500 but kept it below 250ma.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I wouldn't call it a "system". Just the target uC alone. No other stuff attached at all. The Dragon instructions show how to hook it up, so, it would appear to be approved by the factory....

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
Well, I wouldn't call it a "system". Just the target uC alone. No other stuff attached at all. The Dragon instructions show how to hook it up, so, it would appear to be approved by the factory....

-Tony


Good point, Tony.
But how to cycle power of the targetAVR ? Remove it from the ZIF-socket, and put it back again while the Dragon is still powered by the PC ? I guess so :?

But because you encounter the problem when brownout is set to 4.3V, prooves, or at least shows, that the targetAVR sees a dip/drop in the supply and resets consequently.
8cm are nice sized jumperwires but as said before: in terms of decoupling those are looong.
When you put (piggyback) decoupling capacitors on the DIL-package and try again, you could proove that decoupling *is* the problem. Btw, do you connect both grounds of the M328, and AVcc as well as Vcc ?
My Dragon is in a housing and the shortest jumperwires I have are 20cm. So that's no fair test environment.

Edited

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But how to cycle power of the targetAVR ?
Put a switch in series with ALL the leads goin to the chip?

I can see a possible failure mode if the Dragon is unplugged while it is waiting for the AVR to have it's power cycled as David pointed out in page 1 of this thread. Studio doesn't need much propmting to crash as it is without users not following directions.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plons wrote:
Good point, Tony.
But how to cycle power of the targetAVR ? Remove it from the ZIF-socket, and put it back again while the Dragon is still powered by the PC ? I guess so :?

Actually, I just pull the usb cable from the computer to depower the entire Dragon, then plug it back in. When going INTO dW mode I need to close Studio and re-open it too.

Quote:
Btw, do you connect both grounds of the M328, and AVcc as well as Vcc ?

No, only pins 7 & 8 are connected, again as per the connection diagram for the m328 family on the Dragon. (I was surprised about this too!)

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Actually, I just pull the usb cable from the computer to depower the entire Dragon, then plug it back in.
I think that is causing the problem: cycle power to the targetAVR only. Take it out of the ZIF-socket and put it back in. But you need to be very carefull since power is still present on the socket.

Quote:
No, only pins 7 & 8 are connected, again as per the connection diagram for the m328 family on the Dragon. (I was surprised about this too!)
That is odd indeed.

And then the matter of brownout triggering a reset: without decoupling capacitors it can be expected.

I don't use the ZIF-socket on my Dragon. Maybe you should do so too.

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is probably the most pointless post ever.
The OP is unlikely to take any notice of it.

Here goes:

To disable debugWire, you first give a debugWire leave_dW command. While AVR is still powered you can use SPI to clear the DWEN fuse.

So you can never disable debugWire if you remove power from both AVR and Dragon. When power is restored, the AVR will come back in dW mode.

This is the fundamental problem with Studio5. It opens and closes the USB to the Dragon. This in turn enables / disables the 5V o/p.

You should not have too much problem enabling debugWire with your 'pull the cable' strategy. You just won't be able to start debugging.

However after a good night's rest, in the morning your AVR debug session should start without any irritating prompts.

Mind you, if you do not read the prompts, you possibly do not get irritated.

Note that you need ever worry about the nitty-gritty of enable_dW or disable_dW. Studio, C-SPY, CrossWorks look after it for you. However the prompts are there for a very good reason. (I have a lot of sympathy for non-English speakers)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
This is probably the most pointless post ever.
The OP is unlikely to take any notice of it.

Well, I AM the OP and I AM taking notice of it.

I agree that cycling the entire dragon's power should be OK because the CPU stays in dW mode until the DWEN fuse is reset, regardless of power cycles.

As long as the brownout is not set to 4.3v (on a 5V supply), then everything works fine. If I do have 4.3V set then, at least with the CPU on the dragon, I can't communicate with the CPU. I will try it out on an external, properly bypassed board and see what happens.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
david.prentice wrote:
This is probably the most pointless post ever.
The OP is unlikely to take any notice of it.

I agree that cycling the entire dragon's power should be OK because the CPU stays in dW mode until the DWEN fuse is reset, regardless of power cycles.

-Tony

I rest my case !!

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I agree that cycling the entire dragon's power should be OK
But I DON'T!! And I think David doesn't either. By unplugging the Dragon you are interrupting the sequence of events both Studio and the Dragon expect with possible unknown consequences.

Put a switch in the VCC lines to the chip, one or 2 100nF caps on the VCC lines soldered to the bottom of the zip socket and try again.

I have used Dragons ever since they come out and never had any issues.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
I agree that cycling the entire dragon's power should be OK
But I DON'T!! And I think David doesn't either. By unplugging the Dragon you are interrupting the sequence of events both Studio and the Dragon expect with possible unknown consequences.

Well, it definitely does crash Studio! I cycle the USB connection and Studio itself.

I am wary of pulling the chip out of the powered ZIF socket. That is why I cycled power to he entire Dragon. OTOH, I am also wary of switching just VCC or GND with the inputs to the other pins in an unknown state. I have successfully powered one of these devices by back-flowing power through one of the regular pins. I bet the uC was not happy about it, but no permanent damage was evident.

Quote:
one or 2 100nF caps on the VCC lines soldered to the bottom of the zip socket

I'd love to, but I use the same socket for other size chips where the power pins are in a different location. It might be easier to solder a SMT cap to the top of the legs!

Quote:
I have used Dragons ever since they come out and never had any issues.
Which power signals do you switch when you de-power the uC?

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, neophyte question: does it really need a power cycle or just simply a tug on _RESET?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Which power signals do you switch when you de-power the uC?
The ENTIRE target board as I don't need to use the Dragon's prototype area. :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

STRICTLY NOT FOR OP's CONSUMPTION

clawson wrote:
Sorry, neophyte question: does it really need a power cycle or just simply a tug on _RESET?

DWEN needs a power cycle to start working. i.e. if the DWEN fuse is programmed, the AVR will power-up in dW mode.

When in dW mode, a dW command can 'leave dW' and hence use the SPI interface to disable the DWEN fuse while still powered. You must NOT power-cycle or it starts in dW again.

You have a similar situation with all fuses. i.e. when you change the values, they do not take effect immediately:

from m48A/48PA/../328P data sheet.

Quote:
27.2.1 Latching of Fuses
The fuse values are latched when the device enters programming mode and changes of the
fuse values will have no effect until the part leaves Programming mode. This does not apply to
the EESAVE Fuse which will take effect once it is programmed. The fuses are also latched on
Power-up in Normal mode

This is why you can change clock fuses and not realise you are dead until later.

David.