"Can't find Model 01 serial port name" on macOS

Thanks for the info. In both cases, the final character is an E from system_profiler, but a 1 in the device filename. I have no idea why that’s happening, but if that’s consistent, it’ll be simple enough to update the script to compensate.

I just did a double-check and the device filename does change:

$ ls -l /dev/cu*
crw-rw-rw- 1 root wheel 21, 3 10 Feb 05:43 /dev/cu.Bluetooth-Incoming-Port
crw-rw-rw- 1 root wheel 21, 1 10 Feb 05:42 /dev/cu.SSDC
crw-rw-rw- 1 root wheel 21, 9 10 Feb 18:43 /dev/cu.usbmodemCDkbio01

The Serial Number: Ckbio01E entry from the system_profiler output looks more like a model number than a serial number. My assumption is that the trailing E designates a production run number. In either case it does not seem to play much of a role in selecting the device name.

In one instance of listing the device name I got “cu.usbmodemCkbio011” in the other I got “cu.usbmodemCDkbio01”. I am not sure of what criteria OSX is using to add the “D” or the trailing “1”. However the kbio01 appears to be consistent.

Presuming that the user does not have two keyboardio keyboards hooked into the same Mac, you could probably get away with using “DEVICE_PORT=/dev/cu.usbmodemkbio01” as a search term. It is certainly safer than catching every device attached to the usbmodem driver.

BTW I tried to find the the find-device-port-macos function, but could not find where it is defined. Is the function definition missing from the distribution?

My asterisks got dropped.

Should have been a star both before and after kbio01.

As in, DEVICE_PORT=/dev/cu.usbmodemkbio01

Markdown Filters… :frowning:

DEVICE_PORT=/dev/cu.usbmodem*kbio01*

Using backticks for “code” works well: /dev/cu.usbmodem*kbio01*

We’re trying to determine the correct device name, rather than just guessing. And if you look at @blake’s report above, you’ll see that his (at least that one time) didn’t include the expected kbio01 string, which I believe comes from here:

@blake’s string was HIDHL, which likely came from this code instead:

Hello,

I got the same issue trying to update the firmware, with the Model01-Firmware.

Model 01:

      Product ID: 0x2301
      Vendor ID: 0x1209
      Version: 1.00
      Serial Number: Ckbio01E
      Speed: Up to 12 Mb/sec
      Manufacturer: Keyboardio
      Location ID: 0x00200000 / 11
      Current Available (mA): 500
      Current Required (mA): 500
      Extra Operating Current (mA): 0


Nicolass-Mac-Pro:Model01-Firmware nicolas$ ls -l /dev/cu.usb*
crw-rw-rw-  1 root  wheel   21,   5 18 Feb 16:11 /dev/cu.usbmodemCkbio011

In one i have a ‘E’ and he other i have a ‘1’.

i’m following this procedure to flash the firmware :slight_smile:

Any idea what i need to modify to make it work ?
(i couldn’t find the kaleidoscope-builder conf file)

Thanks,
Nicolas

Heu … my bad … the update worked for me to. Here the result i got :slight_smile:

Press ENTER when ready...

In Find device port
dir var /Users/nicolas/Documents/Arduino//hardware/keyboardio/avr/libraries/Kaleidoscope/bin
dev port prob /Users/nicolas/Documents/Arduino//hardware/keyboardio/avr/libraries/Kaleidoscope/bin/find-device-port-macos
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

I would say it works but not sure …
next step is trying to update the keymap … still looking …

1 Like

Sorry; for some reason I overlooked this question earlier. find-device-port-macos is a Perl script here: Kaleidoscope/bin/find-device-port-macos. It’s called from Kaleidoscope/etc/kaleidoscope-builder.conf:

I ran into the same problem. I managed it by just making the prober return the correct location.

    Model 01:

      Product ID: 0x2301
      Vendor ID: 0x1209
      Version: 1.00
      Serial Number: Ckbio01E
      Speed: Up to 12 Mb/sec
      Manufacturer: Keyboardio
      Location ID: 0x14100000 / 14
      Current Available (mA): 500
      Current Required (mA): 500
      Extra Operating Current (mA): 0

The correct node is /dev/cu.usbmodemCkbio011, which the current prober can’t autodetect from the above info. Perhaps something changed with High Sierra that broke the prober?

It’s definitely not happening on every machine running High Sierra, but there are enough occurrences of this same exact phenomenon that I’ll submit a PR to fix it soon; probably this evening.

1 Like

If you don’t mind, I’m interested to see what the output of this command is on a machine with this problem:

ioreg -p IOUSB -l -b | grep -E "@|PortNum|USB Serial Number"

In particular, the USB Serial Number string for the Model01, and if it’s different from what system_profiler shows.

Here’s what it looks like on mine; thanks for looking into fixing this:

  +-o AppleUSBXHCI Root Hub Simulation@14000000  <class AppleUSBRootHubDevice, id 0x1000003f3, registered, matched, active, busy 0 (0 ms), retain 13>
  +-o Model 01@14100000  <class AppleUSBDevice, id 0x1000014ea, registered, matched, active, busy 0 (7 ms), retain 20>
  |     "PortNum" = 1
  |     "USB Serial Number" = "Ckbio01"
  +-o iBridge@14200000  <class AppleUSBDevice, id 0x100001625, registered, matched, active, busy 0 (8 ms), retain 32>
        "PortNum" = 2

And system_profiler SPUSBDataType shows it as Ckbio01E?

It has Ckbio01, no E:

    Model 01:

      Product ID: 0x2301
      Vendor ID: 0x1209
      Version: 1.00
      Serial Number: Ckbio01
      Speed: Up to 12 Mb/sec
      Manufacturer: Keyboardio
      Location ID: 0x14100000 / 16
      Current Available (mA): 500
      Current Required (mA): 500
      Extra Operating Current (mA): 0

A strange thing is that that changed sometime in the last few hours. In addition, the /dev node has changed name to something the script would pick up:

crw-rw-rw-  1 root  wheel   33,   9 Feb 21 12:19 /dev/cu.usbmodemCkbio011

to

crw-rw-rw-  1 root  wheel   33,  13 Feb 21 12:30 /dev/cu.usbmodemCkbio01

It might have occurred when I flashed my firmware to my fork at https://github.com/treed/Model01-Firmware ; which is a few months out of date with the main repo, although there’s nothing operative. Perhaps there was a bug in the firmware as shipped from the factory? This model just arrived today, unsure if that’s true of the others having this problem.

It’s also worth noting that the port name when the device is in the bootloader may be different than the device name when you’re booted into keyboard mode.

The data the keyboard-mode firmware supplies to macOS (including the serial number) could change between flashings, but the bootloader version won’t be altered by a simple flash-over-USB.

The prior serial and port name held at least through the point where I held down prog and hit enter on the keyboard, which I think would be past the point of the bootloader?

The trouble is that system_profiler is now reporting a name that doesn’t match the device filename. I can update the prober script easily enough to compensate, but it feels like we’ll be going back to guessing.

Does ioreg tell more of the truth?

That’s what I’m trying to find out. Unfortunately, the only Mac I’ve got doesn’t seem to have this problem. Maybe I should try to trigger it by making it forget about the Model01 repeatedly?