Ever since I received my model 100 and even before I loaded custom firmware on it I’ve been experiencing the following issue:
Repro:
unplug usb cable from keyboard for the night
open lid to wake up laptop in the morning
connect keyboard to operating (not sleeping etc) laptop by plugging usb-c into keyboard
keyboard doesn’t “wake up” - no keys are registering, no led functionality etc
unplug usb-c from keyboard
re-plug usb-c into keyboard
keyboard is now working as expected
Am I doing something wrong or is this a hw/sw issue?
System: 2021 M1 mac, macos 12.6
Connection: both direct via usb c-c cable I got with a google pixel 2, and via usb c-a cable into a Baseus usb c hub (both these connections work without problems for my model01)
How exactly is the Model 100 being connected? What kind of USB port is it plugged into on the laptop? What kind of cable is used? Are there any adapters, hubs, or extension cables in between?
I also had this issue with my out of the box m100. After Chrysalis update (-> 0.11.8) and flashing the newest firmware (-> 0.90.6-snapshot.54) this issue is gone.
This is sounding like a problem that I’ve heard about in many other contexts. The symptoms are roughly “USB-C ports on a M1 Mac (possibly running 12.x or later) don’t play nicely with USB-2.0 devices”. Unfortunately, I haven’t heard a good explanation for why it happens, and the explanations I’ve heard don’t make sense given what I know about the USB protocol.
I’ve heard that plugging the affected device into a USB-2.0 hub can help.
… hmmm. Upon updating to the latest firmware, the issue seems to have returned.
Unfortunately, I’ve also had to change some hardware including USB cables, so I can’t say for sure if it was just the firmware or a combination of firmware and USB hardware that resolved the issue previously.
For reference, symptons include:
timeout for re-connect seems to be around 100s
first connection shows nothing at all in dmesg, haven’t yet checked with anything that might detect a low level programming mode or something similar that might not show up but still be active.
It must be something though, because on Android the first connection wakes the device.
first connection only needs to be USB power, i.e. connection to USB power supply and then computer within 100s works
However, USB power connector did some weird stuff, at least once connecting to it twice seemed to cause the issue. I can’t reliably reproduce this, though.
Tested on Windows, Android, and Linux, using USB C cables of various types. More details as and when I have time to investigate further.
One way to entirely eliminate Kaleidoscope as a variable in testing is to hold in the “Prog” key while connecting the keyboard. When you do that, the device will stay in bootloader mode, never booting to Chrysalis. If everything works, the “Prog” key will turn red. If it doesn’t, the prog key will not turn red.
I think we’re now up to a total of four or five devices with this issue.
The first one was solved (as far as we can tell) by the customer (a trained EE with a professional lab) cleaning something leftover from manufacturing out of the USB port. We now have device #2 with this issue in-house and can reproduce the issue on a range of hardware, but have not yet been able to resolve it simply by cleaning the USB connector.
I’m going to poke a little harder before we send it back to the factory for them to ask their PCB assembly provider to dig into it.
Sorry for only sporadically coming back to this, life keeps getting in the way. Anyway, being a bear of very little brain but having access to basic tools, I’ve done a little more prodding of the hardware…
First of all, can I just verify that C13 and C14 are meant to be unpopulated? Not likely that they’d been missed, but just to be sure.
I thought I’d just start by seeing how far the voltage got, and ran into an interesting wrinkle - on the initial, failed connection, I get 3V across GND and 3V3 on the JTAG test pads, but GND/5V on the ATTiny test pads gives zero - or rather, under 0.5V, draining like I’m reading a cap. The second (good) connection then gets 5V to the ATTiny side of things.
I was hoping there’d be a nice serial port Rx/Tx set of pins I could monitor to see if there was something going on, but looking into it it looks like I need a JTAG or ST-LINK programmer… I’ve been meaning to get one of those though.
Anyway, I will get in touch with you by email at some point, but would like to carefully poke at it a little more myself first.
(Also, it’s such a pleasure to be able to open up a device with a standard set of screwdrivers, and see it all so nicely laid out.Very satisfying, just as good as I’d expected.)
C13 and C14 are marked as DNP (do not place) in the schematic, so it’s expected that they’re absent.
The 5V bus at the ATtiny test points is switched on by the firmware after USB enumeration and configuration has completed, so your measurements there are expected if that hasn’t happened yet. Probing the 5V side of C15 or C16 might be more informative. (They’re basically USB VBUS downstream of some protection and filtering.)
3.0V instead of 3.3V on the 3V3 bus seems low. The regulator should be able to do better than that.
Sorry, that was me being imprecise. The actual reading I get there is 3.29, and my voltmeter isn’t the priciest so it could well be bang on 3.3.
So for both of those, the initial (fail) connection gives 5.11, and then for the subsequent successful connection it’s 5.08. Don’t know if that’s of any use, I’m assuming the 0.03V difference is just the ATTiny side of things getting power.
I’ve orderd an ST-Link, which should arrive soonish, so hopefully I can have a bit of a lower level look at what’s going on there once it does… Might try to flash Black Magic onto it and see how I go with that.
