DebugWire/Dragon Wierdness

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

Not a question, but thought others might be interested...

 

I've always had difficulty getting into and out of debugWire in AS6.1 with my Dragon.  Maybe that's pretty much typical--I haven't gotten any replies here when I asked for a step by step procedure.

 

But now I'm seeing something that suggests I have (and maybe always have had) a Dragon  hardware problem...

 

I've been chasing what looked like "bus contention" on the MISO signal from SPI peripherals to the Atmega328p.  The signal is shared between two NRF24L01 transceivers, but only one is enabled at a time by their associated csn signals.  It looks like bus contention since the down level output is only around 1 volt when driven from one transceiver, about 1.1V when driven by the other.

 

I've not noticed this until now, since that down level is apparently low enough to be recognized as a logic 0 by the Atmega.  The code executes properly.  But, I needed to go after what's causing it--I thought maybe I had a firmware bug that had both chips on the SPI bus enabled at the same with one driving high, the other low.  This would result in some intermediate voltage level like I was seeing.  Or perhaps the Atmega didn't really have the MISO pin configured as an input.  

 

Or, maybe a hardware short on my pcb from Miso to through something resistive to +5.

 

However, I just noticed that when I remove the header from the dragon, the MISO down levels look good--essentially zero volts.  It doesn't matter whether the dragon is in debugWire or SPI mode--the MISO voltage level is never below 1 volt (but communication on the SPI still works with the marginal down level).

 

Next I used a six pin header in the socket from the dragon and measured between gnd and MISO--there's 1.2 volts DC.  Should be floating or relatively high impedance.  

 

I was going to try to use a resistor to pull it up and down to get the source impedance that the Dragon is driving MISO.  But first I took a close look at the Dragon under  a microscope.

 

I found a six pin part "tombstoned" just above the Mega 128 and just to the left of what looks like a Xtal on the Dragon.  I touched that part with my finger, and it just fell off.  Solder bumps on the lands look like they never reflowed to the pins on one side.

 

I'm tempted to solder the part back on the board, but don't want to void any warranty that might exist on the Dragon.  I'll have to search my email folders to figure out who I bought it from and how to check for warranty, unless Atmel will make it good for me.

 

Anyone had experience getting replacements for defective debugging hardware?

 

 

 

 

 

 

 

 

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

If you bought it within the last 12 months,   I am sure that the Distributor will replace it.

 

If it is older than 12 months,   Atmel might replace it if you gave them serious grief.

 

If you have had the Dragon for a while,   I would simply buy a new Dragon or ATMEL-ICE.

Yes,   I would attempt soldering it first.

 

David.

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

I bought it from Mouser in 10/2013.

 

I called them--90 day warranty only.  They promised to sent email with an Atmel email address to see if they (Atmel) would cover the obvious manufacturing defect (Vikings.avr@atmel.com)

 

Meanwhile, I tried the Atmel website.   Found a local (Raleigh) office to contact,  but no answered the phone at 3:30 p.m. on a Friday.

 

There are no pin 1 markings on the part's footprint on the pcb.  The part looks like it's marked with AH3, but I haven't found an 8 pin part in this package that would match an AH3 designation.    So, I have a 50/50 chance of soldering it  back on the right way.

 

