Device not enumerating on 328p

[EmbeddedDesign]

I cannot seem to enter the bootloader on a 328p device.

I'd like to use this project to take advantage of the lovely bootloader entry/exit options as my project does not have a user accessible button which seems to be required by most other V-USB based projects.
I'm confident that my hardware implementation is sound as I can successfully enter the bootloader and upload application firmware using similar projects such as USnooBie's bootloader which is essentially the same hardware setup I'm using but with no jumpers or buttons.

bootloaderconfig.inc includes the following to match my setup:

F_CPU      = 12000000
DEVICE     = atmega328p
PROGRAMMER = -c usbtiny

The following directives are set in bootloaderconfig.h

#define USB_CFG_IOPORTNAME  D
#define USB_CFG_DMINUS_BIT  7
#define USB_CFG_DPLUS_BIT   2

I have tried defining each of these three options independently in bootloaderconfig.h but the result is the same inability to enter the bootloader upon USB connection, power, or reset:

#define BOOTLOADER_ON_POWER 1
#define BOOTLOADER_ON_USB 1
#define BOOTLOADER_ON_RESET 1

The project builds fine except for the warning:

In file included from main.c:25:0:
usbdrv/usbdrv.h:223:24: warning: ‘usbFunctionDescriptor’ used but never defined
 USB_PUBLIC usbMsgLen_t usbFunctionDescriptor(struct usbRequest *rq);

but this seems fairly common to USBasp projects.

make fuse runs fine but seems to fail on the extended byte fuse for some reason:

avrdude -c usbtiny -p atmega328p -U lfuse:w:0xd7:m -U hfuse:w:0xd0:m -U efuse:w:0x04:m
[...successful writes omitted...]
avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

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

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

Reading | ################################################## | 100% 0.00s

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

avrdude: safemode: efuse changed! Was 4, and is now fc
Would you like this fuse to be changed back? [y/n]

Regardless of the input here, flashing runs without issue but results in safemode setting the fuses to:
E:04, H:D0, L:D7

I can then flash my application code without issue but regardless of what I do, the device, when connected via USB, fails to enumerate.

user@host:$dmesg
[ 4566.665389] usb usb7-port1: unable to enumerate USB device
[ 4566.877361] usb 7-1: new low-speed USB device number 92 using ohci-pci
[ 4567.017365] usb 7-1: device descriptor read/64, error -62
[ 4567.261384] usb 7-1: device descriptor read/64, error -62
[ 4567.501384] usb 7-1: new low-speed USB device number 93 using ohci-pci
[ 4567.641377] usb 7-1: device descriptor read/64, error -62
[ 4567.885382] usb 7-1: device descriptor read/64, error -62
[ 4568.125387] usb 7-1: new low-speed USB device number 94 using ohci-pci
[ 4568.533421] usb 7-1: device not accepting address 94, error -62
[ 4568.669407] usb 7-1: new low-speed USB device number 95 using ohci-pci
[ 4569.077406] usb 7-1: device not accepting address 95, error -62
[ 4569.077438] usb usb7-port1: unable to enumerate USB device

[EmbeddedDesign]

Like many of life's problems, this one appears to have been fuse related after all.

After checking the default fuse settings and comparing them to my setup I made adjustments to disable brownout detection and use the correct clock input/frequency for my setup.
I wound up with:
FUSEOPT_328 = -U lfuse:w:0xff:m -U hfuse:w:0xd0:m -U efuse:w:0xff:m
which allows make fuse and make flash to pass without any errors and succesfully loads the bootloader and enumerates as expected when plugged in to USB with BOOTLOADER_ON_USB set.

[16346.279750] usb 7-2: new low-speed USB device number 11 using ohci-pci
[16346.455844] usb 7-2: New USB device found, idVendor=16c0, idProduct=05dc
[16346.455852] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[16346.455857] usb 7-2: Product: USBasp
[16346.455861] usb 7-2: Manufacturer: www.fischl.de

