> I would avoid that kind of hackery if possible. Ha - I'll I've got is hacked on ideas unfortunately ;-) But if there's some underlying fix that would make sense to apply.
As a counterpoint - one could argue the usb drain command is itself a hack, as there shouldn't be extra data we drain away from the endpoint. Tools that require the drain to operate are probably not implementing the protocol correctly, as they aren't reading all the data from the endpoint. Or the USB tool itself is in some incorrect state and sending data at the wrong time. I've got a USB hardware analyzer here so will take a moment to see if I can see anything causing it, although I seem to recall a message from Dean a while back about going down that rabbit hole, and ending up at a fairly low level. If it's a bug in libusb or something it would be nice to fix, but then I don't know how long it would take to deploy to users? I'll try to make a hex for the at90usb1287 too later that you can use. I'm 95% sure you don't need a target, just attempting to sign onto the AVR-ISP MKII would cause the error. Won't have a change to look at that until later today though my time (GMT-4) so don't hold out too much, as something else might come up... I guess we've had this issue for several years already, so presumably nobody is in too big a rush! Regards, -Colin O'Flynn -----Original Message----- From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de] Sent: September-21-14 1:40 PM To: avrdude-dev@nongnu.org Cc: Colin O'Flynn; Dean Camera Subject: Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1 As Dean Camera wrote: > > Assuming things are working well one shouldn't need the drain > > stuff as you mention. I was never sure why the drain trips up Dean's > > MK2 code, but it does seem to be the problem. > By the time the drain code is called, my code has already switched the > direction on the USB AVR's data endpoint -- since the USB AVRs don't > supported bidirectional endpoints (having an IN and an OUT on the same > index) I have to work around it via manual switching. That's pretty normal though; only the control endpoint is usable in both directions, data EPs need one EP per direction. > However, having > the host read from the IN address when the USB AVR has swapped the > direction to OUT apparently causes libUSB or another layer to choke > and abort the session. Rather than adding any kind of hack, we should analyze the actual problem on this. After all, the other USB-based tools have the same problem. Even though they are using a different chip on the USB interface, they have one EP per direction. If you tell me what to reproduce, I can run this through a hardware USB analyzer. What hardware do I need? I've got an RZRAVEN USB stick (employing an AT90USB1297) around, can I make that work? (It probably has too few pins wired to outside to act as a real programmer, but if it can be reproduced already without a target connected, it might do the job.) > Disabling the drain code for USB makes sense to me at least - I'd > recommend having it disabled for all USB tools by default, with the > command line option to turn it back on as you suggest. Having it on > but only for some USB tools would only lead to confusion. I would avoid that kind of hackery if possible. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
