Atmel ICE Can't Talk to a ATmeg8U2 on a Breadboard, New (_and_ old) Setup

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

I have searched related answers and tried various workarounds and hacks and have not had any success.

 

This is not my first rodeo with bare AVR chips on breadboards or hand-soldered prototypes -- I've gotten several working in the past.

 

I'm using Atmel Studio 7 version 7.0.1645, just updated yesterday, with an Atmel ICE debugger, also updated yesterday. I'm running on Windows 7 Professional. In the "Tool Information" I have:

 

Atmel-ICE
Debug host        127.0.0.1
Debug port        58662
Serial number     J41800068181
Connection        com.atmel.avrdbg.connection.cmsis-dap
Features          1
Firmware Version  1.27
Hardware Version  0

 

 

I have the interface set to ISP, ISP clock at 125k kHz. It seems to be communicating OK with the debugger since I can read the target voltage.

 

Hardware setup: the TQFP -32 version of the ATmega8U2 is on a breakout board from Adafruit, plugged into a breadboard. I'm using the squid cable to connect to pins on the breadboard. I have only 6 pins hooked up as per the Atmel ICE user manual. Per my reading this works out to:

 

- Squid cable plugged into "AVR" (not "SAM") socket on Atmel ICE.

 

- Squid cable pin 1 to SCK (pin 15 on chip)

- Squid cable pin 9 to MOSI (pin 16 on chip)

- Squid cable pin 3 to MISO (pin 17 on chip)

- Squid cable pin 4 to VCC (pin 4 on chip)

- Squid cable pin 2 to GND (pin 3 on chip)

- Squid cable pin 6 to RESET (pin 24 on chip)

 

VCC and GND are hooked up to a power supply set to 5.0V and the "read voltage" command gets back 5.0V.

 

I have tried it both with and without a 10K pullup resistor from RESET to the +5V, and it doesn't work either way.

 

I've tried it with and without a 1uF cap between the VCC and GND pins on the chip as well, no difference.

 

Trying to read the device signature, I get "Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool).

 

I have a second chip on a breakout board and, thinking maybe I fried the first one accidentally, have swapped in the second chip, with exactly the same results.

 

Now, it so happens that I _also_ have a Dragon. Hooking up the dragon instead of the ICE, I can use a little adapter board to attach the squid cable to the ISP pins. If I do that, the tool information shows:

 

AVR Dragon
Debug host               127.0.0.1
Debug port               58662
Serial number            00A200065956
Connection               com.atmel.avrdbg.connection.mchp
Master Firmware Version  7.27
Slave Firmware Version   7.27
Hardware Version         17

 

With that setup, I can't read the target voltage. When I try to set the interface selection to ISP and hit "apply," I get "Failed to get interface clock value. Does the target have power?" And trying to read the target voltage seems to produce a random value.

 

Just for kicks I pulled out an old breadboard for a completely different project, that used to work just fine. That one uses an ATiny461A. It is still all wired up on the breadboard with a squid cable ready to hook up to the Atmel ICE. I hooked up power and plugged the squid cable into the ICE debugger and I get the exact same results. I can read the voltage just fine, but it won't talk to the chip.

 

I swapped in the Dragon and I get exactly the same results as above (can't read voltage, can't read device signature).

 

This leads me to believe that it is more likely a problem with the toolchain, debugger firmware, driver, etc. than my new breadboard.

 

Any suggestions as to what else to try, to figure out what has gone wrong with my toolchain?

 

Thanks.

 

Paul R. Potts - paul@thepottshouse.org

Last Edited: Wed. Nov 8, 2017 - 10:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the ISP speed set to?   Is 1/4 the cpu speed or lower? (125khz)

 

Jim

 

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

As I mentioned, 125. I can't read the fuses so I don't know for sure how the micro is set, but the datasheet says it ships set for the internal RC 8.0MHz oscillator with CKDIV8 on.

 

Update: tried setting it to 8 kHz. Same results.

Paul R. Potts - paul@thepottshouse.org

Last Edited: Thu. Nov 2, 2017 - 06:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time for a photo of your setup on the BB

 

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

Given that the old breadboard project doesn't work either, leading me to believe it is a software problem, I am going to try this next: uninstall everything from Atmel I can possibly find on my computer, including all drivers. Then install from scratch. And see if that makes any difference. This will take a while.

