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 07 Dec 2013 03:10:06 AM UTC  
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 10 Apr 2017 07:21:24 AM UTC, 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 07 Apr 2017 02:49:40 PM UTC, 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
release.

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 07 Apr 2017 02:43:23 PM UTC, 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 27 Mar 2017 01:03:14 PM UTC, 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 23 Mar 2017 10:01:53 AM UTC, 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
http://www.fourwalledcubicle.com/AVRISP.php

andreas <ante>
Sun 12 Mar 2017 12:11:19 AM UTC, 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 31 Jan 2017 02:04:40 PM UTC, comment #9:

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

julian <comboy>
Fri 24 Jun 2016 12:34:19 PM UTC, 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 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",
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?

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

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

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 (11KiB - 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 07 Apr 2017 02:49:40 PM UTCjoerg_wunschReleaseNone=>6.3
    Tue 31 Jan 2017 02:02:44 PM UTCcomboyCarbon-Copy-=>Added comboy
    Fri 24 Jun 2016 12:22:36 PM UTCxiiCarbon-Copy-=>Added xii
    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-cleanup1