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


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

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

Submitted by:  Larry Viesse <larryvc>
Submitted on:  Sat Dec 7 03:10:06 2013  
Votes:  355  
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: Larry Viesse
Open/Closed: OpenRelease: 6.3
Programmer hardware: Device type: 

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

Mon Apr 10 07:21:24 2017, comment #15:

Spare time is a costly thing ...

Having the patch in the tree means, more people using latest tree would test it (consciously or not).

As I have already pointed in my previous post I have both Atmel and Olimex devices. Primary avrdude usage is on Linux for ARM. The only Atmel controller I'm using is Atmega 168pa (-p m168p) So let me know, if I can help with testing.

Though it is not likely to happen any time soon, but converting the project to git would be awesome. Alone patch creation via "git format-patch", "binary" debugging via git bisect and of course git blame feature make git far more appropriate for collaborative projects. No speaking about "tig" utility.

Yegor Yefremov <yegorich>
Fri Apr 7 14:49:40 2017, comment #14:

The question is not as much as what the state of this bug, but
rather when there will be any resources to prepare the next

As long there is nobody actively preparing the release, it
doesn't matter much whether the patch is already in the tree
or not.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Fri Apr 7 14:43:23 2017, comment #13:

What is the state of this issue? I can still apply this patch to current SVN trunk and I get both Atmel and Olimex devices working in Linux. I would really like to see this issue fixed in 6.4.

Yegor Yefremov <yegorich>
Mon Mar 27 13:03:14 2017, comment #12:

without the patch i get
"avrdude: stk500v2_recv_mk2: error in USB receive"
with avrdude: Version 6.2

the patch solves it.

julian <comboy>
Thu Mar 23 10:01:53 2017, comment #11:

Please apply this patch to the official build, none of the avrdude 6.x-versions work with the LUFA-based AVRISP-MKII Clone and most likely the many derrivatives too

andreas <ante>
Sun Mar 12 00:11:19 2017, comment #10:

Not sure why you are having a problem with LUFA + AVRISP MKII if this patch is not applied. I have not applied this patch, but I installed the latest LUFA firmware and my AVRISP MKII works with avrdude 6.2 as well as 6.3 . The only problem is it gives me avrdude: fileio: invalid operation=1
avrdude: write to file 'filename' failed
when I am setting an output file format as "immediate" (m)

Hey Duds <heyduds1>
Tue Jan 31 14:04:40 2017, comment #9:

patch works with 6.3
had to apply it for the LUFa programmer.
Strong Vote to include it!

julian <comboy>
Fri Jun 24 12:34:19 2016, comment #8:

Hi, I don't understand why the patch is still not applied?

I have tested avrdude 6.3 and it still has the problem with Olimex AVR-ISP-MK2 programmer on Linux (Mageia 5).

Please apply this patch, none of the avrdude 6.x work with the Olimex programmer otherwise!
(note: tested with an official Atmel AvrISP MK2 and it also works)

xi <xii>
Wed Jan 27 02:34:18 2016, comment #7:

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

Dylan Taft <dylanetaft>
Sat Dec 26 20:01:24 2015, 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 Sep 22 22:41:03 2014, 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 Sep 13 07:53:41 2014, 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 Sep 13 07:50:29 2014, 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 Mar 12 22:26:43 2014, 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 Mar 12 21:17:40 2014, 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 Dec 7 03:10:06 2013, 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 yegorich (Posted a comment)
  • -unavailable- added by ante (Posted a comment)
  • -unavailable- added by heyduds1 (Posted a comment)
  • -unavailable- added by comboy (Posted a comment)
  • -unavailable- added by comboy (Voted in favor of this item)
  • -unavailable- added by xii (Posted a comment)
  • -unavailable- added by xii (Voted in favor of this item)
  • -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 355 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 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Apr 7 14:49:40 2017joerg_wunschReleaseNone=>6.3
    Tue Jan 31 14:02:44 2017comboyCarbon-Copy-=>Added comboy
    Fri Jun 24 12:22:36 2016xiiCarbon-Copy-=>Added xii
    Wed Jan 27 02:32:38 2016dylanetaftCarbon-Copy-=>Added dylanetaft
    Mon Dec 28 15:43:01 2015mikiCarbon-Copy-=>Added miki
    Mon Sep 22 22:41:03 2014c_oflynnAttached File-=>Added endpointdetect_pass1.patch, #32171
    Fri May 23 13:37:03 2014ronsCarbon-Copy-=>Added rons
    Wed Mar 12 22:26:58 2014joerg_wunschStatusNeed Info=>None
    Wed Mar 12 21:17:40 2014joerg_wunschStatusNone=>Need Info

    Back to the top

    Powered by Savane 3.1-cleanup1