avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] [bug #34339] back to back avrdude commands fail on dra


From: Bill Perry
Subject: Re: [avrdude-dev] [bug #34339] back to back avrdude commands fail on dragon_isp on Ubuntu 10.10
Date: Thu, 08 Dec 2011 02:37:13 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

I can't speak for other OS's but not doing the usb_reset() on Ubuntu 10.10
which is kernel 2.6.35-31 does not work and makes things worse.

With the usb_reset() in place using the stock 5.11.1 code you get this
message
with back to back commands on a avr dragon.
*avrdude: usbdev_open(): did not find any USB device "usb"*


With no usb_reset() in usbdev_close(), you get these messages instead:
*avrdude: usb_open(): cannot read serial number "error sending control
message: Cannot send after transport endpoint shutdown"
avrdude: usb_open(): cannot read product name "error sending control
message: No such device"
avrdude: usbdev_open(): error setting configuration 1: could not set
config 1: No such device
avrdude: usbdev_open(): did not find any USB device "usb"*
and the second command fails.

Adding in the USB device polling in usbdev_open()  but still not doing
the usb_reset() in usbdev_close()
makes it work but there is a long pause/stall on the second command after
getting the above errors other than the "did not find any USB device" error.
This seems to match behavior in the comment in usbdev_close() about the
AVRISP mkII.

So it appears that the usb_reset() is still very much needed to get
things back synchronized
at least for Ubuntu 10.10

--- bill



On 12/08/2011 01:52 AM, Xiaofan Chen wrote:
> On Thu, Dec 8, 2011 at 3:20 PM, Joerg Wunsch <address@hidden> wrote:
>> Follow-up Comment #10, bug #34339 (project avrdude):
>>
>> For those reasons, I'll probably add another commandline option to
>> activate the hack (like, -x usb_wait_time=3).  Obviously, this
>> requires Arduino users to change their Makefiles then in order to
>> benefit from the hack, which poses the question why they could not
>> change their Makefiles for a single avrdude command in the first place
> I think the root cause of the issue is the following codes
> in usb_libusb.c.
>
> #if !( defined(__FreeBSD__) ) // || ( defined(__APPLE__) &&
> defined(__MACH__) ) )
>   /*
>    * Without this reset, the AVRISP mkII seems to stall the second
>    * time we try to connect to it.  This is not necessary on
>    * FreeBSD.
>    */
>   usb_reset(udev);
> #endif
>
> I believe the above usb_reset() is no longer needed for most of
> the Linux users now. It is usually only required for kernel versions
> up to 2.6.28.
> http://libusb.6.n5.nabble.com/Why-does-Linux-forget-the-USB-toggle-bit-of-my-device-td6829.html
> From Alan Stern, one of the leading Linux USB kernel developer.
> "Kernel versions prior to 2.6.28 will always send a Set-Interface
> request when your program releases its interface (or when it closes the
> device file).  If the device doesn't support this request then the
> kernel sends Clear-Halt for each endpoint in the interface.  These
> requests are supposed to set the data toggle back to 0, but many
> devices don't support them properly."
>
> The symptom for these older kernels is usually the program
> runs fine the first time and then failed in the second time
> because data toggle becomes wrong after the first operation.
> Then usb_reset() is added as a workaround to reset()
>
> usb_reset() itself is a hack in this case. I think it is probably easier
> to make the above codes optional, probably by adding an extra
> command line option to enable the codes for older kernel versions
> and problematic device which really needs it. This should make
> avrdude faster and reliable for most of the users for back to
> back operation.
>
> To Bill: you can always try to rebuild avrdude without the
> above usb_reset() code and see if it works for you or not.
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]