Paul R. Potts - paul@thepottshouse.org

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

Well, after uninstalling everything, verifying that the ICE and the Dragon had no driver available at all, and reinstalling 7.0.1645 from scratch, I was able to get the old breadboard project working. So it seems like at least part of the problem was caused by a toolchain update that broke something.

 

The new project board with the Atmega8U2 is still not working. I am looking at it with a scope trying to figure out why the chip is not responding to the attempts to talk to it. Nothing definitive yet. I can see that there is a burst of pulses on MOSI. Those pulses look OK to me. The clock signal from squid cable pin 1 does not look right at all though. It is reading very close to 0V and has a tiny, tiny amplitude. So I'm trying to figure out what is up with that.

Paul R. Potts - paul@thepottshouse.org

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

All right, I had a pin connected wrong. I also verified that it is not a problem with the squid cable itself. On my scope I, if I watch the ICE try to read the device signature, I see it pull down RESET and I see what looks like a perfectly respectable burst of SPI data, clock and MOSI. But I never see anything at all coming back from the microcontroller on MISO (pin 17). Per a voltmeter it remains pegged at about 1.8V, which seems odd. Tomorrow I will try swapping chips again in case I'm still looking at a problem due to a fried chip.

Paul R. Potts - paul@thepottshouse.org

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

Swapped chips. Still nuttin'. I'm building up a new prototype board with a fresh chip, but I don't have much hope that #3 will magically work.

Paul R. Potts - paul@thepottshouse.org

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

Took a fresh chip out of the original package from Digi-key and my EE co-worker built up a new board. Tested continuity on every pin with a voltmeter. Solder connections look perfect, no shorts. This one still fails with exactly the same symptoms. I have taken the breadboard out of the picture and I'm wiring the squid cable directly up to the little proto-board, just in case the breadboard itself might have a bad internal contact. Nothin'. Same symptoms.

 

All I have on hand to take pictures is my cheapo Android phone, but here they are. I have my Rigol power supply connected to pins 3 and 4 and also to the squid cable pins 2 and 4 so that the debugger will receive power. The target voltage reads correct and my voltmeter shows me 4.0V across pins 3 and 4 on the little proto board. I'm not sure how I can simplify it any more than this.

 

Paul R. Potts - paul@thepottshouse.org

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

From 25.9 Serial programming pin mapping:

 

2. VCC - 0.3V < AVCC < VCC + 0.3V, however, AVCC should always be within 1.8 - 5.5V

 

You are not providing proper power to the chip!!!

 

Jim

 

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

Most USB chips come out of the factory with DFU bootloader and expecting an external crystal.
The 8u2 might be different. After all, a DFU bootloader requires about 4kB. Most 8kB chips would not have a 4kB boot area.
.
I am not at a PC. So have not checked the datasheet.
.
Your pcb requires 100nF capacitors. Most of those DIL adapters have pads for capacitors. Even pads for a crystal.
.
David.

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

Oh, FFS. You know, I even went through this before with a previous design where we actually use the internal ADC, on a 461A. I forgot that AVCC has to be up even if you aren't using ADCs.

 

Hooking up pin 32 to my +4V does not seem to cause any change, though. Did I fry it by put power on only VCC? If so I probably fried 3 of them. I don't smell any magic smoke...

 

Paul R. Potts - paul@thepottshouse.org

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

From what I can tell, the DFU bootloader is not on the 8U2 (but is on the 16). Even if it is, I think reading the chip ID ought to be possible using ISP.

 

I had a cap on GND-VCC but took it off as it did not seem to make any difference in this case, but I can try building up a breadboard again. At this point I am just trying to get the bare minimum "is the chip alive and can I program it" sanity check passing. I am now powering AVCC too but something is still not right.

 

Paul R. Potts - paul@thepottshouse.org

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

Here's a picture of the scope: yellow is RESET, blue is MOSI, purple is MISO.

 

Hmmm, well, that came out rotated, but the basic idea is that MISO is not doing anything in response to data (if you zoom on those MOSI vertical lines, they are bursts of data).

 

Here's a closer view of a data packet with clock instead of reset on yellow.

 

 

Thanks for the suggestions, folks. I will be out until Monday. Maybe on Monday I'll try yet another fresh chip on the grounds that maybe I really did smoke three of them. I really wish this micro was available in a DIP version. That made it much easier for me to build prototypes on breadboards for some previous designs, before switching to tiny parts for the final boards.

 

 

