Opening DFU capable USB device... Cannot open device

[gruvin]

RESOLVED: In short, we don't need dfu-util any more, now that we have a bootloader. See here for details.

My Taranis arrived today. Trying to get it connected to Companion, under Windows 8.x

When trying to read the radio's firmware, I get, "Opening DFU capable USB device... Cannot open device"

Strange, because dfu-util is finding the device ...

Code: Select all

C:\Program Files (x86)\OpenTX>dfu-util.exe -l
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=1, name="UNDEFINED"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=2, name="UNDEFINED"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=3, name="UNDEFINED"

Companion is calling dfu-util as follows, which looks fine to me ...

Code: Select all

C:/Program Files (x86)/OpenTX/dfu-util.exe -a 0 --dfuse-address 0x08000000:524288 -d 0483:df11  -UC:/Users/Bryan/Documents/OpenTX/backup-factory-firmware.bin

What could be wrong?

Thanks.

PS: Yes folks ... I did try to search the forum for an answer before posting ... but I came up empty.

[gruvin]

I've since installed v2.0.5 firmware, using DfuSe Demo. No change. Companion still cannot find the radio.

[gruvin]

OK. So I eventually saw a single reference to the word "bootloader" and wondered if maybe that was something special. So, I googled that and finally found a file named bootloader.pdf. Yay. Information about this would be very nice to have on open-tx.org. EDIT: And I'd be happy to write that for us.

Anyway, I was able to the the bootloader to copy a firmware binary to the SD card and then use the bootloader menu to upgrade to v2.0.12.

But I still cannot get Companion to do the firmware reads/write directly. No idea why not.

Thanks for any extra info.

[bertrand35]

Did you do the Zadig driver step before launching dfu-util?

[gruvin]

Did you do the Zadig driver step before launching dfu-util?

I tried. It doesn't work. There's nothing in the drop-down list -- no STM32 BOOTLOADER option or anything else to install. Yes, I ran it as Administrator.

I also tried downloading and installing the dfu USB driver suggested by Fr-Sky. But that just says that Windows already has the latest driver installed, which it found previously for itself.

Then I tried it on another PC, running Windows 7. Exact same results.

In your email, you mentioned that it works painlessly in Linux. So I tried that, but had the exact same problem, still. Namely, that dfu-util is present, works fine (I use it for other STM32 devices routinely) but for some reason I'm still getting "Cannot open device" when trying to do anything with the Taranis -- even though the Taranis _is_ found on the dfu bus -- just like under Windows and as noted in previous posts.

DfuSe Demo (under Windows) DOES work. Just not dfu-util.

So, still no solution unfortunately. I cannot think of anything else to try at this time. I'm completely stumped.

Oh and yes -- of course I'll be happy to write documentation for this, when/if we find the problem.

[gruvin]

AH! ... I just tried dfu-util on my Mac, even though I have no Companion software for that. I get much better results ...

Code: Select all

$ dfu-util -l
...
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,07*128Kg"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e"
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"

And ...

Code: Select all

