dfu-util bug using the wrong interface?

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to get dfu-util to work. I'd send them a bug report but I can't register on Sourceforge, I never get the confirmation email.

 

Anyway, the issue is that I set up my runtime DFU descriptor on interface 1, but dfu-util always sets wIndex to zero. Even if I use the -i parameter to force interface 1 it fails.

 

>dfu-util -v -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [9999:0037] ver=0100, devnum=4, cfg=1, intf=1, path="3-1.4", alt=0, n
ame="Runtime", serial="3555303335351909000B0"

 

Then

 

>dfu-util -v -e
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 9999:0037
Run-time device DFU version 0101
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: error get_status

 

It's the same if I add -i 1 to the command line. In the debugger I can see that my MCU receives 0 in wIndex, and a packet capture in Windows confirms this:

 

  Frame: Number = 1673, Captured Frame Length = 340, MediaType = NetEvent
+ NetEvent:
  USBPort: Dispatch URB_FUNCTION_CONTROL_TRANSFER
- UsbPort: Dispatch URB_FUNCTION_CONTROL_TRANSFER
  - USBPORT_ETW_EVENT_DISPATCH_URB_FUNCTION_CONTROL_TRANSFER: Dispatch URB_FUNCTION_CONTROL_TRANSFER
   + HostController: 1a-0 e
   + fid_USBPORT_Device:
   + fid_USBPORT_Endpoint:
   + fid_USBPORT_Endpoint_Descriptor:
   + fid_IRP_Ptr: 0xFFFFFA800E6D5010
   + fid_URB_Ptr: 0xFFFFFA801115B8A8
   - ControlTransfer:
    + Urb: Function = URB_FUNCTION_CONTROL_TRANSFER, Length = 6, Flags 0xb
    - SetupPacket:
     + bmRequestType: (Class request) 0xa1
       bRequest: 0x3
       wValue: 0 (0x0)
       wIndex: 0 (0x0)
       wLength: 6 (0x6)

 

It's the right control request (0xA1 is right, request 0x03 is GET_STATUS) and it works if I respond to interface 0... But it's runtime DFU, the primary interface 0 needs to be reserved for the application. Things like HID require interface 0.

 

I managed to get dfu-util compiling on Windows and debugged it. As far as I can tell it sets the right value in the packet... Maybe libusb is mangling it somehow.

 

Anyone got any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're doing better than me. I never managed to compile DFU-UTIL under Windows, and ended up having my Java app call an external batch file to run the precompiled .exe

 

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll post my fixes on Github later, since I can't seem to register for Sourceforge to contribute back directly.

 

Anyway, I found the problem. On Windows libusb using the WinUSB API. This API has a limitation where the wIndex value is forced to the interface number. The USB spec says that this should always be the case so maybe it's some kind of security feature.

 

I'm looking for a work-around.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only vague memory to throw in a few cents here is that Atmel's DFU stuff is not completely DFU compatible.

Some years ago there was some hack to make Atlmel's version of DFU work on linux.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan,

Did you manage to compile DFU-UTIL with open source tools, e.g. gcc or MinGW?

 

I ran into problems with LibUSB/WinUSB. I  don't think I could find the right files.

I'd appreciate any pointers, as I'd really like to make a few cosmetic changes.

 

John

 

Four legs good, two legs bad, three legs stable.