Paul R. Potts - paul@thepottshouse.org

Last Edited: Fri. Nov 3, 2017 - 10:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK -- on the off chance that the datasheet is wrong, and these chips arrived programmed to run from an _external_ clock, I ordered some 8MHz crystals. They arrived today, I added the crystal + 2x20pF caps, and tried again. The chip worked immediately.

 

So, the datasheet says:

 

8.3.1 Default Clock Source
The device is shipped with internal RC oscillator at 8.0 MHz and with the fuse CKDIV8 programmed,
resulting in 1.0 MHz system clock.

 

Now that I can read the fuses on these chips, I see that they read EXTENDED 0xF4, HIGH 0xD9, LOW 0x5E. So clock select is shown as "ext. crystal oscillator 8.0MHz, startup time 258 CK + 65 ms."

 

BODLEVEL = 3V0
HWBE = [X]
DWEN = [ ]
RSTDISBL = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 2048W_800
BOOTRST = [ ]
CKDIV8 = [X]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_258CK_65MS

EXTENDED = 0xF4 (valid)
HIGH = 0xD9 (valid)
LOW = 0x5E (valid)

 

So, I guess I don't need any more assistance at present. Maybe this post will help someone else who stumbles across the same problem.

 

Paul R. Potts - paul@thepottshouse.org

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

Most USB chips come out of the factory with DFU bootloader and expecting an external crystal.

Success at last.

 

David.

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

As I mentioned, 125. I can't read the fuses so I don't know for sure how the micro is set, but the datasheet says it ships set for the internal RC 8.0MHz oscillator with CKDIV8 on.

 No, it doesn't.

on the off chance that the datasheet is wrong

The datasheet is not wrong.  You just didn't read it correctly ;-)

 

So, the datasheet says:

 

8.3.1 Default Clock Source
The device is shipped with internal RC oscillator at 8.0 MHz and with the fuse CKDIV8 programmed,
resulting in 1.0 MHz system clock.

OK, >>that<< part of the datasheet is wrong ;-) [another example of Atmel's technical writing staff relying too heavily on copy/paste!]:

 

 

In reality, the m8u2 is different:

 

 

Note the default bit value of CKSEL[3:0] is 0b1110.  Looking at Table 8-1 as suggested shows that to be:

 

 

Digging deeper:

 

 

... and deeper:

 

 

As David previously pointed out, USB-capable AVR are different.  Some other USB-capable AVR are also fused for an external crystal.  The m16u2, m32u2, m16u4, m32u4...

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

Last Edited: Wed. Nov 8, 2017 - 08:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fine, "that _part_ of the datasheet is wrong."

 

Does it contradict itself? Very well, it contradicts itself. I guess, like Whitman, it is large, it contains multitudes angry

Paul R. Potts - paul@thepottshouse.org

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

David pointed this out in #11, five days ago now.  I guess you missed it...?

 

Yes, datasheets (like >>all<< documents) contain errors.  On the whole, Atmel datasheets are pretty good compared so some other vendors.

"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."

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

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

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

 

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

No, I did not miss it. Dave said "the 8u2 might be different" and that he "[had] not checked the datasheet." So I did. It _appeared_ that the 8U2 was different, but Dave's comments _did_ leave enough doubt in my mind that, five days ago (Friday evening after work), I ordered the crystals to try... cheeky

Paul R. Potts - paul@thepottshouse.org

Last Edited: Wed. Nov 8, 2017 - 09:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My doubts were about the DFU bootloader on such a small 8kB chip.

 

Why have you chosen an 8kB chip?   I would expect that most practical apps would need 16u2 or 32u2.

Mind you,   I think the first Unos had 8u2.   The current Arduinos use 16u2.

 

David.

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

Ah, OK, so you were correct about the USB chip needing the external crystal, although I originally read your comment as being unsure about (both) the clock configuration and the presence of the bootloader.

 

Why this chip? No big reason, except that the application is pretty simple. I have had fun building some prototypes and products around some members of the tiny family. You can do quite a lot on those chips with very little SRAM.

 

That said, I have not done a USB project before. If the 8 isn't big enough, it should be pretty easy to switch to a bigger one of the family, since they seem to have the same form factor and pinouts.

 

Paul R. Potts - paul@thepottshouse.org