bugAVR Downloader/UploaDEr - Bugs: bug #40831, LUFA AVRISP-MKII fails with...


You are not allowed to post comments on this tracker with your current authentification level.

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

Submitted by:  Larry Viesse <larryvc>
Submitted on:  Sat 07 Dec 2013 03:10:06 AM UTC  
Votes:  155  
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: Larry Viesse
Open/Closed: Open

(Jump to the original submission Jump to the original submission)

Wed 27 Jan 2016 02:34:18 AM UTC, comment #7:

Confirmed, and the patch still works against 6.2. Will it be accepted upstream?

Dylan Taft <dylanetaft>
Sat 26 Dec 2015 08:01:24 PM UTC, comment #6:

Your [patch](https://savannah.nongnu.org/support/download.php?file_id=32171) also applies to RELEASE_6_2, and it makes avrdude-6.2 work with an Olimex AVR-ISP-MK2.

Michael Mauch <elmicha>
Mon 22 Sep 2014 10:41:03 PM UTC, comment #5:

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)

Colin O Flynn <c_oflynn>
Project Member
Sat 13 Sep 2014 07:53:41 AM UTC, comment #4:

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%02x\n",

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

Dean Camera <abcminiuser>
Sat 13 Sep 2014 07:50:29 AM UTC, comment #3:

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

Dean Camera <abcminiuser>
Wed 12 Mar 2014 10:26:43 PM UTC, comment #2:

OK, I see it in your file now:

The LUFA firmware requires the EP guesswork heuristics to

OK, this really asks for doing it right then.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Wed 12 Mar 2014 09:17:40 PM UTC, 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

Joerg Wunsch <joerg_wunsch>
Project Administrator
Sat 07 Dec 2013 03:10:06 AM UTC, original submission:

The problem was found in usbdev_open in file usb_libusb.c.

The if statement:
prevents Dean's LUFA masqueraded endpoint from being discovered.

See full details at: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=138424&start=0&postdays=0&postorder=asc&highlight=

specifically in this post: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1119592#1119592

Thanks for providing us with this awesome software.

Larry Viesse <larryvc>


Attached Files
file #32171:  endpointdetect_pass1.patch added by c_oflynn (11kB - application/octet-stream - Pass 1 of Endpoint Detection - not yet doing STK600/ICE3, no interrupt endpoint)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by dylanetaft (Posted a comment)
  • -unavailable- added by dylanetaft (Voted in favor of this item)
  • -unavailable- added by miki (Voted in favor of this item)
  • -unavailable- added by elmicha (Posted a comment)
  • -unavailable- added by c_oflynn (Updated the item)
  • -unavailable- added by abcminiuser (Posted a comment)
  • -unavailable- added by rons (Voted in favor of this item)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by larryvc (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 155 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 27 Jan 2016 02:32:38 AM UTCdylanetaftCarbon-Copy-=>Added dylanetaft
    Mon 28 Dec 2015 03:43:01 PM UTCmikiCarbon-Copy-=>Added miki
    Mon 22 Sep 2014 10:41:03 PM UTCc_oflynnAttached File-=>Added endpointdetect_pass1.patch, #32171
    Fri 23 May 2014 01:37:03 PM UTCronsCarbon-Copy-=>Added rons
    Wed 12 Mar 2014 10:26:58 PM UTCjoerg_wunschStatusNeed Info=>None
    Wed 12 Mar 2014 09:17:40 PM UTCjoerg_wunschStatusNone=>Need Info

    Back to the top

    Powered by Savane 3.1-cleanup