Serial Numbers, MAC, and device name on MacOSX

Status
Not open for further replies.
J

jimlux

Active member
An interesting MacOSX feature discovered with TyQT on a Mac.
Normally, the serial number of the USB device winds up as the device name (e.g. /dev/cu.usb12345 corresponds to SNR=12345). However, I was testing this morning and found a case where this isn't what happens. I was running TyQt to see what the serial numbers and devices were, and noticed they were different. So I checked it a different way, using the pyserial module for python, which has a convenient list_ports() function.
['/dev/cu.usbmodem33521', 'USB Serial', 'USB VID:pID=16c0:483 SNR=33522'],
['/dev/cu.usbmodem33471', 'USB Serial', 'USB VID:pID=16c0:483 SNR=33476'],
['/dev/cu.usbmodem33481', 'USB Serial', 'USB VID:pID=16c0:483 SNR=33483'],
['/dev/cu.usbmodem33661', 'USB Serial', 'USB VID:pID=16c0:483 SNR=33663'],
['/dev/cu.usbmodem33461', 'USB Serial', 'USB VID:pID=16c0:483 SNR=33464']]

This matches the output from TyQt (and what the Arduino IDE reports). The SNR reported by TyQt and python DOES match the MAC (e.g. 33464 corresponds to a MAC ending in 82:B8). It also matches what shows up if you dump the USB tree out.
USB Serial:

Product ID: 0x0483
Vendor ID: 0x16c0
Version: 1.00
Serial Number: 33464
Speed: Up to 12 Mb/sec
Manufacturer: Teensyduino
Location ID: 0x14255000 / 32
Current Available (mA): 500
Current Required (mA): 100


Take home message: you don't know, a priori, what the device name will be for a given serial number. Those of us working in Windows already had this issue with COM port numbers being capricious and arbitrary. This is why I was looking at device serial numbers in the first place: I go out and find all the COM ports, and test them to see which ones are connected to a Teensy (looking for the PID/VID) and then send a command to my code on the teensy to read back the MAC (which also tells me that the version of the software loaded is correct).
 
This is a bug in the OS X CDC driver, which Apple does not seem to care about. Like many bugs in their low-level code (personal rant about OS X's "POSIX" layer and broken kqueue). Basically, the last digit from the serial number is ignored and replaced by '1'. You can follow Paul's explanations in this topic: https://forum.pjrc.com/threads/25482-Duplicate-usb-modem-number-HELP

It's the reason why Paul added the 'serial = MAC * 10' workaround so that devices with similar MACs don't conflict (e.g. 56774 and 56775 would show up as /dev/cu.usbmodem56771). Which is what the problem in the topic I linked was.

Interestingly, when the HID bootloader shows up the serial number is in hexadecimal, and without the workaround so you can directly convert it to the MAC.

The good thing however is that you can directly get the device node from the MAC, just append '1'. Although apparently, it'll behave differently if the MAC number is big enough (> 10000000). There's some info in the workaround commit in the Teensy core: https://github.com/PaulStoffregen/cores/commit/4d8a62cf65624d2dc1d861748a9bb2e90aaf194d
 
Last edited:
Also, if you're feeling adventurous you can use the SetupAPI and ConfigurationManager stuff from Win32 to map the COM ports to the USB registry keys and get the corresponding serial numbers.

It's not fun to do, and one of those obscure Win32 API corners. There are hundreds of lines in TyQt's device_win32.c dealing with these APIs.
 
Last edited:
Probably.. Teensyduino 1.18 on the Mac (don't know a good way to get the "as installed" version, but the dmg is from August 2014)

Although... I was doing some tests on another Windows machine, and I recall seeing the SN come in at 10x(2 LSBs of MAC), so at least one of my test machines has the x10 change.
 
Status
Not open for further replies.
Back
Top