bugAVR Downloader/UploaDEr - Bugs: bug #43268, usb_drain() call causes LUFA...

 
 

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

bug #43268: usb_drain() call causes LUFA AVR-ISP MKII Code to Fail

Submitted by:  Colin O Flynn <c_oflynn>
Submitted on:  Sun 21 Sep 2014 11:31:24 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Colin O Flynn <c_oflynn>Originator Name: Colin O'Flynn
Open/Closed: OpenRelease: None
Programmer hardware: Device type: 

Mon 22 Sep 2014 10:25:04 AM UTC, comment #5:

While I still believe it is only masking a more severe issue
buried deep below, I turned usbdev_drain() into a dummy as
I think it serves no useful purpose (other than triggering
the issue buried deep below ;-).

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 22 Sep 2014 09:45:32 AM UTC, comment #4:

OK, fired the USB analyzer onto it.

The difference between Linux and Windows from the analyzer's
point of view is that Windows transactions are wrapped in a
countainer declaring them as "BULK IN" (or "BULK OUT"), Linux
transactions aren't.

Then, inside the Windows "BULK IN", the incomplete transaction
is flagged as "Malformed", commented as "The handshake is
missing". In contrast, the incomplete Linux transactions are
just that, incomplete only (which is expected since no data
are present).

Strange enough, if I connect an Atmel AVRISPmkII, there is no
sign at all from the usb_drain() visible on the bus. I don't
understand why they are handled differently though.

I'm attaching the analyzer trace reports for anyone who is
interested. In the lufa-avrisp2.xml file, the interesting
spot is at time 2.074379450 (Linux usb_drain()), and time
12.669058217 (Windows usb_drain()). In atmel-avrisp2.xml,
the respective OUT transaction (CMD_SIGN_ON) is at time
10.247395683.

(file #32160, file #32161)

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 22 Sep 2014 08:45:29 AM UTC, comment #3:

OK, using it under Linux, it "just works":

I think that's basically the expected behaviour for the fake
programmer. Under Windows (in a VM), I can see the timeouts
though.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Mon 22 Sep 2014 01:59:49 AM UTC, comment #2:

Have now added a hex-file for testing with RZRAVEN USB Stick. There is no IO pins connected, so you can't program a real AVR. I don't even know where the IO pins are routed. It also doesn't route the LEDs or anything so they don't turn on. You can basically just confirm with dmesg it appears as expected.

You can run a command with -F to fake a read, but it will always be garbage.

I've confirmed the hex file does work as expected. Although now on one of my systems it works as expected (almost, just errors out once). Although on another computer you get this, which is the bug being triggered:

[root@localhost colin]# avrdude -P usb -p m328p -c avrisp2

avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
^C

i.e. you get that 'error in USB receive' in a loop and nothing else. It's based on the latest release of LUFA (140302).

Colin O Flynn <c_oflynn>
Project MemberIn charge of this item.
Sun 21 Sep 2014 11:38:40 AM UTC, comment #1:

I now notice that in usb_libusb.c there is a separate struct for the AVR-ISPMK2, which might make it possible to disable the drain for that device without affecting anything else. Need to confirm that struct isn't used by other programmers.

Colin O Flynn <c_oflynn>
Project MemberIn charge of this item.
Sun 21 Sep 2014 11:31:24 AM UTC, original submission:

I had seen this reported on AVRFreaks (originally at http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=819522 but I don't know the new link).

The LUFA AVR-ISP MKII has different endpoint settings than a 'real' AVR-ISP MKII, due to some compatibility issues with libusb. This seems to be triggered by the call to drain() on the USB endpoint.

Easy fixes I see:

1) Turn it off on a per-programmer basis (i.e. for AVR-ISP MK2 only), probably via the config file.

2) Turn if off globally, but with a command-line switch to re-enable it in case it broke something

Opening this bug report to track the issue.

Colin O Flynn <c_oflynn>
Project MemberIn charge of this item.

 

Attached Files
file #32160:  lufa-avrisp2.xml.bz2 added by joerg_wunsch (1MiB - application/x-bzip2 - USB analyzer trace files)
file #32161:  atmel-avrisp2.xml.bz2 added by joerg_wunsch (237KiB - application/x-bzip2 - USB analyzer trace files)
file #32159:  RZRAVEN-AVRISP-MKII.hex added by c_oflynn (20KiB - application/octet-stream - Example hex file for RZRAVEN, does not actually connect ISP lines anywhere useful)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by c_oflynn (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 0 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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 22 Sep 2014 10:25:04 AM UTCjoerg_wunschStatusNone=>Fixed
    Mon 22 Sep 2014 09:45:32 AM UTCjoerg_wunschAttached File-=>Added lufa-avrisp2.xml.bz2, #32160
      Attached File-=>Added atmel-avrisp2.xml.bz2, #32161
    Mon 22 Sep 2014 01:46:35 AM UTCc_oflynnAttached File-=>Added RZRAVEN-AVRISP-MKII.hex, #32159

    Back to the top


    Powered by Savane 3.1-cleanup1