Problem programming Arduino Pro Mini from FTDI Basic

I’m trying to program an Arduino Pro Mini from my SparkFun FTDI Basic board. Uploading from the Arduino IDE works fine the first time after connecting the FTDI Basic to USB, but subsequent attempts to upload fail with the typical error:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync:

I can sometimes get the upload to work by holding down the Pro Mini’s reset button, starting the upload, and releasing the reset button, but that seems to be timing-sensitive.

The pins on the programming header of this Pro Mini read GRN, TX0, RX1, VCC, GND, BLK left to right. The corresponding pins on the FTDI Basic read DTR/GRN, RX1, TX0, 3V3, CTS, GND/BLK. Both devices are using 5V. I am using the stock drivers from Mac OS X Yosemite.

The mismatch between the Pro Mini’s “GND” and the FTDI Basic’s “CTS” pin lead me to think there is some flow control / reset magic that’s not happening correctly. If anyone can offer some pointers on how to get this working, I’d appreciate it… would rather not wear out my cable if I can avoid it!

Thanks in advance!

Mac’s are known to have reset issues. There was a thread a few weeks ago where he had to use a windows machine. I think he narrowed it down to a driver issue.

You can always Google those errors and see what you can find. I can tell that they are very common and are received for a number of reasons.

Am I more likely to have success using the 3rd party FTDI drivers rather than the ones that come with OS X? Last time I checked, they were pretty old, and I hesitate to install them on an OS that’s several years newer.

Probably. I don’t use a Mac, so if you can find them and verify there legit, go for it.

No idea why this should be, and I have no experience with this myself, but I have read that Macs require a higher value capacitor between the computer and the DTS line–10uF versus 0.1 uF for PCs.

–Michael

Interesting. If I had a MAC, I would try this. If anyone tries, please let us know if it works… I suspect that a higher value cap would lengthen the delay on the reset line.