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

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
Update of bug #40831 (project avrdude):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #1:

It's still not quite clear to me why this happens.

The statement you quoted is only supposed to trigger if the
read endpoint number (usb.rep) has not been set by the driver
before (== 0).  An endpoint number of 0 is always reserved for
the control endpoint, and cannot be a data endpoint anyway.
Then, a (half-hearted) attempt is made inside usb_libusb.c to
pick the first data endpoint in the configuration that has the
"IN" direction bit (0x80) set, and this one is used for usb.rep.
(Arguably, this procedure still leaves a lot room for
improvements, yes.)

Can you please post a full USB descriptor from the LUFA
firmware?

    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
Follow-up Comment #2, bug #40831 (project avrdude):

OK, I see it in your file now:

The LUFA firmware _requires_ the EP guesswork heuristics to
work.

OK, this really asks for doing it right then.

    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
Update of bug #40831 (project avrdude):

                  Status:               Need Info => None                  


    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
Follow-up Comment #3, bug #40831 (project avrdude):

Looking over the source code, it appears the issue is that the USB endpoints
are already pre-filled by the upper tool layer:

(In STK500v2.c:)
    pgm->fd.usb.rep = USBDEV_BULK_EP_READ_MKII;
    pgm->fd.usb.wep = USBDEV_BULK_EP_WRITE_MKII;


That means the read endpoint heuristics inside usb_libusb.c will not trigger
for known Atmel tools, and the code will assume that the read endpoint is
always equal to the tool defaults. This breaks for LUFA programmers in libUSB
compatibility mode, as the read endpoint index is changed to 0x83 (but the
descriptors are otherwise identical).

    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
Follow-up Comment #4, bug #40831 (project avrdude):

Since there is already a read endpoint fallback in usb_libusb.c:

if (fd->usb.rep == 0)
                        {
                          avrdude_message(MSG_INFO, "%s: usbdev_open(): cannot find a read
endpoint, using 0x%02xn",
                                          progname,
USBDEV_BULK_EP_READ_MKII);
                          fd->usb.rep = USBDEV_BULK_EP_READ_MKII;
                        }

Should we either set the usb.rep value to 0 in the upper tool layer, or
explicitly zero it out in the usb layer?

    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin O'Flynn
Hi Dean/Joerg,

Keeping my reply on the list & not bugtracker as not directly related to
that bug:

Do you think it's worth fixing the issue forcing the separate endpoints?
AFAIK the issue is triggered by a call to usbdev_drain() which might be
possible to work around (read: just disable for avr-isp2).

I only ask as if this is fixed it might add another complication to the
system, and I don't know if it would become worth making two separate
AVR-ISPmk2 programmers at that point. One has the 'libusb' fixes and assumes
the two separate endpoints, (i.e. called avrisp2lufa or whatever), one
always assumes endpoints are as in Atmel AVRISP-MK2.

I assume it would be possible to differentiate between the 3 programmers and
enable the correct code (i.e.: Atmel AVR-ISPMK2, LUFA AVR-ISPMK2 in
AVRStudio Mode, LUFA AVR-ISPMK2 in LIBUSB Mode). But it might become a
ungainly/difficult to maintain into the future, and ultimately be easier at
some point in time say screw it to the users, and make them specify exactly
what they want.

Regards,

  -Colin O'Flynn



-----Original Message-----
From: avrdude-dev-bounces+coflynn=[hidden email]
[mailto:avrdude-dev-bounces+coflynn=[hidden email]] On Behalf Of Dean
Camera
Sent: September-13-14 4:54 AM
To: Dean Camera; Larry Viesse; Joerg Wunsch; Ron Snijders;
[hidden email]
Subject: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude
6.0.1

Follow-up Comment #4, bug #40831 (project avrdude):

Since there is already a read endpoint fallback in usb_libusb.c:

if (fd->usb.rep == 0)
                        {
                          avrdude_message(MSG_INFO, "%s: usbdev_open():
cannot find a read endpoint, using 0x%02xn",
                                          progname,
USBDEV_BULK_EP_READ_MKII);
                          fd->usb.rep = USBDEV_BULK_EP_READ_MKII;
                        }

