Same new ICE, NEW old problem

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

More trouble with my new ICE.  I'm sure this same "problem" has been solved here many times, but my searches led nowhere.

 

With help from this forum, I learned that ICE does not power the target.  Problem solved!  Happily programming and debugging attiny85's for a week. Next, Turned to ATMega88... boom.

 

---
Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool) [etc., etc.]
---

 

Switched back to attiny85's... SAME PROBLEM!!!

 

I do know about ISP pinouts, having built my own successful adapters.  Maybe my "basic" ICE cable w/ 6-pin ISP is bad?  But I've since tried the squid cable, following "Table 3-6. Atmel-ICE SPI Pin Mapping" in the current ICE user guide.  No luck.

 

So far as I can tell, my connections are good.  Maybe I am missing something about, "[v]erify device selection, interface settings, target power, security bit, and connections to the target device?"

 

BTW, this is NOT a DBWEN fuse issue.  Also, I know the targets are good chips (an assortment of known quantities was tested).

 

Please help!  The poor old dragon never gave me this trouble, and I cannot afford to have wasted $150 (US) on this ICE.

 

Thanks for your attention.

 

-- Tarmin D.

 

This topic has a solution.

Tarmin Dee
It has been noted that, all falls but not some, or other.

Last Edited: Fri. Feb 26, 2021 - 01:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Accidentally plugged into the sam port of the ice?

what happens if you just read the target voltage or the device ID? can you do that at all????

Are you really sure you did not leave the tiny85 in debug mode last time exiting?

Accidentally connected the 6pin cable the wrong way around?

What have you set the programming speed to?

Are you sure you have selected the right device ( that should come up when you try to read the device signature)

 

Tip... I always first try to read the device signature when I re-connect my programming tool. As long as that does not work, no need to do anything else and in the process accidentally change a fuse or 2.....

 

 

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

Thank you.  I appreciate your response.  Your checklist is well put, and corresponds to my own practice.  So:

 

1.  SAM vs. AVR port is not the issue.
2.  The ICE's steady green LED is lit, indicating a powered chip. (I'm using 3.3V, but have also tried 5V.)
3.  DWEN is not the problem.  I swapped several chips in and out while testing, each of which was subsequently re-programmed with USBtiny.
4.  Cables are correctly positioned for ISP.
5.  Programming speed is 125kHz, although different speeds were tried out of desperation.
6.  I am certain that the correct device has been selected; I cannot read a signature.
7.  I am also in the habit of relying very much on the Device Programming tool.

 

So far as due diligence goes, most of yesterday was wasted on the problem.  After reading your response, I went back over the checklist today, this time restricting things to ATtiny85 only, and to a single test bench.  The configuration is such that I can easily switch between ICE (cabled) and USBtiny (jumper wires), without touching the actual connections into the chip.

 

I have had problems before with USB and TI's MSP430G2553 Launchpad -- some were actually shipped with bad cables!  I think I have eliminated that concern here, though, having swapped both USB ports and cables.

 

Summarizing:  I successfully used ICE with ATtiny85 for about a week.  Yesterday, I tried programming an ATMega8 (yes, a clumsy fossil).  That's when things quietly went boom across the board, as described earlier.

 

Bottom line: I am desperate.  The ICE was a significant investment for me.  I do not want an expensive, itty-bitty, plastic chotchka with teeny-weeny, curly wires sticking out.

 

Is there something other than the above that I've missed?  Is this unit fubar?  Must I fight with Microchip Direct for a replacement or refund?  Should I file a complaint with PayPal?  What does one do in such a situation?

Tarmin Dee
It has been noted that, all falls but not some, or other.

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

I don't think I have ever successfully destroyed an Atmel-ICE :/

Do you have perhaps a JTAG target you could test against?  Even just reading the IDCODE would give a second opinion on the level shifters and IO.

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

TarminDee wrote:
Must I fight with Microchip Direct for a replacement or refund?
90 day warranty

TarminDee wrote:
Should I file a complaint with PayPal?
Transparency - have had issues with PayPal.

TarminDee wrote:
What does one do in such a situation?
Gather data via a logic analyzer, diagnose

 


Development Tools Warranty | Microchip Technology

 

PJRC Store, Payment Options (bottom half)

 

Protocol decoders - sigrok (2 instances of AVR)

 

"Dare to be naïve." - Buckminster Fuller

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

Not many posts here on damaged Atmel-ICE.

IIRC :

  • wrenched USB connector (corrected in later production)
  • power supply

 

 

Architecture Description | Atmel-ICE

Filters and protection

