AvrUsbBoot on ATmega168

[spiff]

I have been trying to make AvrUsbBoot work with ATmega168. What I have done is set the appropriate parameters in bootloaderconfig.h, and alter the Makefile appropriately:

Code: Select all

BOOTLOADER_ADDRESS = 3800
LDFLAGS += -Wl,--section-start=.text=$(BOOTLOADER_ADDRESS)
COMPILE = avr-gcc -Wall -Os -Iusbdrv -I. -mmcu=atmega168 -DGICR=MCUCR

As far as I can see this should be all that I needed: The register defining IVCE and IVSEL is handled by the define on the command line. The correct MCU has been defined.

I have put in a little debugging code that lights a LED when the bootloader is activated, and this works as expected. In other words everything seems to be fine with fuse configuration etc.

Yet, all that happens when I plug in the device is that windows shows the "USB device not recognized" balloon. When I put my other code (my SpiffChorder firmware) in the device and set the fuses accordingly, the device works fine, so I believe the hardware should be OK.

Any suggestions to what I might be missing here would be appreciated.

Kind regards

[spiff]

I found a different thread with a problem that could be related:
http://forums.obdev.at/viewtopic.php?t=1327

Then I stumbled upon the following in the AvrUsbBoot Makefile:

Code: Select all

OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o
# Note that we link usbdrv.o first! This is required for correct alignment of
# driver-internal global variables!

Could this be a cause of my problems?

I don't think so, 'cause I did what the author of the other thread suggested, namely trying to link the application for use at address 0, putting it in the MCU and turning the boot fuse off. Code correctly starts, but Windows still reports "Usb Device Not Recognized".

[christian]

This is an old note. Recent versions of AVR-USB don't have this requirement any more.

If the boot loader fails to work, please check the usual things: fuses, speed selection in usbconfig.h, level conversion for D+ and D- etc.

[spiff]

This is an old note. Recent versions of AVR-USB don't have this requirement any more.

If the boot loader fails to work, please check the usual things: fuses, speed selection in usbconfig.h, level conversion for D+ and D- etc.

But the version of AVR-USB used for the bootloader is also very old. I have not tried replacing it, but there are only a few bytes left in the bootloader section, so I am worried that replacing it means it will not fit in the bootloader. This is why I have been using the old version so far.

Of course this could also be the reason for it not working with ATmega168, although I would suspect it would work with the other author having made it work on ATmega1281.

You suggestion of the clock rate seems like it would explain what I am seeing: Code starts correctly (lights an LED), but USB does not work. This is the exact same code I used to use with my ATmega8, and also the same hardware, except that I changed the controller.

So I'm using a 12MHz Xtal, and I think perhaps this old version of AVR-USB only supports 12MHz, because I have found no place defining the clock speed. I have checked the fuses several times, and I am positive they should work (configured for external crystal). Also, the only fuse I changed when I tried putting my working spiffchorder code in the device was the bootrz, selecting the bootloader section or not.

For the level conversion, I use 3.6V zeners (low power types), as I have used before, and again, the hardware works with my SpiffChorder code.

I just don't get it.

[spiff]

OK, I decided to try a newer driver, to see if it would fit in the bootloader section. Turns out it is actually considerably smaller (about 100 bytes) than the one included in the AvrUsbBoot archive. I ported each of the options from the old usbconfig.h, but I am not really sure what VID/PID the old one used, since that part of the config was commented out. I assume this means to use ObDev's VID/PID pair, but when I try doing the same with the newer driver, I get warnings about needing to define it anyway.

Turns out that if I ignore the warnings and compile anyway, I actually get a working bootloader. At least to the point where the device is detected as AVRUSBoot. Perhaps the old driver which needed special alignment was indeed the culprit.

Now, the problem is getting further away from the avr-usb stack, and I might be getting off-topic in this forum, but my observation is this: When I try to use the avrusbboot application, I get this error:

Code: Select all

C:\avr\SpiffChorder>avrusbboot main.hex
Pagesize: -128

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I assume this is some signed/unsigned stuff in the application, but I haven't looked into it yet. Also, I don't remember if I compiled the avrusbboot application on Windows myself, or if I found a prebuilt binary. In any case I guess the best option would be to get in touch with Thomas Fischl and ask him if he will include my patches into his version.

One more question: I got confused about the device asking for a driver when I plugged it in. Turns out that this happens if i use a different USB port on my computer than what I have normally used with AVRUSBBoot. Do I need to re-install the driver for every port, and what driver is it exactly? I must have installed it for one port a long time ago (about a year ago, when I first looked at AVRUSBBoot), but I have forgotten what I did.

EDIT: I just found the driver in the AVRUSBBoot distribution.

[christian]

As you already found out: We take great care to ensure that newer versions have the same or less code size than previous versions.

Regarding VID/PID: We added a warning if it's not defined in usbconfig.h because we want to make sure that people know what they are doing. Simply add obdev's free VID/PID pair for custom class devices to usbconfig.h.

And finally the page size issue: I have not tried AVRUSBBoot myself with the Mega168. You might consider using BootloadHID. It avoids the driver issue on Windows and the page size thing is handled by the AVR firmware, not the host side driver. Or you use USBaspLoader. This one has been tested with the Mega168 and the host side software is avrdude.