Should we either set the usb.rep value to 0 in the upper tool layer, or
explicitly zero it out in the usb layer?

    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dean Camera-3
Hi Colin,

Yes, of course ultimately I'd love to get AVRDUDE out-of-the-box
compatible with my programmer. However, I realize Joerg et. al. may feel
differently, since my firmware is only a clone of the real thing, and
limited by the hardware platform that I have designed it for. I don't
really expect Joerg or the other developers to put in extra effort to
make my clone firmware work correctly.

That said, I think we have the potential for some quick fixes here that
shouldn't impact users of the real-deal.

The first is the fixing of the endpoint selection, which currently
blocks all users of AVRDUDE from using my clone programmer completely,
as the workaround I have for the second incompatibility involves using
different endpoint addresses to the real units, which AVRDUDE-HEAD
ignores. If we can fix the endpoint detection code, users will be able
to use the "libUSB compatibility mode" firmware I built to work around
the second issue.

The second issue is the serial drain code in AVRDude tripping up my
limited bidirectional endpoint code. Turning this code off eliminates
the need for my compatibility mode firmware, and makes my clone
completely out-of-the-box AVRDUDE compatible. However, that may have
ramifications I am not aware of, so Joerg would need to weigh in.

Cheers!
- Dean

On 15/09/2014 9:06 AM, Colin O'Flynn wrote:

> Hi Dean/Joerg,
>
> Keeping my reply on the list & not bugtracker as not directly related to
> that bug:
>
> Do you think it's worth fixing the issue forcing the separate endpoints?
> AFAIK the issue is triggered by a call to usbdev_drain() which might be
> possible to work around (read: just disable for avr-isp2).
>
> I only ask as if this is fixed it might add another complication to the
> system, and I don't know if it would become worth making two separate
> AVR-ISPmk2 programmers at that point. One has the 'libusb' fixes and assumes
> the two separate endpoints, (i.e. called avrisp2lufa or whatever), one
> always assumes endpoints are as in Atmel AVRISP-MK2.
>
> I assume it would be possible to differentiate between the 3 programmers and
> enable the correct code (i.e.: Atmel AVR-ISPMK2, LUFA AVR-ISPMK2 in
> AVRStudio Mode, LUFA AVR-ISPMK2 in LIBUSB Mode). But it might become a
> ungainly/difficult to maintain into the future, and ultimately be easier at
> some point in time say screw it to the users, and make them specify exactly
> what they want.
>
> Regards,
>
>    -Colin O'Flynn
>
>
>
> -----Original Message-----
> From: avrdude-dev-bounces+coflynn=[hidden email]
> [mailto:avrdude-dev-bounces+coflynn=[hidden email]] On Behalf Of Dean
> Camera
> Sent: September-13-14 4:54 AM
> To: Dean Camera; Larry Viesse; Joerg Wunsch; Ron Snijders;
> [hidden email]
> Subject: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude
> 6.0.1
>
> Follow-up Comment #4, bug #40831 (project avrdude):
>
> Since there is already a read endpoint fallback in usb_libusb.c:
>
> if (fd->usb.rep == 0)
> {
>  avrdude_message(MSG_INFO, "%s: usbdev_open():
> cannot find a read endpoint, using 0x%02xn",
>                                            progname,
> USBDEV_BULK_EP_READ_MKII);
>  fd->usb.rep = USBDEV_BULK_EP_READ_MKII;
> }
>
> Should we either set the usb.rep value to 0 in the upper tool layer, or
> explicitly zero it out in the usb layer?
>
>      _______________________________________________________
>
> Reply to this item at:
>
>    <http://savannah.nongnu.org/bugs/?40831>
>
> _______________________________________________
>    Message sent via/by Savannah
>    http://savannah.nongnu.org/
>
>
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev
>


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch
As Dean Camera wrote:

> I don't
> really expect Joerg or the other developers to put in extra effort to
> make my clone firmware work correctly.

Clone or not, that doesn't matter here.  AVRDUDEs goal is to be
able to talk to any known general-use AVR programmer around.