I can actually use the Dragon as it is to debug code--the Atmega recognizes the 1.2 volt levels as logic zeros (at least with the 5 volt Vcc I'm using).  So, if "Vikings" won't make it right, I figure I'll ignore the flaky MISO logic 0 levels, get this project's code stable, then try soldering the part on with hot air gun.  If no luck, l'll have to order a new Dragon and eat the $50.  Maybe I should just do that any and save the hassle.

 

I looked at the overall quality of the Dragon SMT reflow and saw no other obvious issues.

 

Dave Thomas

Last Edited: Fri. Sep 12, 2014 - 10:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you identify the location on the pcb with a photo,   another Dragon owner can tell you which way round any lettering is orientated.

I doubt if any online photos have good enough resolution to read SMD legends.

 

I suspect that it is a overvoltage protection chip.

So you lose the protection if it is missing but it should not affect the normal voltage levels.

 

David.

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

Cool, I’ll do that.  But it’s really hard to see the part labelling.  Takes at least a Diopter lens and changing the angle of lighting to even see the part markings.

 

Not tonight, first thing Sat morning.

 

But, if it's just the overvoltage protection, that won't fix the "MISO being driven to 1.2 volts" issue.

 

Thanks!

 

Dave Thomas

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

Found this:

 

 

http://asf.atmel.com/bugzilla/sh...

 

Got a fault message stating that it was not possible to enter debugWire mode.
Tried a few times, with same result.
Then I used ISP programmig to enable debugWire on chip by changing fuses.
Now debugWire debuging works.

Yup, that's what I always see. Part of why I asked for the step by step into/out of debugWire mode.  

 

Workaround for debugWire:
Do not use 6pin ribbon cable connected to ISP connector, instead use only 3
wires: VCC, GND and RESET. After manually enabling debugWire by changing fuses
using ISP-programming. Start debug session.

 

Good idea!  No reason to use the 6 pin cable when doing debugWire, since the Dragon is screwing up RX Miso.

 

Still, I'll try replacing the part that fell off when touched.  But, I suspect this is common to ALL Dragons on AS 6.1.

 

Here's how to check--

 

Measure between GND and MISO on the dragon 6 pin header.  If it's about 1.2 volts, it's the same thing I'm seeing and could damage SPI peripherals.

 

Dave THomas

 

 

 

 

Last Edited: Sat. Sep 13, 2014 - 01:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Here's a picture of the Dragon.  The tweezers are pointing to the footprint where the part fell off.

 

 

Note,  put the part is on top the yellow cap.

 

If anyone can tell the pin 1 orientation based on the markings  (white dot probably marks pin 1), I'd really appreciate it!

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

I had to remove my home-made plastic 'case'

 

The chip should be orientated with pin#1 next to the O index legend.   Look at the chip to the North.   This has a o index legend.

 

I have no idea what this chip does.    But obviously it must be there for some reason.

 

I am impressed by the quality of your photo.

 

David.

 

 

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

There is another 6 pin chip just north of the footprint.  I thought the O index legend was for that chip, not the one that fell off.  But now I can actually see the pin 1 markings for both chips in  the photo.

 

Still,  it would still help if someone with a Dragon could take a look. and to measure voltage between MISO and GND on the SPI header while in debugWire mode.  Should be open, but if it's  around 1.2 volts, that’s the same thing I have and would suggest a problem common to all Dragons or AS6.1, not just mine.  

 

The photo was taken through a Diopter lens with a Samsung camera.

 

Thanks,

 

Dave Thomas

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

Bought a brand new Dragon so I could have a solid down level on MISO.  But it has the same issue -- the Dragon's MISO pin is not in a high impedance state when in DebugWire mode.

 

The NRF24L01 has an Iol spec of .25 ma.  Assuming it's sinking at least that much current, it looks like the Dragon is presenting the equivalent of a 20K resistor to five volts.

 

So, I definitely suspect ALL AVR dragons have this issue.  If your SPI peripheral can drive MISO with a 20K resistor, you won't have a problem.  But several (many? most?) SPI peripherals don't expect any pull-up resistor on MISO and consequently don't normally need to sink enough current to guarantee a down level with an external pull-up.

 

I can't find any electrical specifications for the Dragon to confirm that it's out of spec or what a specified impedance for the ISP signals in debugWire mode.

 

It also has all the same "quirkiness" when trying to get into and out of debugWire mode.  So the missing part on my original Dragon was a red herring and I wasted $50.

 

Dave Thomas

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

The Dragon documentation says:

 

The AVR Dragon will automatically tristate all unused ISP pins when running debugWIRE.

So, it doesn't do that.

 

I'd like to talk to someone who might care at Atmel.  Anyone have a contact?

 

Thanks,

 

Dave Thomas

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

Anyone have a contact?

User "meolsen" here usually knows the right person to talk to.

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

If I could get these Tiny bootloaders working,  I will have a go with various ideas that involve debugWIRE and Dragon / JTAGICE-mkII.

 

My biggest worry is "NRF24L01 and 5V".    It is a 3V chip.

 

I tend to leave the 6-way ribbon in place.    I have never worried about any MISO loading from a powered Dragon, USBASP, STK500, ...

There are generally several Slave SPI buses on the bus.     They won't mind driving a 20k 'load'.     They don't like driving into a short-circuit.

 

Any programmer/debugger must be powered at all times.     Otherwise 3-state is more likely to appear as "sack of potatoes on your foot".

 

Be realistic.    JTAG or debugWIRE will present some extra current and load.      If you are after minimal Sleep / Standby current,    remove the debugger!

 

David.

Last Edited: Thu. Sep 18, 2014 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes it's a 3V chip.  But it's 5 volt tolerant on all I/O.

 

I'm not worried about standby current or sleep current, just functionality.  It's the bad down levels (1.2 volts)

 

As I mentioned above, SPI slaves don't expect to have to sink current on MISO.   That's really marginal for the AVR and can easily cause false issues--I may be seeing some now in the form of extra retires when downloading code using the bootloader I'm developing.

 

Yes, the debugger must be powered at all times.  That's from the USB port and/or the VCC pin.  It doesn't mean there needs to be a load on MISO.

 

There's no reason at all that MISO can't be in a high impedance state while debugWire is in use--it really just seems like an oversight in the design.

 

 Many SPI slaves probably can sink enough current.  But it least needs to be specified as an Iil requirement so others don't waste time and money chasing what they think is an issue in their own hardware.

 

I'll try sending an email to meolson.

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

Tried sending a private message to 

 

User "meolsen"

But got:

 

  • The following users will not receive this private message: meolson..
  • You must include at least one valid recipient.

 

Did I get the right spelling?

 

Thanks,

 

Dave Thomas 

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

I think the "5V tolerant" requires a bit of investigation.

 

Think about it.     If your AVR is outputting 5V,    the input pin on the NRF has to absorb all the current from the low-impedance push-pull output.

I presume this means it has 'beefy' substrate diodes.

 

Either add serial resistors or run the AVR at 3.3V.

 

David.

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

There's no issue running with 3.3 volts on the NRF24L01 and the Atmega at 5 volts.  It's designed for this, and I've done this on several designs and shipping products with no issues at all.   Many others have also.  

 

Also, remember, the down levels on MISO (and all the SPI lines) are fine when the Dragon isn't attached.  

 

Also, it' s easy to  measure the "not high impedance" on the Dragon.  Put a 20K resistor in the six pin header between MISO and GND.  Measure MISO voltage.  It should be zero or very close to it, right?  It's not even a good logic zero.

 

the input pin on the NRF has to absorb all the current from the low-impedance push-pull output.

 

What?  It does not need to absorb any current at all.  Maybe you're thinking the outputs from the Atmega are clamped to 3.3V/gnd through intrinsic body diodes.  That's not the case.  They swing all the way from 0 to 5V.   Probably the I/O interface ciruitry is in an isolated P/N region and that circuitry does a voltage translation to get the levels below 3.3 for internal CMOS logic.  

 

But it's not an output from the Atmega that has the issue anyway--it's the MISO input to the Atmega (output from the NRF) that doesn't have a good down level when attached to the Dragon.

 

 

 

 

 

 

 

 

 

 

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

BTW, the workaround is from the other post I referenced--I'll just use a different cable when in debugWire mode that doesn't have MISO connected.  One more thing to do to get in and out of debugWire mode, but it should avoid the issue.

 

Building the cable now...

 

 

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

Yup, if I use a cable without MISO, MISO swings between 0 and 3.3V when the NRF is selected (CSN low).  And, when CSN is high, you can tell MISO is floating (hi-Z).

 

I can attach scope photos if anyone's interested.

 

I'll have to swap cables to get out of debugWire into SPI mode, since the MISO signal is used for programming, including fuses.

 

Net, Dragon seems to leave a pull-up resistor on MISO when in debugWire mode.  Which means it doesn't meet it's electrical spec.

 

It's ok if your SPI slave can sink milli-amps on MISO, might cause hard to isolate issues on something like an NRF24L01 which has an Iol spec of only .25 ma.

 

Dave Thomas

Last Edited: Thu. Sep 18, 2014 - 08:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's say the Dragon has a residual pull-up  of 20k.   This is 250uA @ 5V.

 

I tend to use 10k on /CS pins.  

 

But you are always going to want a 'safety' pull-up or pull-down on an inactive SPI bus.

Of course,   when /CS makes a particular Slave active,   the Slave is using a push-pull driver on the MISO line.

 

If your NRF's MISO push-pull driver can't sink 250uA,    there is something wrong.

 

It will be interesting to see your scope trace.

Then I might see what my Dragon does.

 

A 100k or 470k pull-up would be sufficient for 'safety' on an inactive SPI bus.

But I take your point.     Any non-SPI application might actually want/need a very high impedance.

 

David.

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

As I mentioned the NRF Iol spec is only 250 ua.  I'm saying the pullup resistor has to be less than 20K to see what I'm seeing, otherwise (assuming NRF is in spec) the voltage level would be near zero. 

 

I tend to use 10k on /CS pins.  

 

Sure, those are outputs from the Atmega and the Atmega can easily drive those.  That's good practice and absolutely required in many cases.

 

But you are always going to want a 'safety' pull-up or pull-down on an inactive SPI bus.

Why would you put pull up resistors on an interface that's not supposed to have it?  This isn't the CS nor  I2C where pullups are required.  In SPI Processor drives MOSI push/pull, slave drives MISO push pull.

 

Would you put pull up resistors on address and data lines between a processor and memory for "safety"?   

 

I can see adding pullups to signals driven from the Atmega where it's critical they remain high even when the processor is in reset (like CSNs to multiple parts on the same SPI bus).  Since all outputs of the Atmega go to high-z when the part is in reset, multiple parts could be enabled at the same time if they just float while not in reset.  But, not the MISO signal.

 

You definitely do not want pull ups on an SPI interface.

 

I'll post some scope pictures.  

 

Yes, find a convenient resistor to put between MISO and GND and measure the voltage.  I have two of two that look bad.

 

Thanks,

 

Dave Thomas

 

 

 

 

 

Last Edited: Thu. Sep 18, 2014 - 09:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's what Miso looks like when the Dragon is connected to the target device:

 

 

 

MISO is at +5 when the NRE is not selected (CSN high).  It should be floating.  

 

It's 3.3 volts when driven high by the NRF, and 1.2 volts when driven low.

 

Despite the bad 0 logic levels, the target is still functional.  The Atmega recognizes the 1.2 volts as a good down level.  So, unless you took care to look a the signals on an O-scope, you'd likely never know there's an issue.  However, this could

cause difficult to isolate issues, especially when the whole reason you're using a debugger is probably because something's happening you don't understand.

 

Simply cutting the MISO wire makes the trace look good:

 

 

Signal swings between 0 and +3.3 volts.  When the NRF isn't selected (CSN high), you can see the "softness" in the trace indicating it's in Hi-z state.

 

Bought a new Dragon figuring I must have a bad one, but exact same results on second dragon.

 

And same results when enabling (instead) a second NRF on same SPI bus AND same results using a different target board.

 

So, looks like a Dragon design issue to me.

 

 

 

 

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

davethomaspilot wrote:

Tried sending a private message to 

 

User "meolsen"

But got:

 

  • The following users will not receive this private message: meolson..
  • You must include at least one valid recipient.

 

Did I get the right spelling?

 

Thanks,

 

Dave Thomas 

This gentleman...

 

https://www.avrfreaks.net/users/m...

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

It would be nice to see one pulse in detail.     I can't tell what is happening with such a cluttered screenshot.

 

But it certainly looks like the Dragon has a significant pull-up on MISO.

 

Yes,  I take your point about inactive ISP lines should be high impedance.

Perhaps the Dragon designers were more concerned with Transorbs on each pin.

 

If it is a problem,   you would just debug with VCC,GND,dW pins.    Which is exactly what you are doing now.

 

David.

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

Not sure what you're looking for that isn't easily seen in the o-scope waverforms.  Maybe if you explain what you're trying to see I could get it for you, but please review the points I made in the post where I included the shots.  If those are in question, let me know.

 

Let's keep it really simple and avoid opportunity for obfuscation.   Just take a DVM and move the + lead  to measure current instead of voltage.  Connect one DVM probe to the Dragon's MISO and the other one to GND.  Measure the current.

 

I measure 5 ma.

 

 That's huge for SPI slaves and could easily causes problem for many SPI devices.

 

"you would just debug with VCC,GND,dW pins. "

 

Yeah, well, that's what I'm doing.  But the process of getting into and out of debugWire mode is already convoluted and full of error messages that must be ignored.  Heaven help the next guy who finally figures out how to get through all of it only to find out that he must, oh by the way, ignore what the documentation says about leaving the ISP cable in place while debugging.

 

Seems like it needs to be fixed, or at least noted in the documentation.

 

Dave

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

It worked when I clicked on that link and sent private message that way.   Thanks!

 

Dave Thomas

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

davethomaspilot wrote:

It worked when I clicked on that link and sent private message that way.   Thanks!

 

Dave Thomas

 

For future, just ping :) I prefer to answer things in the open.

 

