Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1

[Colin O'Flynn]

> 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:address@hidden 
Sent: September-21-14 1:40 PM
To: address@hidden
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. ;-)