Ever since I received my model 100 and even before I loaded custom firmware on it I’ve been experiencing the following issue:
- 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)
+1, I am experiencing similar issues.
That happens to me as well
What model of laptop? What OS?
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?
Edited the op with more details
I initially had this issue with an early delivery model. It was fixed in firmware 10.1 for me - have you tried using Chrysalis to update the firmware?
(For more detail, I found the “need to be plugged in twice” timeout was around 30s.)
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.
I just flashed 0.90.6-snapshot.55 but the issue remains.
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.
Interesting. I’m wondering why never in 3 years I had this issue with my model 01 however. Same machine, hub, cable - I just swapped the keyboard.
… 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.
Please email us at email@example.com. I believe this is a manufacturing issue with your board.
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.
Thanks for the info, Jesse. I managed to reproduce the issue with the method you described to take Kaleidoscope out of the equation.
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.
Hey, when can we expect some updates on this?