ATmega16u2 Minimal Connections to test ISP?

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

Hi guys (first post),

I recently connected some ATmega16u2 TQFP chips to a DIP adaptor for breadboarding. I want to make the minimal connections to successfully test the ISP connectivity with avrdude.

I have already tried basically connecting to vcc/avcc, miso/mosi/SCLK, /RESET, gnd. i left unconnected uvcc, ugnd, ucap, d+,d- (i don't have a good understanding of whether these lines need to be connected with other external circuitry). Using these connections alone failed.

My programmer is a USBTiny, I am not sure it guarantees support with ATmega16u2... I can't find much on this chip outside the datasheet, which is why i am here.

I am coming from experience using ATmega8 and ATmega8515..

Thanks in advance for your help,
``

Last Edited: Wed. Oct 23, 2013 - 03:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GND?

"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

yes excuse me, gnd is also connected.

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

You need a crystal. (or an external oscillator)

Basically, any ISP chip can be programmed by avrdude.
USB chips always expect a crystal.
Non-USB chips come from the factory with Internal RC osc.

So if your copy of avrdude.conf is old, you just need to install a new copy.
I think that avrdude comes with AS6 nowadays.

Your connections sound fine. You can omit the uxxxx pins. You always need 100nF capacitors on VCC/GND. You might get away with the 100nFs from the USBTINY, but I don't recommend it.

David.

Last Edited: Wed. Oct 23, 2013 - 03:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@david,

You were right :) I plugged in a Crystal, and avrdude recognized the chip :)

I'm just surprised, because I thought I read about an internal oscillator on the datasheet.

Thanks,

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

bazzman wrote:
I'm just surprised, because I thought I read about an internal oscillator on the datasheet.
So did I:
In the ATmega8U/16U/32U datasheet, Atmel wrote:
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. The startup time is set to maximum and time-out period enabled. (CKSEL = "0010", SUT = "10", CKDIV8 = "0"). The default setting ensures that all users can make their desired clock source setting using any available programming interface.
However, the default fuse settings for CKSEL[3:0] disagree:
In Table 25-5, Atmel wrote:
CKSEL3  1 (unprogrammed)
CKSEL2  1 (unprogrammed)
CKSEL1  1 (unprogrammed)
CKSEL0  0 (programmed)

In Table 8-1, Atmel wrote:

Device Clocking Option         CKSEL3:0
Low Power Crystal Oscillator   1111 - 1000

Who wants to tell Atmel?

JJ

"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

Furthermore, perhaps the datasheet is more incorrect, to the point where there is no Internal Oscillator Fuse Option??! Because, I cannot seem to successfully change the lower Fuse settings to Internal Oscillator, the chip appears to automatically reset the fuse immediately after programming -> back to having CKSEL at 0b1110

In the following code snippet, I am trying to program lower fuse to change CKSEL to 0010 (Internal Calibrated Oscillator), while retaining everything else as factory default, watch what happens:

avrdude -c usbtiny -p m16u2 -U lfuse:w:0x52:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9489
avrdude: reading input file "0x52"
avrdude: writing lfuse (1 bytes):

Writing |                                                    | 0% 0.00s ***failed;
Writing |################################################## | 100% 0.11s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x52:
avrdude: load data lfuse data from input file 0x52:
avrdude: input file 0x52 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x52 != 0x5e
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was 52, and is now 5e
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Derp, I cannot tell yet if my *write* op failed, or if the chip is purposely saying "NO"

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

Herp derp,

I got the fuses working, there is in fact that Internal Oscillator.

Note: I had to flash the Flash ROM with some dummy hex file to finally be able to program the fuse bits. Now I am ISP with no crystal connected, successfully.

Special note that the chip ships with the CKDIV8 programmed, which divides the clock by 8, so I was sure to unprogram it (1) in the lfuse while programming CKSEL to internal oscillator

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

p.s. I told Atmel about the discrepancy <3

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Writing |                                                    | 0% 0.00s ***failed;
Writing |################################################## | 100% 0.11s

Smells like lock bits were programmed.

bazzman wrote:
Note: I had to flash the Flash ROM with some dummy hex file to finally be able to program the fuse bits. Now I am ISP with no crystal connected, successfully.
Flashing a new program will automatically cause avrdude to perform a chip erase before the flash. This clears lock bits. All you really needed to do was pass -e on the commandline before the -U for the fuse.

The 8U2/16U2/32U2 ship with the lock bits programmed:

In Table 25-1, Atmel wrote:

Lock Bit Byte  Bit No     Description        Default Value
                7           –             1 (unprogrammed)
                6           –             1 (unprogrammed)
    BLB12       5       Boot Lock bit     1 (unprogrammed)
    BLB11       4       Boot Lock bit     0 (programmed)
    BLB02       3       Boot Lock bit     1 (unprogrammed)
    BLB01       2       Boot Lock bit     1 (unprogrammed)
    LB2         1       Lock bit          0 (programmed)
    LB1         0       Lock bit          0 (programmed)

Oddly, I can find no mention of it in the complete datasheet or the datasheet summary, but Atmel's product page for the 8U2/16U2/32U2 also has a USB DFU bootloader datasheet.

The datsheet for the 16U4/32U4 specifically state that the device ships with a DFU bootloader. I've not used any of the U2 or U4 parts before, so I can't confirm whether this is true of all U2 parts, but since the datasheet shows lock bits programmed by default on the U2 part, I'd guess it is.

I imagine the lock bits are set by default to make it a bit (not much) harder to brick your avr. I hope you didn't want that bootloader ;)

Despite the datasheet errata re: default clock source, the DFU bootloader and the USB hardware on the chip needs a better clock source than the calibrated internal RC oscillator can provide, which explains the default settings for a crystal.

Quote:
Special note that the chip ships with the CKDIV8 programmed, which divides the clock by 8, so I was sure to unprogram it (1) in the lfuse while programming CKSEL to internal oscillator
CKDIV8 is programmed by default on, I believe, all mega and tiny avr.

JJ

//////////////////////////////////////////////////////////////

"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

I also just hooked up an ATmega16U2 to USB with a 16MHz crystal, and was wondering how it was working (both with DFU and after programming) if the default clock was the internal RC oscillator.

 

Not surprising anymore, if it's programmed to use the crystal by default. What's perhaps more surprising to me is how the DFU bootloader automatically figures out whether the crystal is 8 or 16 MHz and immediately shows up on the computer.

 

This thread clears things up a bit. If setting the clock prescaler to 1 in software, all of the other default fuse settings are fine, and there is no need to manually change fuse bits with an ISP. Very convenient since everything can be programmed and tested straight from a single USB port!

Last Edited: Tue. Dec 2, 2014 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's late 2017 and the datasheet for the ATmega8U2 still has the incorrect text about the default clock configuration in section 8.3.1.

 

Yes, it is correct elsewhere in the same document, but the problem still cost me a couple of days of work.

 

Is there a recommended path to getting Atmel to fix their obvious datasheet errors (within, oh, I don't know, a year?) That would be nice.

 

Paul R. Potts - paul@thepottshouse.org

Last Edited: Fri. Nov 10, 2017 - 08:10 PM