> The first is the fixing of the endpoint selection, ...

I don't mind improving that heuristics.  The way it is now, I simply
didn't spend any effort into an automatic selection, since basically,
the EP numbers are written down in the Atmel protocol documents, so it
wasn't envisioned they would ever change.

If someone wants to put in a real heuristic here, please go ahead, and
do it.  The only requirement is that it doesn't break support for any
of the official tools, or anything else using the libusb code by now.

For the JTAGICE3, keep in mind there are two fundamentally different
firmware levels that need to be supported.  FW version up to 2.x use
two bulk EPs for communication, plus one interrupt EP for event
reporting, while 3.x firmware uses two interrupt EPs (HID class) for
everything.  So creating a heuristic that works with every device
without being required to add special hacks based on individual
product strings or PIDs is a bit of a challenge, but not impossible.

> The second issue is the serial drain code in AVRDude tripping up my
> limited bidirectional endpoint code.

I'm not sure how useful all the draining stuff is at all if the
backend is sitting on USB.  Basically, it's there since the days
when programmer have been connected to real serial devices.

The current implementation of usbdev_drain() is meant to be as little
intrusive as possible though: read from the EP until it tells there
are no more data around.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin O'Flynn
Hi All,

> I don't really expect Joerg or the other developers to put in extra effort
to make my clone firmware work correctly.

I've got a vested interest in making it work, as am using that code myself.
And it seems your LUFA clone pops up all over the place, at least going by
how many google hits I got for it & the problem when first looking into it.

>> The second issue is the serial drain code in AVRDude tripping up my
>> limited bidirectional endpoint code.
>I'm not sure how useful all the draining stuff is at all if the backend is
sitting on USB.  Basically, it's there since the days when >programmer have
been connected to real serial devices.

Indeed, the original addition of the usb_drain() code has a comment about
fixing an odd state in the JTAG-ICE, where I assume things get
unsynchronized and it's sending more data than expected.

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. I globally disabled the drain stuff on my own
build of AVRDude and haven't had problems, although I only have a few tools
to test against.

My thought was one of two options for doing this:

1) Turn it off on a per-programmer basis (i.e. for AVR-ISP MK2 only).
Originally thought via the config file, although I now notice it might be
possible to disable inside of usb_libusb.c for the AVR-ISPMK2 only, which
would be the most clean option.
2) Turn if off globally, but with a command-line switch to re-enable it in
case it broke something

Let me know your thoughts - I'm happy to try contributing a patch for either
option. I started up bug report #43268 to track the issue without stealing
your bug report Dean ;-)

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Joerg Wunsch [mailto:[hidden email]]
Sent: September-21-14 6:34 AM
To: [hidden email]
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:

> I don't
> really expect Joerg or the other developers to put in extra effort to
> make my clone firmware work correctly.

Clone or not, that doesn't matter here.  AVRDUDEs goal is to be able to talk
to any known general-use AVR programmer around.

> The first is the fixing of the endpoint selection, ...

I don't mind improving that heuristics.  The way it is now, I simply didn't
spend any effort into an automatic selection, since basically, the EP
numbers are written down in the Atmel protocol documents, so it wasn't
envisioned they would ever change.

If someone wants to put in a real heuristic here, please go ahead, and do
it.  The only requirement is that it doesn't break support for any of the
official tools, or anything else using the libusb code by now.

For the JTAGICE3, keep in mind there are two fundamentally different
firmware levels that need to be supported.  FW version up to 2.x use two
bulk EPs for communication, plus one interrupt EP for event reporting, while
3.x firmware uses two interrupt EPs (HID class) for everything.  So creating
a heuristic that works with every device without being required to add
special hacks based on individual product strings or PIDs is a bit of a
challenge, but not impossible.

> The second issue is the serial drain code in AVRDude tripping up my
> limited bidirectional endpoint code.

I'm not sure how useful all the draining stuff is at all if the backend is
sitting on USB.  Basically, it's there since the days when programmer have
been connected to real serial devices.

The current implementation of usbdev_drain() is meant to be as little
intrusive as possible though: read from the EP until it tells there are no
more data around.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dean Camera-3
 > 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. 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.

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.