$ dfu-util -a 0 --dfuse-address 0x08000000:524288 -d 0483:df11  -Utest.bin
dfu-util 0.7
...
...
Starting upload: [#####...#######] finished!

That is, dfu-util is working perfectly on the Mac. Gosh. How weird :-/ Well, at least I can manually handle firmware on my main machine. A step in the right direction. Meanwhile, the bootloader works for models and settings in Companion.

So now I'm guessing that some special version of dfu-util is required and that I don't have the appropriate version installed in either Linux or Windows -- remembering that I could not get ZaDig to work. I'll work on that problem next.

@bertrand35 ... what version of dfu-util (dfu-util --version) are you running and under what OS (Linux?). Thanks. Oh -- mine is v 0.7 on the Mac and, oh darn -- the same on Linux. But my Linux is a VMWare virtual machine. So that's another variable. Geeze. It shouldn't be this hard.

[MikeB]

The bootloader, as I wrote it, allows reading/writing the EEPROM and reading/writing the flash memory. When you start in bootloader mode, then connect to USB to the PC, you should get two drives appear on the PC. One is the SD card and the other should have two files on it. One file is the EEPROM and the other is the flash memory.
Companion should simply be able to write a file to the flash memory file to do a firmware update.
The whole idea of the bootloader was to do away with dfu-util and zadig.

Mike.

[Kilrah]

i.e. Now you got the bootlaoder on using your Mac, you won't need dfu-util ever again.

Just for the sake of it:

So now I'm guessing that some special version of dfu-util is required and that I don't have the appropriate version installed in either Linux or Windows -- remembering that I could not get ZaDig to work. I'll work on that problem next.

Zadig installs the driver that allows dfu-util to communicate with the radio - so without it it certainly won't work. Did you "Show all devices" in Zadig as explained, with the radio off and cable connected?

[gruvin]

@Kilrah -- the USB drivers in Windows 7 and Windows 8.1 are already present. I never used Zadig before to make this happen. I did it manually. But I already use dfu-util for other STM32 projects, without issue -- on the Windows 7 and iMac native machines, at least. I have now realised that my Windows 8.1 and Linux machines, being VMWare virtual machines on my iMac, are for some reason not able to work properly with DFU devices -- including my other STM32 systems. I can list the devices, but they have "UNKNOWN" names and will not connect properly. This is not something to concern ourselves with here. Anyway, it should not matter now, because the bootloader is supposed to take its place. On that matter then ...

@MikeB -- that is good news. How though do I tell Companion NOT to use dfu-util but instead use the bootloader -- for firmware transfers? I see no option for this (Version 2.0.12). It always wants to use dfu-util when I try to transfer firmware in any direction. However, Companion is using the bootloader drives to do model and settings transfers, which is working as it should. (Both drives do connect as they should, with all the files present and accounted for -- both in Windows and Linux. Both OS's still want to use dfu-util though.)

EDIT: Somehow, it just started working under Linux. The only thing I changed was to set the SD File Structure Path in Companion, which I had done on Windows but forgot on Linux. That's weird, because the firmware is not even on that drive. *confused*

Super cool work on the bootloader, by the way!

[Kilrah]

Companion autodetects if the TARANIS drive is there, and if a FIRMWARE.BIN file is on it. If yes it writes to it, if not it falls back to calling dfu-util.

[gruvin]

Thanks for the assistance. It's another day and everything is still magically working in my Ubuntu Linux inside a virtual machine on my iMac. Who knows what was wrong initially with the bootloader drives? *shrug* I'm good a jinxing things. Yeah. That'll be it.

It's all very impressive, too. Kudos to all involved. Thanks a bunch. I'm having lots of fun with this radio and software.

[frater]

I got my Taranis on the same day as Gruvin, but haven't had much success on Windows 8.x either.

I'm running hyperV virtual machines on Windows 8.1
This means that the host machine (Windows 8.1) is not really a host machine, but actually a client.
Although you wouldn't notice it on the surface. If you enable HyperV on your Windows 8.x you have a different machine then a normal setup. Even if you don't have any virtual machines.

I don't know if the problems with dfu-util.exe have anything to do with it.
On Windows XP I had it running in no time....

There's another hurdle that Windows 8.x brought in. It's "driver signature enforcement".

If you install a program in Windows 8.x and it wants to install an unsigned driver, you will either get no dialogue for this or the installer crashes or hangs.

To properly install such a program and receive the "unsigned driver dialogue" you need to go to the metro interface and change the boot options of the PC. After it restarts you'll get a screen where you can pick the advanced option. I believe after pressing "7" the PC starts with " signature enforcement disabled" .
You will still get a warning when you install a driver that isn't signed, but you'll at least be able to accept that.

http://lmgtfy.com/?q=windows+8+driver+s ... nt+disable

I'm not giving a direct solution, I'm just pointing out the forces you have to reckon with.... They may or may not apply to you or on this problem....