CHIRP

1. are you using latest chirp daily?
2. are you using latest ftdi driver for mac? (this almost sounds like driver/port issue)
3. can you provide a debug.log of the session

Item 1: No I am using the 0.3.1 Mac App. I have not figured out how to use the daily build as I have no clue as to where the Chirp files are located on a Mac. Please note that downloading from the radio to the computer works flawlessly.

Item 2: Yes I am. Also if the driver was not correct would the download work correctly. Plus I have an Icom 91AD and It works flawlessly with the Mac for both up and download.

Item 3: Did you read all of mine original entry? The upload to radio always freezes/locks the computer and I can only get out by powering down the MacBook using the power switch. Would a log be saved in that situation? If yes, tell me where to look for it.

first, please review this faq:
http://chirp.danplanet.com/projects/chirp/wiki/How_To_Report_Issues

second:
from the download page, if you go to daily builds and follow the link you will find a folder of files
http://trac.chirp.danplanet.com/chirp_daily/LATEST/

the one you want for mac is the one with app in it: chirp-daily-20140206.app.zip

Download that one. Look in your download folder - it will probably unzip it for you, in which case you will see an app:
chirp-daily-20140206

which you can double-click on and launch - this is the daily build.

third:
does the icom 91AD use the exact same cable as your yaesus - if not, it does not necessarily rule out a cable/driver as being the issue.

The debug.log may or may not be collected if it crashes - but there is a good chance. Please review the first item above for how to get the debug.log

Again, chirp itself should not "freeze" or lockup your computer. It might crash or lockup chirp the program, but if your entire computer is locked up, chances are, this is a bug or bad design with the hardware driver. (Usually only hardware or hardware drivers can make the whole OS unstable).

I'm having a similar issue with my Icom IC-W32A. I'm running OSX 10.9.1 using a SiLabs CP2102 USB to UART interface. I don't have any trouble downloading data from the radio, but uploads to the radio fail (and as a result, the memories of the radio are all cleared). Should I open a new issue for my radio or update this post with the details?

New issue please. We can mark them related if we determine that to be true.

The problem persists. I got the daily upload app, reinstalled the FTDI MAC drivers, and ran CHIRP. The down load from the radio worked fine. I pasted new data into the download data, started upload, and the program crashed, locking up the MAC Book Pro, requiring a power off reset. The data from the radio memories is deleted as Glenn found with his Icom. Once again, when I run CHIRP in a Parallels window-Windows 8.1, on same MAC Book it works perfectly.

This definitely sounds like a driver issue to me. In general, USB-to-serial drivers on MacOS are utterly terrible. Reading from the radio could definitely work while still having problems writing to the radio. When you use Parallels, you end up pushing the USB device directly into the Windows VM, which uses its own driver.

The code for CHIRP is 100% the same on MacOS, Windows, and any other OS. Especially when you show that it works on the same machine with the same cable and the same build of CHIRP, but under different OSes, the only difference remaining is the driver.

Looks like apple introduced a built-in FTDI driver (com.apple.driver.AppleUSBFTDI) which has been breaking lots of software/vendors devices. see: https://developer.apple.com/library/mac/technotes/tn2315/_index.html

There are multiple advices from multiple vendors on how to fix. Unsure if this is related, but it sounds suspicious. (Note that chirp does not use the D2XX apis that many vendors use, but just the serial device that is created, e.g., /dev/cu.usbserialxyz)

A search for "ftdi mavericks" comes up with an assortment of issues such as:
http://forum.arduino.cc/index.php?topic=198539.0
http://support.synthe-fx.com/customer/portal/articles/1346688-important-lcompanion-10-9-mavericks-info
http://www.enttec.com/support-center/kb/article/108-OS_X_Mavericks_(10.9)_-_IMPORTANT

Can you tell us exactly which FTDI driver you installed? (i.e., link or filename please)

I installed the 2.2.18-2 version. Downloaded from FTDI website.

OK boys and girls. I downloaded the driver switch on and off applet described in the enttec.com url above. Installed it and ran it. Then tried a download from radio and was told there was no port available. So I ran the applet again and activated the driver. Now the download worked. So I put together a new local repeater file and then did an upload. Worked perfectly---so go figure.

I'm reporting the same problem as others above with a bit more researched input regarding the problem cause.

I can download memory settings from my Yausu VX-6 transceiver to CHIRP. I cannot upload memory settings from CHRIP to my Yausu VX-6. CHRIP totally locks up (only recovery is Force Quit Application) repeatably at one-third of the way through the upload. Additionally all of my manually entered Yausu VX-6 memory settings are wiped out after the CHIRP upload attempt, except for one entry.