The good news is that by fixing that I think I can remove my libUSB
compatibility code entirely, leaving a single firmware that works across
Atmel Studio, AVRStudio and AVRDUDE. Less confusion for users is always
a great goal - it's always been a real pain to have the two different
firmwares.

Cheers!
- Dean


On 21/09/2014 9:36 PM, Colin O'Flynn wrote:

> Hi All,
>
>> I don't really expect Joerg or the other developers to put in extra effort
> to make my clone firmware work correctly.
>
> I've got a vested interest in making it work, as am using that code myself.
> And it seems your LUFA clone pops up all over the place, at least going by
> how many google hits I got for it & the problem when first looking into it.
>
>>> The second issue is the serial drain code in AVRDude tripping up my
>>> limited bidirectional endpoint code.
>> I'm not sure how useful all the draining stuff is at all if the backend is
> sitting on USB.  Basically, it's there since the days when >programmer have
> been connected to real serial devices.
>
> Indeed, the original addition of the usb_drain() code has a comment about
> fixing an odd state in the JTAG-ICE, where I assume things get
> unsynchronized and it's sending more data than expected.
>
> 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. I globally disabled the drain stuff on my own
> build of AVRDude and haven't had problems, although I only have a few tools
> to test against.
>
> My thought was one of two options for doing this:
>
> 1) Turn it off on a per-programmer basis (i.e. for AVR-ISP MK2 only).
> Originally thought via the config file, although I now notice it might be
> possible to disable inside of usb_libusb.c for the AVR-ISPMK2 only, which
> would be the most clean option.
> 2) Turn if off globally, but with a command-line switch to re-enable it in
> case it broke something
>
> Let me know your thoughts - I'm happy to try contributing a patch for either
> option. I started up bug report #43268 to track the issue without stealing
> your bug report Dean ;-)
>
> Regards,
>
>    -Colin O'Flynn
>
> -----Original Message-----
> From: Joerg Wunsch [mailto:[hidden email]]
> Sent: September-21-14 6:34 AM
> To: [hidden email]
> 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:
>
>> I don't
>> really expect Joerg or the other developers to put in extra effort to
>> make my clone firmware work correctly.
> Clone or not, that doesn't matter here.  AVRDUDEs goal is to be able to talk
> to any known general-use AVR programmer around.
>
>> The first is the fixing of the endpoint selection, ...
> I don't mind improving that heuristics.  The way it is now, I simply didn't
> spend any effort into an automatic selection, since basically, the EP
> numbers are written down in the Atmel protocol documents, so it wasn't
> envisioned they would ever change.
>
> If someone wants to put in a real heuristic here, please go ahead, and do
> it.  The only requirement is that it doesn't break support for any of the
> official tools, or anything else using the libusb code by now.
>
> For the JTAGICE3, keep in mind there are two fundamentally different
> firmware levels that need to be supported.  FW version up to 2.x use two
> bulk EPs for communication, plus one interrupt EP for event reporting, while
> 3.x firmware uses two interrupt EPs (HID class) for everything.  So creating
> a heuristic that works with every device without being required to add
> special hacks based on individual product strings or PIDs is a bit of a
> challenge, but not impossible.
>
>> The second issue is the serial drain code in AVRDude tripping up my
>> limited bidirectional endpoint code.
> I'm not sure how useful all the draining stuff is at all if the backend is
> sitting on USB.  Basically, it's there since the days when programmer have
> been connected to real serial devices.
>
> The current implementation of usbdev_drain() is meant to be as little
> intrusive as possible though: read from the EP until it tells there are no
> more data around.


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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:[hidden email]]
Sent: September-21-14 1:40 PM
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch
As Colin O'Flynn wrote:

> 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.

You're probably right.  I thought of the same code being also used for
plain STK500v2 devices connected over USB (like, through an FT232)
where there could still be "old stuff" sitting around in the pipeline,
but then, these don't use the libusb backend but rather
ser_posix/ser_win32, so it's not the same AVRDUDE code then.

> 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.

