[Top][All Lists]

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

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

From: Joerg Wunsch
Subject: Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude 6.0.1
Date: Sun, 21 Sep 2014 18:40:27 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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

Never trust an operating system you don't have sources for. ;-)

reply via email to

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