I am running CHRIP on Mac OS X 10.9 Mavericks, which is a fairly new O/S release for Apple. I’ve tried running both CHIRP 0.3.1 and the latest daily build. Both versions fail with the Yausu VX-6 upload data transfer.

My USB serial cable is a Valley Enterprises "Yeasu USB VX-7 FTDI", part # RPC-Y7R-U. The deployed Virtual COM port (VCP) driver I am using is the FTDI Mac OS X VCP version 2.2.18, release date: 2012-01-06 downloadable from FTDI at: http://www.ftdichip.com/Drivers/VCP.htm

I am able to perform both uploads and download data transfers to my Boefeng UV-5R data transceiver. It is only the Yausu VX-6 transceiver upload data transfer which is failing--note that each transceiver device uses a different VCP serial driver. Thus additional verification what I suspected. That is, as others have suggested, this is definitely a driver issue and not a CHIRP application issue.

There are some indirect implication here: http://forum.arduino.cc/index.php?topic=198539.0 with suggested solution indicating that the newly introduced OS X 10.9 Mavericks AppleUSBFTDI kernel driver ( https://developer.apple.com/library/mac/technotes/tn2315/_index.html ) could be part of our memory setting upload problems. I followed the suggested solution to disable the new AppleUSBFTDI kernel driver. Disabling this driver had no affect on fixing my CHIRP to Yausu VX-6 transceiver memory transfer setting.

My conclusion is that those of us using a USB serial cable containing a FTDI chip, on Mac OS x 10.9 Mavericks and the Mac OS X FTDIUSBSerial driver, are without a possible handheld memory data transfer solution until FTDI ( http://www.ftdichip.com ) updates their Mac OS FTDIUSBSerial driver.

If someone can prove my conclusion as incorrect, I am listening. All I want to do is manage transceiver memory settings transfer to/from on my Mac OS X workstation.

I did not mention in my last update, that I went to the FTDI website and got the instructions for removing the driver from OS X. While written some years ago, it appeared to work. So I am wondering if removing it and I guess leaving just the MAC FTDI driver removed the problem. I have done several uploads to the VX-7R and they are all going smoothly and completely.

The following is a VCP driver bug fix when using CHIRP on Mac OS X 10.9 Mavericks to perform memory settings uploads to Yaesu VX-6R and VX-7R radios and the upload locks up your Mac OS X workstation. The connection is when using a USB to/from handheld transceiver (HT) radio cables containing the FTDI serial chip.

There is an apparent buffer pointer overflow bug, which causes a computer lockup, when uploading memory settings using the Mac OS X FTDI VCP Driver, version 2.2.18 from http://www.ftdichip.com/Drivers/VCP.htm. The upload lockup appears to only occur with Yaesu HTs.

To work around this FTDI driver bug, you will need this: AN 134 FTDI Drivers Installation Guide for MAC OSX - Nov 2013, PDF document, available here: http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FTDI_Drivers_Installation_Guide_for_MAC_OSX.pdf

Accordingly, the fix is to not use the FTDI VCB driver and instead use the Mac OS X 10.9 Mavericks provided built in Apple VCB driver. For Apple driver details, see Apple Technical Note TN2315 at: https://developer.apple.com/library/mac/technotes/tn2315/_index.html. If you have already installed the Mac OS X FTDI VCP Driver, version 2.2.18 and now want to remove this driver, then follow the FTDI uninstall instructions at section 4.1 Uninstalling VCP Drivers on page # 9 of the above mentioned FTDI Drivers Installation Guide for MAC OSX PDF document.

It is advisable to reboot you Mac OS X workstation after installing or removing VCP Serial drivers. Be sure to reboot after changing your serial driver environment. Otherwise, there is a likelihood that you serial driver environment change will not show up when again testing a HT memory data transfer.

As an aside, if you want to know about disabling and enabling the Mac OS X 10.9 Mavericks provided Apple VCB driver see section 7.1 Using VCP or D2XX with OSX 10.9 on page # 13 of the above mentioned FTDI Drivers Installation Guide for MAC OSX PDF document. Also there is a software utility tool available to enable and disable the Mavericks provided Apple VCB driver, see OS X Mavericks (10.9) - IMPORTANT, available here: http://www.enttec.com/support-center/kb/article/108-OS_X_Mavericks_%2810.9%29_-_IMPORTANT

One final note - be sure you only have one type of driver enabled at any time. VCP by Apple, VCP by FTDI or D2XX by FTDI .. these are each mutually exclusive.