OK, that would be good.  I don't have the USB dongles around here
anyway, they are still in the office.  So if I get such an image
sometimes this week, I should be able to run some tests.

> I guess we've had this issue for several years already, so
> presumably nobody is in too big a rush!

:-)

As for the other part (endpoint detection heuristics), is there anyone
who would want to step forward on this?
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin O'Flynn
Hello,

Alright - last message hijacking the thread I promise, let's keep any
further discussion in the separate bug issue I raised!

> OK, that would be good.  I don't have the USB dongles around here anyway,
they are still in the office.  So if I get such an
> image sometimes this week, I should be able to run some tests.

I've uploaded a hex file to bug # 43268 that does this. I'll add some notes
to that bug report about using it.

Regards,

  -Colin


-----Original Message-----
From: Joerg Wunsch [mailto:[hidden email]]
Sent: September-21-14 3:15 PM
To: [hidden email]
Cc: Colin O'Flynn; 'Dean Camera'
Subject: Re: [avrdude-dev] [bug #40831] LUFA AVRISP-MKII fails with avrdude
6.0.1

As Colin O'Flynn wrote:

> 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.

You're probably right.  I thought of the same code being also used for plain
STK500v2 devices connected over USB (like, through an FT232) where there
could still be "old stuff" sitting around in the pipeline, but then, these
don't use the libusb backend but rather ser_posix/ser_win32, so it's not the
same AVRDUDE code then.

> 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.

OK, that would be good.  I don't have the USB dongles around here anyway,
they are still in the office.  So if I get such an image sometimes this
week, I should be able to run some tests.

> I guess we've had this issue for several years already, so presumably
> nobody is in too big a rush!

:-)

As for the other part (endpoint detection heuristics), is there anyone who
would want to step forward on this?
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dean Camera-3
In reply to this post by Joerg Wunsch
Joerg Wunsch wrote:
> That's pretty normal though; only the control endpoint is usable in
> both directions, data EPs need one EP per direction.

Indeedy, each non-control endpoint accepts only IN or OUT data. However,
it's perfectly legal to have two logical endpoints share the same index
but with opposite directions, giving the 0x02 (OUT) and 0x82 (IN)
endpoint addresses used on the legacy Atmel tools. The issue here is
that on the AVR8 devices the endpoint address is dictated by its logical
index in the device, so endpoint index 2 in the USB AVR8 can only be
given the USB endpoint address of 0x82, or 0x02 - you can't assign
different logical endpoints to arbitrary endpoint addresses.

