Climber's experiences with AVR GOTCHAS

Like everything technical, there are gotchas with programming AVRS that causes aging, forces hairpulling, raises bloodpressure and generally ends up wasting valuable time. I decided to put together a web page that describes the one I encountered so you might not end up wasting your time like I did.

If the tone of this web page seems bitter THAT'S BECAUSE IT IS.

These aren't the pins you're looking for

The labeled ISP port on most avr processors are used to also serially program the device. Life is good. That was until I tried to program the mega64 and mega128. The SPI pins are used for, well, SPI. The MOSI/MISO/SCK pins for serial programming are, instead, on pins PE0, PE1 and PB1. This is documented on page 303 on the PDF I downloaded. I wish there had been some kind of note or asterisk or SOMETHING in the Pin Configurations section that indicated I had to look elsewhere for the programming port.

Atmel's documentation rocks; except when it doesn't

Speaking of documentation issues, I wish the fact that pin 6 on the ISP header has to have VCC on it in order for the AVRISP MK II to know what voltage to program with was in the DOCUMENTATION for the AVRISP MK II. Hell, most of my projects don't even HAVE a pin 6 since I always power the project locally

Turns out that the help files for avrstudio has this important tidbit but, for some reason, the programmer's documentation does not. Fat lot of good that did me since avrstudio doesn't work in linux.


When I started getting into programming these devices I used the DAPA style parallel port programmer cable that I first learned about from Guido Socher's excellent Atmel AVR pagers on There was a comment that the cable can't be too long. What I didn't know is that the target processor's clock speed dictated that length!

So, I build a cable that works just fine for every device I try it with. Then, one day, I decide to use a 16 MHz crystal for the first time. I download programs without error. I then set the fuses to use the crystal at 16 meg. POOF! Can't program it anymore. Naturally I thought I had screwed up the fuses and after soldering in two different replacements I FINALLY figured out that my cable was only good up to 8 MHz and needed a shorter one for the 16 meg devices.

I am quite cognizant of the fact that clock speed limits signal lengths but since the programming device sends the clock for programming through the SCK line WHY IN THE WORLD WOULD THE TARGET DEVICE CLOCK MAKE A DIFFERENCE? IS THAT CLOCK EVEN RUNNING IN RESET MODE? That was a rhetorical question so don't email me the answer since I already know it. Still annoys me, though.

Fortunately, since I am switching entirely to the AVRISP MK II for all my programming (you can make more than one work at once; sweet!) this issue is going away.

The RC oscillator sucks; resonators suck less but still suck, crystals ROCK

I recently used up a string of 11 tiny44s to make up some "mines" for the minesweeper contest we had in the 2007 Western Canadian Robot Games. Part of their function was to generate a 38.0 KHz signal to drive some infrared LEDs. I found that there was about a 15% difference in the resulting PWM frequency from one extreme to the other amongst these processors. I had to go back and calibrate each one individually and hoped to hell that they didn't vary much between the conditions in my basement to the conditions at the Calgary Aerospace Museum where we held the event.

In other projects this variation was enough to completely screw up serial commuications I was attempting with other processors. This taught me that for projects that need even moderately accurate timing the RC oscillator doesn't cut it.

Resonators are a step up but, for me, still suck. I recently used a 16.0 MHz resonator on a project but I only got 15.85 MHz which completely screwed up everything that depended on accurate timing. Since OSCCAL can't be used to calibrate it I had to keep replacing it until I found one that was accurate enough to use.

I've decided that if I am going to bother adding in pads and routes for a resonator I might as well use a crystal instead.


Most of the larger AVRs have a JTAG port. Since I've found it nearly impossible to find JTAG documentation on the Internet that doesn't suck and refuse to cough up $95 US to buy documentation from the IEEE without knowing beforehand if it sucks or not I've decided that JTAG is dead to me.

The fuse to enable the JTAG port is left enabled by default. I turn mine off to stop the system from using it when I want just ordinary I/O pins.

Why does my code need a NOP to enable it to upload?!?!?!?!?!?!?!?

Still haven't figured this one out. I write and compile a program for a mega88. It's good. Upload Works. Modify code. Compile. Upload fails. avrdude hangs and dies right near the end of the first write. Add a asm volatile ("nop" ::); to the program. Anywhere; it doesn't matter. Recompile. Upload DOES NOT work. WTF? For this particular processor does the .hex file file have a size evenly divisible by two or what?

Unlucky 13

While playing with my little board that has a USB FT232BM on it I noticed that it would never send a 13. It would always replace it with a 10.


I hooked up my max232 chip and had the mega88 simultaneously transmit the same data to my computer through USB to /dev/ttyUSB0 and through RS232 to /dev/ttyS0. The 232 port got 13s and the USB port got 10s.


Turns out the stupid serial USB driver automagically translates carriage returns (13) to line feeds (10). This fixed it:

stty -icrnl --file=/dev/ttyUSB0

What I don't know at this time is if I have to do that EVERY SINGLE TIME the USB device is attached and/or the computer reboots.

to email Craig send to climber at (replace at with @ and remove spaces).
Return to Craig's main page.

Last modified: Feb 11, 2008. Stupid genes.