This thread don't really rings a bell. I know there have been something with the Dragon not being able to tristate, but I can't seem to remember the details... You should contact Atmel Design Support to get in touch with a support person that will forward the query to one that knows a bit more about the Dragon than me (he sits about 20 meters from me, but we need to get this counted into the support system, and it's also easier for us to follow up the issue there... ).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Just quoting from the most recent documentation:

Connecting Atmel AVR Dragon probe to 6-pins SPI header using a 6-pin cable

When the DWEN fuse is programmed, there is only need for the GND, VTref and RESET lines to be able to use the debugWIRE interface. However to ease the task of changing between SPI programming mode and debugWIRE mode, it is recommended to use debugWIRE with all six lines connected. The SPI pins will not be driven by the Dragon when running debugWIRE, but pull-up resistors will still be active.

 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Are the values of the pull-up resistors documented anywhere?  For the 5 milliamps I'm seeing, that would be a 1K pull-up.  That doesn't seem reasonable.

 

Maybe there's been a mix-up at board assembly--like maybe 1k resistors used instead of something like 100K.  I know from bitter experience, board stuffers will sometimes just use whatever they happen to have for resistors, especially pull-ups.

 

When I tried contacting Design Support via email I had to fill out a form which had a required field for something like service contract # (or something similar).   Do you have an email, URL, or phone # I could try?

 

Thanks,

 

Dave Thomas

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

Use the 'open a support case' link on the design support site (you need a myAtmel account, which is used for support tracking and many other common atmel things)...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Fri. Sep 19, 2014 - 04:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Opened a case.

 

Thanks!

 

Dave THomas

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

Atmel replied and closed the case.

 

The reply wasn't very useful.  Something along the lines that they've not had any problems with using the Dragon for SPI programming of the Atmega processor.

 

Of course this is irrelevant.  

 

I reopened the case to try again.

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

Again, a non-reply.  A request for device being used, the issue encountered, and the version of AS studio.

 

Clearly indicates the first level support team doesn't understand the issue, but I guess this shows up on someone's score card as answering the ticket.  At least they didn't close it this time.

 

I don't think I'll bother to open a ticket again.  This forum seems  far more helpful than anything I can expect from the support team.  Maybe it will get better if it gets kicked to next level.