Project

General

Profile

Actions

Bug #7937

closed

UV-25X4 “Radio did not enter clone mode”

Added by Lee Whatley almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
06/01/2020
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
BTech UV-25X4
Platform:
MacOS
Debug Log:
I read the instructions above:

Description

I have a Btech UV-25X4 and programming cable (PC04 FTDI Cable Single Pin) that I purchased new from Btech via amazon. My OS (OSX 10.13.6) sees the programming cable and assigns it /dev/cu.usbserial-D306VRR2. When I try to "Download From Radio" using CHIRP (daily-20200521) with the cable plugged into the radio's data port and the radio powered on the lights on the cable alternate between red and green, but I get the "Radio did not enter clone mode" error. I opened a case with Btech and they instructed me to open a case with CHIRP, as they feel that the radio and the cable are operating properly. I should note that I have been able to successfully program a UV-5R, as well as a Radioddity QB25 (which is essentially the same HW as a UV-25X4) on this system, though in both cases with a different cable.


Files

debug.log (26.4 KB) debug.log Lee Whatley, 06/01/2020 02:13 PM
Actions #1

Updated by Lee Whatley almost 4 years ago

I tried the same version of CHIRP (daily-20200521) on a Linux system this morning and was able to program the radio just fine using the same cable. So this appears to either be an issue with the cable driver under OSX or the OSX build of CHIRP.

Actions #2

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from New to Feedback
  • Model affected changed from UV-25X4 to BTech UV-25X4

Does this cable use a Prolific chip? That might be a problem under MacOS. Apparently, a FTDI based cable has better chances to function properly under this operating system. (I don't have a Mac, so this is third hand info.)

Actions #3

Updated by Lee Whatley almost 4 years ago

This BUG can be closed. The issue was with built-in FTDI driver in OSX not working properly. I had to manually disable the built-in driver and use the driver from the FTDI website. I'll provide steps here for folks that run into the same issue and find this BUG via google search:

1.) Download/Install latest FTDI VCP driver from https://www.ftdichip.com/Drivers/VCP.htm
1.a) This will create /Library/Extensions/FTDIUSBSerialDriver.kext

2.) Boot into recovery mode and disable csr
2.a) Reboot and hold down Command-R to go to recovery mode
2.b) From recovery mode open a terminal (in the utilities menu) and run "csrutil disable"
2.c) Restart back to "normal" mode

3.) Remove the Apple FTDI driver
3.a) Open a terminal and become root
3.b) csrutil status #verify csr is disabled
3.c) cd /System/Library/Extensions
3.d) mv AppleUSBFTDI.kext AppleUSBFTDI.kext.disabled

4.) Boot into recovery mode and re-enable csr
4.a) Reboot and hold down Command-R to go to recovery mode
4.b) From recovery mode open a terminal (in the utilities menu) and run "csrutil enable"
4.c) Restart back to "normal" mode

5.) Verify the correct driver is being used
5.a) Open a terminal
5.b) Plug in your FTDI USB cable
5.c) Run "kextstat | grep FTDI"
5.d) You should see "com.FTDI.driver.FTDIUSBSerialDriver" on the output line. If you see "com.apple.driver.AppleUSBFTDI" then it did not work

Actions #4

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from Feedback to Closed

Thank you for this feedback, it will eventually make it into the FAQ :-)

Actions

Also available in: Atom PDF