ATmega168 documentation uses word addressing, avrdude uses byte addressing

I was programming USBaspBootloader into a metaboard with an Atmel AVR ATmega168 microcontroller. I always got this error:

usb 6-2: device descriptor read/64, error -71
...
usb 6-2: device not accepting address 21, error -71

1. USBaspBootloader’s Makefile specifies atmega168 and BOOTLOADER_ADDRESS=3800 by default. This is in hex addressing a byte, i.e. 0x3800. avrdude uses byte-addressing.

ATmega168 documentation refers to 0x1C00 as the bootloader address. This is in hex addressing a word. 0x3800 / 2 = 0x1C00.

So, when programming a bootloader using avrdude, USBaspLoader’s Makefile should have 3800 (the default), not 1C00.

2. bootloaderconfig.h has features enabled that make the bootloader too big (> 2K). I had to turm them off:

80 #define HAVE_EEPROM_PAGED_ACCESS 0
...
87 #define HAVE_EEPROM_BYTE_ACCESS 0
...
93 #define BOOTLOADER_CAN_EXIT 0

All of this was, of course, done under Linux.

First tryout of AVRs

I bought a few programmers some time ago. On eBay, for around 16 dollars american. They’re a copy of Thomas’ Fischl’s USBasp. Now I’m toying around with them – a part of my summer internship.

First off, I tried connecting one working programmer to the other and see how it goes. Well, FreeBSD couldn’t recognize it:

avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc

This is since I’m using a laptop. It has ppi (parallel port interface) in the kernel, but it doesn’t have a parallel port. And avrdude simulates writing to a parallel port for programming, or something like that. So, no /dev/ppi0 – no programming.

So I turned Windows back on and tried the avrdude that comes with WinAVR (version 20080610). It couldn’t locate USBasp also, but for a different reason: the libusb driver that comes with USBasp is outdated or something. The latter link leads to another one, where you can download the new driver. Also, this page with error explanations (linked in the same thread) was somewhat useful.

So, then Windows and avrdude saw the USBasp programmer I was using, but didn’t see the second identical USBasp programmer (known to work) that I used as a target (even if both of them had the green power light on):

avrdude: error: programm enable: target doesn't answer. 1

I set the “self-programming” jumper on the target, but that didn’t help right away. It did turn the target’s “power” LED off.

I additionally had to set the “slow SCK” fuse on both the programmer and the target. Otherwise there was some trouble reading the target chip signature:

avrdude: Device signature = 0x0000ff
avrdude: Expected signature for ATMEGA8 is 1E 93 07
avrdude: safemode read 1, lfuse value: ff
avrdude: safemode read 2, lfuse value: ff
avrdude: safemode read 3, lfuse value: 0
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may
not be reliable.
avrdude: safemode: To protect your AVR the programming will be aborted

Then I got this:

avrdude: Device signature = 0x1e9307
avrdude: safemode read 1, lfuse value: ff
avrdude: safemode read 2, lfuse value: ff
avrdude: safemode read 3, lfuse value: ff
avrdude: safemode: lfuse reads as FF
avrdude: safemode read 1, hfuse value: d9
avrdude: safemode read 2, hfuse value: d9
avrdude: safemode read 3, hfuse value: d9
avrdude: safemode: hfuse reads as D9

At this point, I could basically dump the target’s memory, program it, etc.. Note that the fuse values on these programmers that I’ve bought are somewhat different from those specified in the USBasp readme.

So to sum up, the jumper positions are:

power: programmer – Vusb, target – Vtarget;
self-programming: programmer – off, target – on;
slow SCK: programmer – on, target – on.

I’ll write up what happens next.