/dev/tty.* and /dev/cu.* and AppleUSBFTDI

Recently I have been struggling to upload to my Blue Pill (BP) and Maple Mini (MM) clones. The problem arised with whether I choose the /dev/tty.* or /dev/cu.* port of my USB to serial converter.

Using stm32flash, only the /dev/tty.* port works, an not the /dev/cu.* port. For stm32loader.py, both work. For maple_upload, only the /dev/cu.* port works. This was extremely confusing.

After a bit of searching, I came across the following: Arduino in OS X 10.9 Mavericks – Serial Port Issues. And there it was, AppleUSBFTDI was causing the problems! I am using a FTDI base adapter, and after unloading the Apple FTDI driver, and only loading the FTDI driver, everything is working again on the /dev/cu.* port Only stm32flash refuse to work with the /dev/cu.* port, no matter what.

As always, YMMW

My FTDI adaptors just arrived, so if I have time at the weekend, I will see if they have the same issue on my OSX machines

I have to say that I had already applied this apple_USB_FTDI hack long time ago. (Energia was permanently crashing), so this could be the reason I didn’t got such troubles. Maybe a good point for the reference/manual?

Hi Roger

Have you had time to test your FTDI adaptors yet?

RogerClark wrote:My FTDI adaptors just arrived, so if I have time at the weekend, I will see if they have the same issue on my OSX machines

Yes

Tried it this afternoon

The problem appears to be in STM32Flash

It seems incapable of opening CU devices

I didn’t write it, and I don’t think its supported by anyone, as I’ve already had to do some fixes for bugs on the PC where it only allowed COM port numbers from 1 to 9 (i,e single digit numbers)

STM32Flash is a bit convoluted as it supports both Windows and OX and Linux, so it has to separate sets of low level comms interaction code, and I think the makefile decides which low level c file to compile

I took a quick look at the code (its in the repo https://github.com/rogerclarkmelbourne/ … serial/src
)

So you could take a look at the code to see why the open() call fails on a CU device

But, its not the driver thats at fault, because I connected the FTDI usb serial adaptor to HW serial 1 (PA9 and PA10), and write a sketch using serial1.println – then uploaded the sketch via the bootloader to the board.
And the IDE can open the CU device and I can see the text comming from hardware serial 1.

So its just a bug in STM32Flash

Which I agree should be fixed, but I’m not sure I’m the ideal person to do it.

Looking quickly at the code, I think I found the guilty line around 206 of serial_posix.c of my 0.4 version :

/* 1. check device name match */
if (strncmp(ops->device, "/dev/tty", strlen("/dev/tty")))
return PORT_ERR_NODEV;


Martin

Well spotted.

I think i may as well remove that check, i can’t see why it would be beneficial.

Or if there is a reason to check, then we’d need to check for “cu” devices as well as tty.

I suppose the safest course of action is the second solution

Well, maybe the solution #1 is good too : removing that check !
Because why the author wished to verify that what we have written at command line is true, since I can decide to create a symbolic link such as /dev/ftdi pointing to /dev/ttyUSB99, that my choice …

Martin

Good point about symlinks

I actually just tried option #2 and it fixed the issue. But so will removing the check altogether.

One thing I have just noticed with the FDTI clone I have, is that its not as reliable at the high baud rate I have defaulted it to.

Edit BTW. There is an issue with the .a file being in git, I need to set git ignore to exclude it,

I agree with Martin and Roger.

Since we will (mainly) use stm32flash via the Arduino IDE, we know that the device/port sent to stm32flash will be either a /dev/tty or a /dev/cu, thus both will work.

If stm32flash is used “standalone”, then the validation makes sense, but for our purposes, I think it is better to remove the validation to get stm32flash working with both, since stm32flash flashes faster than stm32loader.py

Done.

I removed the test for /dev/tty

there is still a test to see if the path is valid at all, but thats all.

And it seems to work fine on OSX.

Thanks Roger!