[avrdude-dev] [bug #34339] back to back avrdude commands fail on dragon_isp on Ubuntu 10.10

[Bill Perry]

Follow-up Comment #5, bug #34339 (project avrdude):

One final comment just to provide the complete information
and background about this issue all in one place/post.

SUMMARY:
=============================================================

This is an issue in avrdude (usb_libusb module) caused by avrdude
resetting the USB when it closes certain USB devices.
It happened to show up when using the Arduino IDE or their makefiles 
when attempting to burn a bootloader image
due to the way they use avrdude when burning a bootloader using the avr
dragon.

The essential issue is that back to back avrdude commands can fail on certain
USB devices.

OSs affected:
- All except BSD.

USB Devices affected:
Any device that calls usbdev_open()/usbdev_close() which currently is:
- JTAG ICE mkII
- AVR Dragon 
- AVRISP mkII
- any device that uses USB on stk500v2 or stk600

USB Devices not affected:
- USBtiny
- USBASP


Workarounds:
- Delay 3+ seconds between back to back avrdude commands
- modify avrdude commands to collapse multiple commands into a single avrdude
command.

======================================================
Additional detailed background

Whenever you do back to back avrdude commands, the second
avrdude command can fail on certain USB devices because the previous avrdude
command resets the USB
and that requires re-enumerating the USB device.
If the second avrdude command runs before the USB device has fully
enumerated,
when avrdude looks for the USB device, it will appear to not be there.

avrdude does an explicit usb reset on all OS's other than BSD
when it closes the USB connection.
(The comment in  usbdev_close()  in usb_libusb.c mentions the  AVRISP mkII)
Given that avrdude is resetting the USB and creating this enumeration race
condition,
avrdude should also properly handle dealing with the ramifications of
doing that USB bus reset.

The solution is quite simple: Poll for the USB device over a period of time.
(a few seconds)
instead of just looking for the USB device just once.

avrdude is currently not taking advantage of libusb capabilities that it
could
use to ensure that a USB device that is on the USB it resets during close is
fully enumerated by attempting retries when looking for
the USB device at open.
As a result, when you do back to back avrdude commands on certain USB devices
the second command will
fail if your USB device is not quickly re-enumerated.

This problem shows up on linux as well as Windows XP and probably other OSs as
well.
It is very easy to replicate using the Dragon on either OS.

It is a trivial fix to avrdude to poll up to a few seconds when looking
for the USB device rather than just look once.
(It is only 6 lines of code)

With the small patch provided earlier,
if the USB device fully enumerated before the search for it was done, there is
no added delay.
If it is not enumerated yet, the code will poll for it up to the timeout
period
(patch used 3 seconds) until the device is enumerated.
If the device is not present, it will poll the full timeout period and then
error off just like it does now.

The patch seemed like a nice easy solution to the problem since it
uses the existing code to handle everything and is not specific to the AVR
Dragon.
It simply adds a level of robustness to the USB device connection code by
polling
for the device rather than only looking for it a single time.


Devices like USBtiny and USBASP don't experience this issue because they
don't
call the usbdev_open() or usbdev_close() functions in usb_libusb.c
They have their own versions of the same routines that they use, so that
when
the USB connection is closed the USB bus is not reset.
While they don't poll for the USB device in their open routines, because
they don't reset the USB
in their close routine, those devices don't have to re-enumerate and the
problem is avoided.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34339>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/