Cannot read/write codeplug to MD380 when experimental firmware is loaded (Windows)

I have compiled and installed Travis' experimental firmware (latest version from Git) and loaded it into my MD380 with no problem. The user database load (make flashdb) works fine too.

My problem is that I cannot read or write a codeplug to the radio using the Tytera CPS software version 1.32 once the new firmware is loaded. When I try to read or write the codeplug I get the message "please check whether the USB is occupied or not connected". I know that the USB connection is working because I can use it to load the firmware and the database into the radio.

The only way that I can read the codeplug or write a new one to the radio is to go to a system that does not have the libusb driver installed. I need to reflash the firmware with the Tytera firmware (currently using version 2.34) and then CPS will happily read/write the codeplug. This is ugly.

What is everyone else doing to update their codeplugs after installing the new firmware?

 My environment is Windows 7.

PD0ZRY MD380 pre-build firmware

PD0ZRY MD380 pre-build firmware


After getting a lot of requests for local hams with limited knowledge of linux for the md380 firmware I desided to make it automatic
You can find the firmware here: md380-fw
So i wrote a relative simple bash script to check for a new version and if there is one make a new build
Firmware updates are build every hour if there is new code pushed.

Contact Manager 1.32 Released - Update

I received mails from several hams who had trouble with converting codeplugs from one type of radio to another, and found that two distinct issues could pop up - - one, if the first digit of the manufacturer ID code in the codeplug was corrupted, that incorrect data would be propagated to the new codeplug; and second, the frequency range data within the codeplug (which is stored in two different locations and methods, and varies by model) was not consistently being updated.

Version 1.32, which can be downloaded from http://n0gsg.no-ip.org/contact-manager/, corrects both of these problems and adds support for the Retevis RT3, which is yet another MD380 work-alike.

If you open your codeplug in Contact Manager and it says "Unknown" in the Radio Type dropdown box, then you know that the manufacturer ID information is corrupted in your file. Simply choose the correct manufacturer ID, then save the codeplug and you'll be back in business.

MD380 MD390 Retevis RT3 Experimental Firmware Supported Haradware

I've read many posts about this experimental firmware. I've seen many posts related to the MD-380, but I have a MD-390 with GPS and 13.020 firmware (as received new).

My question: can the experimental firmware be used with the newest MD-390 with GPS and new vocoder? I don't want to risk attempting to load it if it's known to now work.
73 - Chris Smith VE6xxxx

From :
https://github.com/travisgoodspeed/md380tools/blob/master/README.md

Supported Hardware
The patched firmware is known to work on the following devices:

Tytera/TYT MD380 (old vocoder)
Tytera/TYT MD380 (new vocoder)
Tytera/TYT MD390 (new vocoder, no gps)
Retevis RT3

Tytera (TYT) MD380 Windows Firmware Installation

Tytera MD-380 Windows Firmware Installation

You can install any of these patched firmware files into your MD380 by using the respective .bin file with the Tytera Windows firmware upgrade tool, "upgrade.exe", available inside their firmware upgrade downloads.

Here are the steps:

    Turn off your MD380 using the volume knob.
    Attach the Tytera USB cable to the SP and MIC ports of your MD380.
    Attach the Tytera USB cable to your host computer.
    Hold down the PTT and the button above the PTT button (not the button with the "M" on it).
    Turn on your MD380 using the volume knob.
    Release the buttons on the radio.

This is how I update the CSV file, with FlashDB, under Windows OS!

Hello UHF MD-380 owners... and MANY thanks to Travis and others on the team, for their programming efforts and for their countless hours they have put into this project!

I have been trying to understand why I was only able to perform a "make flashdb" one time under Windows and transfer the CSV file into the MD-380. Over the past month, I have tried many approaches to the way I installed then de-installed the USB driver, but with no success... until last weekend. I have been testing this on different Tytera radios, and I believe I have found a way to issue a "make flashdb" and reliably flash the 16MB SPI Flash in the UHF MD-380... via Windows.

I have performed this on 3 different MD-380s and repeated several updated CSV installs on each, running both the older (patched v2.032) and newer (patched D13.020) firmware versions. (Please note, I have skipped many steps and hopefully most users will follow what I am trying to state below.)

Normally, I would obtain either one of the following two responses when issuing a "./md380-tool spiflashid" command in a MINGW32 window:

Tytera MD-380 Teardown MD380 Reverse Engineering

md380-re/teardown/button ant closeup.jpg

md380-re/teardown/front case annotated.jpg

How to update TYT MD-380 hacked firmware!

How to update TYT MD-380 normal or hacked firmware!

How to update your TYT MD-380 to the latest firmware. It is recommended to update your radio regularly to get the latest bug fixes for this radio.

users.csv update MD380 experimental firmware

users.csv does not show info on updated MD380 experimental firmware

I'm another one who went through the process of updating my UHF MD-380 to the experimental firmware from Travis Goodspeed. I originally tried using a Windows 10 machine, and after going through the process, apparently successfully did the firmware and user.csv updates.

When trying the radio, the new firmware seems to be working, but no matter what, I could not get any info other than DMR ID in the green pop-up window that is supposed to show the user information. I have enabled UserCSV in the utility/md380tools menu, but no luck.

So, I thought perhaps W10 was the issue, so I went through the process again on a W7 machine - same result. I see that others have had the same problem, and always get asked two questions: "Did you flash the DB in normal mode?" - the answer is yes, I did. "Did you enable UserCSV from the md380 tools menu?" - Yes, I did.

MD380 message from CPS version 1.32

I just downloaded and built the latest version of md380tools. When I try to write a codeplug to my radio I get this message from CPS version 1.32

I have no issue writing the codeplug with md380-dfu

Tytera (TYT) MD380 DFU-mode

To place radio into DFU-mode, press and hold both PTT and button above it, at the same time turning the radio on. LED should be flashing red and green.

To get out of DFU-mode turn radio off then back on.

MD-380 firmware reverse engineered

So how do I actually do a firmware upgrade on the radio? When you say "compile", I don't understand. How do we just download a firmware file and run a program to put it on the radio?
And if we put an "experimental" firmware in the radio, can we use the same stock TYT programming software, or is there a different programming software we need to program the new features?
So, what is this "github"? How come it doesn't just have the usual download links that say 32- bit Windows, 64-bit Windows, etc. How do I actually download from this website to upgrade an MD-380?

Since this is "experimental" only the Linux source files are provided at "github". You have to compile them into the needed binary file for the update.

This experimental firmware is a project by some obviously pretty smart guys who are kind enough to share it with everyone. But the nature of the project is somewhat advanced and so is the process to make it work, they aren't going to take the time to package everything into a pretty little installer for you. It's understood that if you want to tinker with this kind of stuff you come up to speed with thats going on and become involved.



Github is a repository that programmers use to share source code and ideas. The code can then be pulled from there to be compiled into binary or executable files (depending on what the project is). Also you will often see that with projects like this the authors won't include compiled binaries (and sometimes not all the required dependencies) to avoid copyright issues etc).

In this case they don't include the stock Tytera firmware that needs to be modified, it gets pulled from another site. DSD used to be the same way, and SDRTrunk still is. Some assembly required!