Installing libusb-win32 and PyUSB for MD380 / Retevis RT3

There are several ways to install libusb on a windows PC. Zadig is one possibility, and the 'classic' method described below is another. If one doesn't work, try the other :o)

Download the zip archive from libusb-win32, and unzip it.
I used the 'latest version', 'libusb-win32-bin-1.2.6.0.zip' at the time of this writing.
The Wiki mentions 'Filter Drivers', 'Device Drivers', and a 'user friendly GUI installer'.
I decided to lauch 'bin/amd64/install-filter-win.exe' (on a 64-bit system with an Intel CPU).
Fortunately the 'user friendly installer' bails out if you pick the wrong one (at least when using the 32-bit "x86" installer on a 64-bit system).
The 'filter installer' seems to tie the driver to a certain USB device. So connect your radio to the PC and power it up before the installation (otherwise you won't see the 'STM Device in DFU Mode' in the list of selectable devices).

To test if libusb_win32 is properly installed, and the correct 'filter' was selected in the previous step:

Installing PyUSB (USB access wrapper for Python)

Download PyUSB and unzip the content to C:\tools\pyusb (so that "setup.py" is in that folder).
Note: I did NOT use the one from sourceforge.net/projects/pyusb/, last not least because their version isn't up to date,
and there were 'strange things' happening at SF some years ago.
The downloaded file from walac.github.io was walac-pyusb-1.0.0-15-g2b09e55.zip .
Start a 'command window', 'console', or your favourite Unix-like shell. Anything that allows invoking Python is ok.
I first used Babun (but later dropped it again due to trouble with USB / "no backend" - see next chapter). Babun contains the necessary commands required later to build and download the MD380 Tools.
First we check it the shell will launch "the correct Python" (because unfortunately, there are "incompatible Pythons out there").
Then we change to the directory into which we unzipped PyUSB, and ask Python to install it for us.
Strings on the right side are the current directory, as displayed by Babun (and Cygwin, on which it is based).
Characters right next to the prompt (" » ") have been entered by the operator (that's you).


{ md380tools }  » python -V                                          /cygdrive/c/tools/md380tools
Python 2.7.8
{ md380tools }  » cd c:/tools/pyusb                                  /cygdrive/c/tools/md380tools
{ pyusb }  » python setup.py install                                      /cygdrive/c/tools/pyusb
    ........... (dozens of lines omitted here) ........
byte-compiling /usr/lib/python2.7/site-packages/usb/__init__.py to __init__.pyc
running install_egg_info
Writing /usr/lib/python2.7/site-packages/pyusb-1.0.0-py2.7.egg-info
{ pyusb }  »                                                              /cygdrive/c/tools/pyusb

PyUSB / md380_tool.py : "No backend available"

As many winusb / PyUSB users before, I also got the infamous 'no backend available'-error. Even after all had been working perfectly for days, this annoying problem occasionally reappeared for obscure reasons.


{ md380tools }  » make flashdb                                       /cygdrive/c/tools/md380tools
"make" -C db stripped.csv
make[1]: Entering directory '/cygdrive/c/tools/md380tools/db'
make[1]: 'stripped.csv' is up to date.
make[1]: Leaving directory '/cygdrive/c/tools/md380tools/db'
wc -c < db/stripped.csv > user.bin
cat db/stripped.csv >> user.bin
./md380-tool spiflashwrite user.bin 0x100000
No backend available
Makefile:93: recipe for target 'flashdb' failed
make: *** [flashdb] Error 1
{ md380tools }  »                                                  /cygdrive/c/tools/md380tools 2

After following several threads about 'PyUSB / no backend available' at stackoverflow.com:


 The problem is that i didn't include libusb0.dll and libusb-1.0.dll files 
 in PATH environment variable location
 (...) 
 PyUSB module will check for libusb0.dll and libusb-1.0.dll files (which act as backends) 
 in the PATH environment variable and in C:\windows\System32 locations 
 and then establishes communication with USB devices. 
 Since i'm using libusb-win32-wizard for creating device drivers it uses libusb0.dll. 
 The process of execution can be found using following DEBUG program:

import os
os.environ['PYUSB_DEBUG'] = 'debug'
import usb.core
print list(usb.core.find(find_all=True))

The favourite file manager (not 'Explorer'!) found dozens of those DLLs splattered all over the place - "Windows DLL Hell" at it's finest !
The ones that Python (and Windows) should be able to find were


 C:\Windows\System32\libusb0.dll (76384 bytes, last modified 2013-09-29)
 C:\Windows\SysWOW64\libusb0.dll (67680 bytes, last modified 2013-09-29)

Contained in the archive with "libusb_win32" (libusb-win32-bin-1.2.6.0.zip) were:


 C:\tools\libusb-win32\bin\amd64\libusb0.dll   (76384 bytes, last modified 2012-01-17 !)
 C:\tools\libusb-win32\bin\x86\libusb0_x86.dll (67680 bytes, last modified 2012-01-17 !)
 C:\tools\libusb-win32\bin\ia64\libusb0.dll (forget about this one, it's only for 'Itanium' CPUs)

After brainlessly copying those DLLs around, I still couldn't fix the No backend available problem when trying to run the Python scripts that access USB in Babun, e.g.


  spiflashwrite user.bin 0x100000

and any similar command resulted in No backend available. But since "spiflashwrite" is entirely implemented in md380_tool.py, it should run in any implementation of Python 2.7. So, after "the Python in Babun" failed to load the libusbwinsomething-DLL, why not try "another Python" ? I tried the shell that came along with MinGW32 (installed into C:/MinGW, not a crappy "Program Files (x86)" or similar folder ), then installed PyUSB also for "that other Python", and ... bingo, see next chapter. Farewell Babun, hope to see you later, maybe.

Wrong SPI Flash ID - or "how to make the DMR User Database transfer work on a windows PC"

Below are the results from the MinGW32 shell, with the commands to install PyUSB, and to download the entire (worldwide) DMR user database into the RT3 / MD380 :


Wolf@YHF6 /c/tools/md380tools
$ cd c:/tools/pyusb
Wolf@YHF6 /c/tools/pyusb
$ python setup.py install
Wolf@YHF6 /c/tools/pyusb
$ cd c:/tools/md380tools
Wolf@YHF6 /c/tools/md380tools
$ python md380_tool.py spiflashwrite user.bin 0x100000
SPI Flash ID: 10 dc 1        <- this indicates a problem !
W25Q128FV 16MByte maybe
erase 2586259 bytes @ 0x100000
flashing 2586259 bytes @ 0x100000
reboot radio now

Wolf@YHF6 /c/tools/md380tools

"Looks like success", but no... DMR-IDs were not decoded yet, and "no entry in your users.csv" was displayed whenever there was activity on the local DMR repeater. This seems to be a common problem under windows. Also, the SPI Flash ID of this radio should be EF 40 18 (hex).
As suggested by Ed N6YN, I tried to "tickle" the USB before another attempt of 'spiflashwrite'-ing the DMR User database:


 Execute the "testlibusb-win.exe" file, then click on the Refresh button 
 at the bottom of the popup window. 
 (Note this file is located in the libusb-win32-bin-1.2.6.0\bin\x86 folder). 
 Once you click on the Refresh button you will find that if you again issue a 
  ./md380-tool spiflashid command (..), you will receive the proper response 
  from the radio:
 SPI Flash ID: EF 40 18
 W25Q128FV 16MByte

Here, on a 64-bit machine with Win8.1, I got the same stunning result:
First, execute "testlibusb-win.exe" (unzipped from libusb-win32-bin-1.2.6.0.zip).
When successfull, it will show 'Patched MD380' (follow the above link for a screenshot).
Then, without quitting 'testlibusb-win.exe', let the MD380 Tools read the SPI-Flash-ID, and when getting "ef 40 18", proceed with writing user.bin (the complete DMR database).
Enter enter the cyan coloured commands in your favourite command shell (or copy them there):


Wolf@YHF6 /c/tools/md380tools
$ python md380_tool.py spiflashid
No backend available   # Aaaargh.. the old annoyance is back ! Continue here .

Wolf@YHF6 /c/tools/md380tools
$ python md380_tool.py spiflashid
SPI Flash ID: ef 40 18             <- hip-hip-hooray .. finally a correct Flash-chip-ID .. Thanks Ed !
W25Q128FV 16MByte

Wolf@YHF6 /c/tools/md380tools
$ python md380_tool.py spiflashwrite user.bin 0x100000
SPI Flash ID: ef 40 18
W25Q128FV 16MByte
erase 2586259 bytes @ 0x100000
flashing 2586259 bytes @ 0x100000
reboot radio now

Wolf@YHF6 /c/tools/md380tools
$

After this successful transfer of the DMR database, the RT3 / MD380 could now decode any of the 49000 DMR-IDs in the database into callsign and operator name.

The journey of exploring the 'Experimental' firmware continues on DL4YHF's Retevis RT3 / Tytera MD380 page .

Switching from the default USB driver ("STTub30" for the Retevis/Tytera CPS) to libusb

If you frequently switch between the normal CPS ("Customer Programming Software") and the MD380-Tools, consider to use Zadig to switch from the 'STTub30' driver (which appears as 'STM Device in DFU Mode' in the device manager) to the libusb driver (or similar driver compatible with the MD380-Tools). Zadig can install or replace the currently selected driver with just a few mouse clicks.

Connect the radio to the USB port and turn it on (normally, not in firmware-update mode)
In Zadig's 'Options' menu, select 'List All Devices'
In the drop-down list, select 'Patched MD380' (see screenshot in the next chapter)
In the field right next to the green arrow, select 'libusb-win32 (latest version)'
Click 'Replace Driver' and wait until done.

After these steps, Python and PyUSB can be used to run the MD380-Tools.

"Switching back" to the default USB driver (for the Retevis / Tytera CPS)

Occasionally, I wanted to edit the codeplug with the original Retevis (or Tytera) CPS under windows. After installing libusb_win32 (or similar), this didn't work anymore, since the USB device (the 'Patched MD380') was now occupied by the libusb_win32 'driver' !
Unfortunately there is no way to switch back (via Zadig) to the "original" driver.
Remember which driver was in use before installing libusb_xyz ? Here the screenshot (in Zadig) before switching to one of the possible drivers for the MD380-Tools:

("STTub30" was the driver installed by the Retevis CPS, in December 2016)

Since it's not possible to 'switch back' to the original driver with Zadig, I had to use the following steps under Windows 8.1 to get the original USB drivers back:

Open the Device Manager ("Start".."Control Panel", etc etc etc or simply run "mmc devmgmt.msc")
In this case, the "Patched MD380" was listed under "libusb-win32 Usb Devices"
RIGHT CLICK on it, select "Uninstall" / "Deinstallieren" ... but hold on, DON'T PROCEED TOO QUICK !
Make sure "Delete the driver software for this device" is checked
(on a german PC: Haken vor "Die Treibersoftware für dieses Gerät löschen")
Turn the radio off and on again (or disconnect from / reconnect to USB).
Only because we've deleted the driver software,
windows will NOT immediately re-install the libusb_win32 driver (or whatever we installed via Zadig & Co) !
If the "Patched MD380" still appears as another "libusb" device or similar outside the "USB-Controller" list, repeat the above step (uninstall + delete driver).
Sooner or later, windows surrenders, and the "STM Device in DFU Mode" appears in under "USB-Controller" again.
Dr Zadig would then identify the current driver for our "Patched MD380" as "STTub30", as it was after a clean install of the CPS (see screenshot further above). Anything else causes the Retevis/Tytera CPS not to recognize the radio, because it can only talk to the "STTub30" driver.

After these steps, you can start the 'normal' Customer Programming Software (by Retevis or Tytera) to load a new codeplug into your radio, or use their 'Upgrade.exe' to load a new firmware under windows (without the MD380-Tools).

back to DL4YHF's Retevis RT3 / Tytera MD380 page