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

Submitter:  Larry Viesse <larryvc>
Submitted:  Sat 07 Dec 2013 03:10:06 AM UTC
Votes: 355
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  Larry Viesse
Open/Closed:  Open Release:  6.3
Programmer hardware:  Device type: 

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>
Group 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>
Group 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>
Group 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>
Group 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:

                  if (fd->usb.rep) == 0)
                  {

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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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
  • -email is unavailable- added by yegorich (Posted a comment)
  • -email is unavailable- added by ante (Posted a comment)
  • -email is unavailable- added by heyduds1 (Posted a comment)
  • -email is unavailable- added by comboy (Posted a comment)
  • -email is unavailable- added by comboy (Voted in favor of this item)
  • -email is unavailable- added by xii (Posted a comment)
  • -email is unavailable- added by xii (Voted in favor of this item)
  • -email is unavailable- added by dylanetaft (Posted a comment)
  • -email is unavailable- added by dylanetaft (Voted in favor of this item)
  • -email is unavailable- added by miki (Voted in favor of this item)
  • -email is unavailable- added by elmicha (Posted a comment)
  • -email is unavailable- added by c_oflynn (Updated the item)
  • -email is unavailable- added by abcminiuser (Posted a comment)
  • -email is unavailable- added by rons (Voted in favor of this item)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by larryvc (Submitted the item)

    •  

    There are 355 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-07 joerg_wunsch ReleaseNone 6.3
    2017-01-31 comboy Carbon-Copy- Added comboy
    2016-06-24 xii Carbon-Copy- Added xii
    2016-01-27 dylanetaft Carbon-Copy- Added dylanetaft
    2015-12-28 miki Carbon-Copy- Added miki
    2014-09-22 c_oflynn Attached File- Added endpointdetect_pass1.patch, #32171
    2014-05-23 rons Carbon-Copy- Added rons
    2014-03-12 joerg_wunsch StatusNeed Info None
    2014-03-12 joerg_wunsch StatusNone Need Info

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-3b9d.
    Corresponding source code