can probably protect when mis-wiring 12V and maybe 24V automotive; likely not for off-line power (current into USB VBUS therefore damaging Atmel-ICE's power supply due to excessive reverse current)

 

"Dare to be naïve." - Buckminster Fuller

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

TarminDee wrote:
BTW, this is NOT a DBWEN fuse issue

how are you sure?

 

TarminDee wrote:
I swapped several chips in and out while testing, each of which was subsequently re-programmed with USBtiny.

I don't think that says anything about whether this particular chip is stuck in debugWIRE ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow!  Another set of quick responses, each of which needs time to mull over.

 

Regarding the debug wire fuse, though... Today, I tested against multiple chips, two of which had never been touched before (i.e., there was no opportunity to have messed with any fuses, period).  Also, each had subsequently been programmed through avrdude and USBtiny, using the external tool menu item.  I believe that means loading the binaries through SPI, something not be possible, had the DWEN fuse been set -- right?

 

The JTAG comment is interesting.  Unfortunately, all I have along those lines is the MSP430G2553.  For some reason, Microchip Studio does not offer to program TI chips.  Go figure!

 

Any other suggestions along those lines?  I did notice a reference to logic analyzer,s which I will pursue, but is there anything else specifically hardware oriented?

 

Thanks again, all.  You folks are great!

Tarmin Dee
It has been noted that, all falls but not some, or other.

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

TarminDee wrote:
Regarding the debug wire fuse, though

Easy enough to rule out DWEN by:
atprogram dwdisable

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

I have had problems with my Atmel ICE that I could not explain.  Working one minute and not working the next.  This happened more than once.  First few times I wasted a lot of time trying to figure it out.

 

I am going to sound like tech support here.  But the solution for me was to turn off the computer (physical power switch) and reboot.

 

Unplugging the ICE didn't fix it.  Restarting Atmel Studio didn't fix it.  Warm boot didn't fix it.

 

The ICE would enumerate if being plugged/unplugged.  It was visible in the programming window of Atmel Studio.  You could read the VCC and it was correct.  But if you hit "read ID" it would fail.

 

Each time it has happened it was when connected to a benchtop laboratory PSU that had problems.  Switched PSU and have not seen it for some time.

 

Looking at the SPI pins with a scope would show data happening so I didnt think the drivers were shot.  I tried with a NiCad battery pack to give a clean 4.8v DC in case the known failing PSU was a problem.  Nothing worked.  Then did a cold boot and it was working again even on the flakey PSU.  But it failed again sometime later.  This happened several times over a period of a few months.  I fixed the flakey PSU and it has not happened again.  That last bit might be coincidence I just don't know.

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

andrewm1973 wrote:
I fixed the flakey PSU and it has not happened again.
a reminderwink ... XMega SRAM slow turnaround? - Solved (Glitchy Power Supply). | AVR Freaks

"Dare to be naïve." - Buckminster Fuller

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

TarminDee wrote:
I tested against multiple chips

what, exactly, did you test ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[ ... per awneil: what, exactly, did you test ? ]

 

Well, e.g., whether I could read the device signature in Atmel Studio.

Tarmin Dee
It has been noted that, all falls but not some, or other.

Last Edited: Tue. Feb 23, 2021 - 10:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I still don't see how that confirms that a different chip is not "stuck" in debugWIRE mode?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

andrewm1973 wrote:
I fixed the flakey PSU and it has not happened again.
a reminderwink ... XMega SRAM slow turnaround? - Solved (Glitchy Power Supply). | AVR Freaks

 

The weird part is that once the ICE was locked up by the flakey power supply it would not work until a PC cold boot.  A re-enumeration on the USB, a restart of AVR Studio or a warm boot of the PC would not fix the issue.  Even with a clean 4v8 DC from batteries.

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

awneil wrote:
I still don't see how that confirms that a different chip is not "stuck" in debugWIRE mode?

 

Sorry.  I did not realize that you were still entertaining the debugWire possibility when questioning my reference to different chips.  Anyway, ATMega8's lack the debugWire fuse.

 

Tarmin Dee
It has been noted that, all falls but not some, or other.

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

andrewm1973 wrote:

gchapman wrote:

andrewm1973 wrote:
I fixed the flakey PSU and it has not happened again.
a reminderwink ... XMega SRAM slow turnaround? - Solved (Glitchy Power Supply). | AVR Freaks

 

The weird part is that once the ICE was locked up by the flakey power supply it would not work until a PC cold boot.  A re-enumeration on the USB, a restart of AVR Studio or a warm boot of the PC would not fix the issue.  Even with a clean 4v8 DC from batteries.

 

What a nightmare!  Many of us are attracted to programming because of its apparent determinism, but we can only aspire to the condition of Laplace's demon.  In the case of andrewm1973, how can we really tell whether the nightmare has finally ended?

Tarmin Dee
It has been noted that, all falls but not some, or other.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When power, clock, and signals are within the specification limits excepting certain environmental conditions (ESD/EFT/lightning, GCR, ...)

 

"Dare to be naïve." - Buckminster Fuller

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

I marked gchapman as the solution, but others said much of the same.

 

With tail 'twixt Tarmin's hind legs: the ICE works fine!  Yes, the simple things.  Connections, power supply... well, that was it in this case.

 

Thank you, all.  You folks are GREAT.

Tarmin Dee
It has been noted that, all falls but not some, or other.