Does AtmelIce Hi-Z ISP pins while in debugWire mode?

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

I'm having issues getting into and out of debugWire mode.  I had big time problems back when I used a Dragon, but I haven't had similar problems after I switched to the AtmelIce.

 

I vaguely recall that I had to make a special header to isolate ISP pins from the Attiny being debugged using debugWire, if they were being used to spi communicate with other devices.  But, I thought that was only when I used a Dragon.  Maybe that's required with AtmelIce too?  

 

Does anyone know if the AtmelIce "stays off" (doesn't drive them) the SPI pins when debugWire mode?

 

Also, must other devices on the SPI bus float MOSI/MIS for the device to exit debugWire?

 

Thanks!  

 

 

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

debugWIRE should work fine.   The SPI pins will be in 3-state.

 

I never disconnect the ISP pins for a debugWIRE session.

Obviously complete disconnection does no harm.

 

The only problems arise if you leave the Atmel-ICE connected to the target without poweing the Atmel-ICE.

 

David.

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

Of course target power is required.

 

So, you have used debugWire while the SPI pins are used to communicate with another SPI device?  Otherwise, you wouldn't know whether the ICE was still driving them or not.

 

Also, is only the !RST pin needed to instruct the device to exit debugWire mode?  Or must the ICE use some of the SPI pins to exit debugWire mode.

 

Thanks!

 

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

You need the dW pin to instruct the device to leave debugWIRE mode.

A subsequent power-on reset will restore debugWIRE mode.

 

You can only disable debugWIRE permanently by changing the DWEN fuse e.g. by regular ISP.

In other words you MUST have ISP lines connected to change the fuse.

 

Entering debugWIRE requires:  set DWEN.  toggle power to re-start in debugWIRE mode

Disabling debugWIRE requires:   leave dW command.   clear DWEN without losing power.

 

David.

Last Edited: Sat. Jan 19, 2019 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I can't even "temporarily" disable debug wire, so I guess the issue isn't the ISP pins being driven.

 

debugWire works fine for debugging--I just can't exit it.  Based on what you're saying (only the dw pin is needed), I can rule out my fixture as being the issue.  I have an adapter between the ICE and tag-connect bed of nails that I use when I need on low profile pcbs that use the tag connect footprint instead of a pin header.

 

I've used that fixture many times, but not lately.   Mostly, I worry about the small ribbon cable wires from the ICE to the female header.  They look fragile and seem like they will eventually fail.  But, that's not my issue, if can debug fine--just can't exit debugWire.

 

This magic chant in the Studio command prompt frequently helped with this:

 

atprogram -d attiny44 -i debugwire -t atmelice dwdisable

 

But, that doesn't work either.

 

I'm about ready to change out the device.  It's a bit of a PITA, since I have to have to add a couple of wires to swap pins--(I screwed up when I designed the PCB and didn't notice a pin that needed ADC wasn't on the PORTA bus).  Just an extra 1/2 hour though.

 

I'll give others a chance to "chime in" before I try a new processor.

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

I just can't exit it.  Based on what you're saying (only the dw pin is needed), I can rule out my fixture as being the issue

To enter and exit DW the full 6 pin ISP is required as far as I know, not just the reset pin.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I isolated the ISP wires to the Attiny and now I can exit debugWire mode!

 

So, I'm thinking somehow the MOSI, MISO or SCK signals are being driven by the RPI, despite using wiringPi gpio utility to define those signals as inputs while doing ISP.  This prevents the ICE from being able to drive them.

 

Either that, or something intermittent in the connection path between the ICE and the pcb.

 

Is the drive capability of the ICE specified anywhere?  I'm considering using resistors between the RPI and ISP header so programming of the ATTiny can be done regardless of what state the RPI is in.  But, I need the drive capability of the ICE to see if that will work and to size the resistors.

 

Thanks!

 

 

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

RPi GPIO is 3.3V.  What' your t44 running with?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Usually a 1K resistor in series with what ever load is enough, just make sure that the ISP connector goes directly to the AVR pins.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

RPi GPIO is 3.3V.  What' your t44 running with?

3.3 volts

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

It's totally reproducible--I can unplug the daughter card from the rpi, and program the ATtiny using SPI without a problem.  

 

When it it's plugged into the rpi, I cannot.  Even though I put RPI SCLK, MOSI, MISO as inputs and CE1 (the CE the ATTiny monitors as an SPI slave) as output to 1.

 

But, I think I understand what's happening.  The Attiny controls an enable input to a 5V regulator for the RPI.  There's a pulldown on that enable line.  Consequently, when the ATTiny is in the reset state, the DC/DC will not be enabled.

 

So, when I ISP program the Attiny, I think its gpio not used for ISP  must go to Hi-Z state.  Which means the 5V regulator will turn off, since there's a pulldown on that line. 

 

I see the rpi getting rebooted when I try reading the device signature using Studio "Device Programming".  Which means the RPI GPIO may not stay in high impedance state.  The RPI SPI lines might then prevent the ICE from being able to control them for ISP or debugWire mode transition.

 

But, what's interesting is that I don't see this issue on the first card I built.    I left the Attiny daughter card plugged to the RPI and powered up.  I reprogrammed the attiny using ISP many times with the card and went in/out of debugwire mode also.

 

The first card has a six pin header for ISP instead of the tag-connect footprint.  The SD image for the RPIs is identical (but different RPI). 

 

Regardless, I need the series resistors and/or a jumper for the regulator enable pin.  The jumper would allow me keep the RPI powered on while the Attiny is being reprogrammed.

 

On this card, I'll simply remove the pulldown resistor on the enable pin.  I haven't tried this, but if I'm right, running a script on the rpi to float the SPI pins should then be sufficient.  The regulator power down is just a power save feature, so when I get everything else working, I can just populate the pull down again.

 

Next pass, I'll add the 1K resistors.

 

Thank you for your attention!