Serial Port not Enumerating on Mac Sierra

I have some custom boards that are not enumerating the Serial port on the latest MacOs Sierra. The same boards work great on Linux and Windows. I am thinking it is something with the macOS itself. The Device shows up fine in system profiler and in console.
{
"sessionID" = 665958207013298
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 3
"bcdDevice" = 513
"Bus Power Available" = 250
"USB Address" = 3
"bMaxPacketSize0" = 64
"iProduct" = 2
"iSerialNumber" = 3
"bDeviceClass" = 0
"Built-In" = No
"locationID" = 18446744073660465152
"bDeviceSubClass" = 0
"bcdUSB" = 256
"USB Product Name" = "Maple 003"
"PortNum" = 3
"non-removable" = "no"
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
"Device Speed" = 1
"USB Vendor Name" = "LeafLabs"
"idVendor" = 7855
"IOGeneralInterest" = "IOCommand is not serializable"
"USB Serial Number" = "LLM 003"
"IOClassNameOverride" = "IOUSBDevice"
}

Small update. If I reboot with the device plugged in, the maple serial port shows up, but when I try to upload to it, it tried to upload via dfu and fails. After removing and replugging in the device, it fails to show up as a serial port again.

Have you tried using a USB hub? I found on my MacBook with Mavericks, using a USB hub to connect the boards to the Mac usually works if the Mac does not recognize the board. YMMV

Kenjutsu wrote:Have you tried using a USB hub? I found on my MacBook with Mavericks, using a USB hub to connect the boards to the Mac usually works if the Mac does not recognize the board. YMMV

Can you try a non bootloader version, that has usb serial?

I.e flash via stlink?

It sounds like the mac does not like the board changing from being a dfu device to a serial device.

BTW. On your custom board, how do you reset the USB?
Do you just have the 1.5k pullup and rely on the GPIO hack we use for the BluePill, or do you have a transistor to reset the USB like on the Maple Mini etc

PS. All my macs are too old to run Sierra so it would be virtually impossible for me to test this, as running a Sierra VM on a PC Hackintosh would most likely not perform the same as real Mac hardware due to chipset differences

Roger, On my custom board I am using the 1.5k pull up and relying on the gpio hack. The symptoms seem to fit your theory on switching from dfu to serial and vise versa. I’ll try uploading with usb to uart tomorrow and see if that works without the bootloader. I’ll report back my findings. I also just found a maple mini I had lying around, I’ll try that as well.

If that is the case, I have a few other macs I can try it out on just to confirm it is not isolated to mine. Then, I’ll work on the timings of the bootloader to see if that is all it is. Thanks for the direction. I didn’t even know where to start.

I am just concerned it is an issue specific to me as it does not appear that anyone else is having this issue.

I’m not sure if this will help, but some recent changes to the bootloader allow additional control of the way the bootloader behaves by using the battery backed RAM registers in the STM32 which survive a restart / reboot.

I’m not really using the new feature yet, but basically, we can lock the bootloader into DFU note (like pressing the button on the Maple mini), by setting one of the registers in RAM prior to the sketch rebooting the board.

But that probably won’t help you, if the problem is the Mac doesn’t spot the change from DFU to Serial.

Anyway, its just a thought

Update: I tested on the maple mini, and it works fine on my MacOS Sierra, so it is an issue with either my custom board, or the gpio reset hack itself. On my custom board I use the reset hardware similar to the bluepill, but the button, led, and pinmap are identical to the maple mini in all other regards. I don’t have a bluepill to check if it is a config issue. I’m ordering one now, but we all know how long that will take. These custom boards of mine work great on windows and linux, I just pulled out this mac and never used any stm32duino stuff on mac, so I don’t know if it is a new issue or not.

I tried to upload via just serial, but that compilation disables the usb port. I added the -DSERIAL_USB flag and got it to compile and upload. The usb serial port works great at that point by skipping the dfu on boot. I’m going to play around with the gpio usb reset hack timings and see if it has something to do with that.

WOOHOO I think I found the problem. Apparently mac Sierra requires a longer delay when reenumerating. I changed the for loop for the gpio hack to increase the time the USB D+ pin is held low in boards_setup.cpp under the STM32F1/variants/*variant*/wirish/.

It was set to
for(volatile unsigned int i=0;i<512;i++);

It was definitely just a timing issue. I ended up just changing the bootloader. With both modifications, it works great, except for autoreset after upload (which didnt work on the maple mini either) on Mac, but I’ll dig into that later. In the bootloader code, the initial loop was a do while loop for 1024 times. It was commented out and changed to a 512 for loop in usb.c.

for(delay = 0;delay<512;delay++);

// volatile unsigned x = 1024; do { ; }while(--x);// wait a moment

Ok…

I will need to get some other people to test this on their hardware, as I vaguely recall that if the reset is too long it didnt work for some people.

BTW. Did you upgrade an existing machine to Sierra, or if this a new machine?

I would have thought that the length of the USB pulse this is required would be more related to the motherboard chipset than the OS, but I guess its possible that the driver in Sierra takes longer to respond than on El Capitan.