To get around that for the AVRISP-MKII Clone firmware (since the Jungo
drivers and Atmel tools assume the 0x02 and 0x82 endpoint addresses) I
just swap the direction of endpoint 2 in the USB AVR to the direction
needed at that point in time based on the higher level protocol. It's a
nasty, nasty hack, but as long as both sides stick to the published
protocol it works a treat. Where it falls down is when AVRDUDE tries to
read data from endpoint 0x82 in the serial drain function when I've
already flipped around the direction of the bank inside the AVR, causing
a USB transaction failure (invalid endpoint, since according to the USB
AVR controller, 0x82 doesn't exist any more at that point in time).


> Even though they are using a different chip on the USB
> interface, they have one EP per direction.

More advanced USB chipsets (XMEGA, newer UC3s, etc.) can freely allocate
any logical endpoint address to any physical bank in the device, so you
could allocate the first three endpoints to addresses 0x00, 0x02, and
0x82. If i ever port my code to the XMEGAs it will work just fine
without hacks, but carries the 3.3V restriction which makes it more
difficult to quickly use on parts if you're just throwing together a
programmer from your parts bin.


> 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?

Sure, that'll work fine. Presumably you have an AVR-GCC setup available (!) so just "git clone [hidden email]:abcminiuser/lufa.git" or grab a tarball from https://github.com/abcminiuser/lufa/archive/master.tar.gz and extract it out. In the "Projects/AVRISP-MKII" folder edit the makefile "BOARD" value to "NONE" (this disables the LED twiddling code) and "make all" to generate the HEX file. I'm not sure if the RZUSBSTICK uses an 8MHz or 16MHz crystal, so set "F_CPU
" in the makefile accordingly.

By default, the firmware builds in the LibUSB compatibility mode, which uses the different 0x02 and 0x83 endpoints which breaks completely on the latest AVRDude as the heuristics doesn't find the new endpoint layout. To change this, comment out the LIBUSB_DRIVER_COMPAT in the "Config/AppConfig.h" header and recompile.

If you can't do the above, let me know what configuration (F_CPU, USB endpoint compatibility mode) you need and I'll generate a binary for you. Note that this will cause naughty SPI/USART output from the AT90USB1287 when trying to contact a programming target, which might break other hardware on your board if you don't disable it.


Cheers!
- Dean



_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch
As Dean Camera wrote:

> To get around that for the AVRISP-MKII Clone firmware (since the
> Jungo drivers and Atmel tools assume the 0x02 and 0x82 endpoint
> addresses) I just swap the direction of endpoint 2 in the USB AVR to
> the direction needed at that point in time based on the higher level
> protocol.

OK, thanks for the explanation.  I finally understand the dilemma.

> >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?

> Sure, that'll work fine. Presumably you have an AVR-GCC setup
> available (!) so just "git clone
> [hidden email]:abcminiuser/lufa.git" or grab a tarball from
> https://github.com/abcminiuser/lufa/archive/master.tar.gz and
> extract it out.

As Colin already did all that for me, I could just proceed into
testing it.  As a result, I removed everything but the "return 0"
from usbdev_drain(), so all is fine now.

I still don't really understand why it only became apparent under
Windows, while it worked fine under Linux (presumably also other
Unices) even with the old drain code.  But the above might explain the
different behaviour I've seen between the LUFA clone and the Atmel ICE
(where the drain code didn't leave any traces on the USB analyzer at
all).

Now, if someone wants to go ahead, and implement a real endpoint
selection heuristic, we can hopefully solve the second issue.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin O'Flynn
> Now, if someone wants to go ahead, and implement a real endpoint selection
heuristic, we can
> hopefully solve the second issue.

There is some current code in there, which as Dean mentioned is just not
triggered. Would it seem cleaner to rearrange this such that if attempting
to read from the endpoint fails, we switch to heuristic mode (i.e. detect
the read endpoint)? I haven't actually tried this yet, was just going to
play around a bit now, but let me know your thoughts...


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch
As Colin O'Flynn wrote:

> There is some current code in there, which as Dean mentioned is just not
> triggered. Would it seem cleaner to rearrange this such that if attempting
> to read from the endpoint fails, we switch to heuristic mode

No, no trial & error, please.

If at all, then apply a proper heuristics straight from the beginning.
For the Atmel tools, the EP numbers are well defined, so checking the
algorithm against these definitions should be easy.  For the
remainder, the algorithm must be clever enough to always detect the
correct EP setup situation.

The goal must be to have no hardcoded EP numbers in the code anymore.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin O'Flynn
Hello Joerg,

>> The goal must be to have no hardcoded EP numbers in the code anymore.

Ah that makes sense, since it would be using the USB descriptors properly!
I'll take a look at it anyway to see how well this works. If I get anything
useful I'll need someone else to test it, as I don't have a real AVR-ISP
MK2. I do have a JTAG2 can test against.

Warm Regards,

  -Colin O'Flynn


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joerg Wunsch-6
In reply to this post by Joerg Wunsch-6
Follow-up Comment #5, bug #40831 (project avrdude):

I've added a possible patch against SVN head. This gets rid of hard-coded
endpoints & sizes for the stk500v2 and jtagice2 files. It's fairly simple, but
I've tested with an Atmel JTAG-ICEMKII, LUFA AVR-ISPMKII in AVRStudio Mode,
and LUFA AVR-ISPMKII in LibUSB mode.

I haven't modified the files for stk600 or jtagice3, which also have
hard-coded endpoints. Wanted to get feedback on this approach first before
going onward...

(file #32171)
    _______________________________________________________

Additional Item Attachment:

File name: endpointdetect_pass1.patch     Size:10 KB


    _______________________________________________________

Reply to this item at:

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

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


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
12
Loading...