Interestingly, the device will fail to enter the bootloader or enumerate when plugged in if I flash application code (such as a simple blink example) using my usbtiny programmer via ISP (the same way the bootloader was written).

• Any idea what might cause this?

I can, however, upload application code via USB using the uspasp protocol, though it often reports wrong count/responds size:

Writing | ######avrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong count at writing ffffffff
####################avrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
######################## | 100% 12.05s

but seems to recover and verifies correctly:

Reading | ################################################## | 100% 0.09s
avrdude: verifying ...
avrdude: 988 bytes of flash verified

Lowering the baud rate -b from 115200 to 57600 seems to help a little but this seems like unusual behavior.

• Any thoughts on how to avoid this issue?

[gblargg]

the device will fail to enter the bootloader or enumerate when plugged in if I flash application code (such as a simple blink example) using my usbtiny programmer via ISP (the same way the bootloader was written).

Seems either usbtiny is changing the fuse settings (e.g. bootloader flag, or a clock rate flag), or erasing part of the bootloader area.

I can, however, upload application code via USB using the uspasp protocol, though it often reports wrong count/responds size:

Hmmm, I never saw that when I was using it. I'll have to pull a 328p board out when I have time and see whether I can get it to occur.

Lowering the baud rate -b from 115200 to 57600 seems to help a little but this seems like unusual behavior.

I didn't think that would have any effect on USB transfers. If it's intermittent then random things can seem to be influencing it, heh. Thanks for contacting me.

[EmbeddedDesign]

Hi @gblargg

Thank you by the way for the awesome USBaspLoader feature updates! I know this project is a little old but it's exactly what I was looking for.

I was able to resolve not being able to upload application firmware with the programmer after writing the bootloader. avrdude was indeed erasing the flash, so simply passing -D as an argument prevented this and it seems to work fine now.

The connection timeouts when uploading via USB seem to persist.
I wouldn't have thought the baud rate -b or bitclock -B settings would effect USB transfers either but it kind of seems to make some difference. Perhaps they don't, I'm not sure.

With a 328p running at 12MHz, baud rate at 115200 and bitclock set to auto (assuming these matter) I'm able to flash via USB without issue for small images.

avrdude: writing flash (988 bytes):

Writing | ################################################## | 100% 0.16s

avrdude: 988 bytes of flash written
avrdude: verifying flash memory against test.hex:
avrdude: load data flash data from input file test.hex:
avrdude: input file blink.hex contains 988 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.10s

avrdude: verifying ...
avrdude: 988 bytes of flash verified

Larger images still exhibit the connection timeout issue however and will generally fail to verify.

avrdude: writing flash (20350 bytes):

Writing | ###                                                | 6% 0.49savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong count at writing ffffffff
Writing | #######                                            | 13% 10.96savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ############                                       | 23% 20.13savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ##############                                     | 28% 27.21savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ##################                                 | 36% 35.54savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ###################                                | 38% 41.37savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ########################                           | 48% 50.54savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ###########################                        | 54% 58.03savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | #############################                      | 57% 64.28savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ##############################                     | 60% 70.53savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ###############################                    | 61% 75.94savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ###############################                    | 62% 81.36savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ######################################             | 75% 91.78savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | #######################################            | 78% 98.03savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ###########################################        | 86% 106.36savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | #############################################      | 89% 112.61savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
Writing | ################################################## | 100% 122.20s

avrdude: 20350 bytes of flash written
avrdude: verifying flash memory against test.hex:
avrdude: load data flash data from input file test.hex:
avrdude: input file selestia.hex contains 20350 bytes
avrdude: reading on-chip flash data:

Reading | ###########                                        | 21% 1.23savrdude: error: usbasp_transmit: Connection timed out
Reading | #########################################          | 81% 9.55savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong reading bytes ffffffff
Reading | #########################################          | 82% 14.62savrdude: error: usbasp_transmit: Connection timed out
avrdude: error: wrong responds size
avr_read(): error reading address 0x2c1c
    read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2

I've tried various known good cables, as well as both USB 2.0 and 3.0 ports and hubs to no avail.