I’m on a Mac, OS X 10.12.6, and I have compiled a firmware for my Model 01 before; when I was attempting to update my firmware today, I ran into this error:
Building output/Model01-Firmware/Model01-Firmware (0.0.0-gv1.22-3-gb745-dirty)
Press ENTER when ready…
Can’t find Model 01 serial port name at ~/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope/bin/find-device-port-macos line 80.
make: *** [flash] Error 2
I’ve tried resetting the git branches completely, unplugging / reconnecting the keyboard, but the error is the same. The searching I have done didn’t reveal any clues and I’m hoping someone here may be able to help me figure it out.
With the keyboard plugged in, try the following command at a terminal prompt:
$ system_profiler SPUSBDataType
Also this one:
$ ls -l /dev/cu.usb*
And furthermore, does typing on the keyboard work?
Last, you can try holding down the prog key while you plug in the keyboard, and keep it held until you run make flash; that might do the trick. I once flashed a bad experimental version of the firmware that made the keyboard non-functional, and the only way to flash it was to keep it in the bootloader when powering it on.
I’ve borked my keyboard many times when attempting to install firmware that I screwed up. For me the trick is to unplug the Model 01, wait until immediately before the Arduino IDE tries to upload the firmware, and then hold down the prog key and plug it back in. That usually works, although it sometimes requires multiple attempts.
I just tried holding holding the prog key while plugging the keyboard in and then hitting enter when prompted after running make flash, but I’m getting the same error.
Product ID: 0x0274
Vendor ID: 0x05ac (Apple Inc.)
Version: 6.24
Serial Number: D3H5266VVR1GHMFAX6PS
Speed: Up to 12 Mb/sec
Manufacturer: Apple Inc.
Location ID: 0x14400000 / 3
Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 0
Built-In: Yes
Bluetooth USB Host Controller:
Product ID: 0x8290
Vendor ID: 0x05ac (Apple Inc.)
Version: 1.46
Speed: Up to 12 Mb/sec
Manufacturer: Broadcom Corp.
Location ID: 0x14300000 / 2
Current Available (mA): 500
Current Required (mA): 0
Extra Operating Current (mA): 0
Built-In: Yes
Model 01:
Product ID: 0x2301
Vendor ID: 0x1209
Version: 1.00
Serial Number: CHIDHLE
Speed: Up to 12 Mb/sec
Manufacturer: Keyboardio
Location ID: 0x14100000 / 22
Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 0
ls -l /dev/cu.usb*:
crw-rw-rw- 1 root wheel 20, 7 Feb 6 19:40 /dev/cu.usbmodemCHIDHL1
The first thing to do is to unplug the keyboard and plug it back in a few times, and each time you plug it in, run those two commands again, and see if you get different values for “Serial Number” for your Model01 from system_profiler, and/or the filename of the device. The stuff after /dev/cu.usbmodem and the “Serial Number” ought to match, and they both ought to include the string kbio01, so I’m wondering if something is writing past the end of an array and clobbering that data, possibly with random numbers.
When you’ve checked that, and you just want to flash your firmware, find the file:
Kaleidoscope/etc/kaleidoscope-builder.conf
…and find this line:
Add one line after that as follows:
DEVICE_PORT=/dev/cu.usbmodem*
…but first, make sure that there’s only one file that matches that glob on your system (there was the first time you ran ls, so there probably still is, but better safe than sorry).
After that, you should be able to flash the firmware. Then check again, and see if you’re getting strings that don’t contain kbio01, and/or still don’t match. I recommend flashing the stock Model01-Firmware first, then following that up with your own version if that works.
Sorry I couldn’t get back to you quicker on this. Good luck!
Were you seeing the same error from find-device-port-macos? That’s a recent addition to the kaleidoscope-builder code that fixed a similar problem (couldn’t flash the firmware from macOS).
Anyone else who’s seeing this problem; it would be helpful to run those two commands, and report the output here. With more data, it will be easier to debug and fix this problem.
Building output/Model01-Firmware/Model01-Firmware (0.0.0-gv1.22-3-gb745-dirty) …
Press ENTER when ready…
Can’t find Model 01 serial port name at /Users/michael/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope/bin/find-device-port-macos line 80.
make: *** [flash] Error 2
The relevant output from system_profiler SPUSBDataType was:
Model 01:
Product ID: 0x2301
Vendor ID: 0x1209
Version: 1.00
Serial Number: Ckbio01E
Speed: Up to 12 Mb/sec
Manufacturer: Keyboardio
Location ID: 0x14112000 / 40
Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 0
The output from “ls -l /dev/cu.usb*” was:
crw-rw-rw- 1 root wheel 21, 47 9 Feb 20:41 /dev/cu.usbmodemCkbio011
Per your suggestion, adding DEVICE_PORT=/dev/cu.usbmodem* to the find-device-port-macos function resolved the issue.
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?
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:
Heu … my bad … the update worked for me to. Here the result i got
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 …
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.
