Typeractive.xyz•6mo ago

Left side stopped working after flashing

I just flashed some new firmware to my typeractive corne (I've done so many times!) but my left (primary) half is now in a seemingly broken state. I can't get it to output any characters, either over USB or trying to switch to a previously-paired BT device. The nice!view displays an image, but it appears to be rendering once based on its boot state and not updating — if I insert or remove a USB-C cable, the charging status icon doesn't update, and similarly pressing a key that toggles a layer change doesn't update the layer name. The right half's display indicates it's not able to find a BT connection to the left half, assuming the right half is otherwise working properly. It appears I can successfully get the device to re-enter boot mode, and if I try to re-flashing a previous known good firmware it acts the same as a successful flash (i.e. an OS filesystem error and the USB mass storage device disconnects), but completing that does not change the behavior. Any tips for debugging?

19 Replies

TyperAI•6mo ago

It sounds like you're experiencing a common issue that can occur after flashing firmware. Here are some steps to help you troubleshoot the problem with your Corne keyboard: 1. Check the Bootloader: Since you can successfully enter boot mode, ensure that you are indeed flashing the correct firmware for your specific keyboard configuration (e.g., left half, right half, with or without nice!view). 2. Verify Firmware Compatibility: Make sure the firmware you are trying to flash is compatible with your keyboard's hardware version. If you have made any changes to the keymap or configuration, double-check that they are correct. 3. Clear Previous Bonds: If the left half is not connecting to the right half, try clearing the Bluetooth bonds. You can do this by pressing the &bt BT_CLR key on your keyboard to clear the bond for the currently active profile. Make sure to do this for both halves. 4. Inspect Solder Joints: Since the left half is not responding, it could be a hardware issue. Check the solder joints on the nice!nano and ensure that all connections are solid. Look for any potential shorts or cold solder joints. 5. Test with Known Good Firmware: If you have a known good firmware file, try flashing it again. Sometimes, the flashing process can fail without a clear indication, so re-flashing might help. 6. Check Power Supply: Ensure that the power switch is in the "on" position and that the battery is properly connected. If the battery is low or not connected correctly, it could cause issues. 7. Inspect the nice!view: Since the display is not updating, there may be an issue with the nice!view connection. Ensure that it is properly soldered and connected. 8. Try a Different USB Cable/Port: Sometimes, the issue can be as simple as a faulty USB cable or port. Try using a different cable or connecting to

lazerwalkerOP•6mo ago

(I've confirmed I'm flashing a left-half firmware, which also is evidenced by the OLED showing the primary half display. Same USB cable/port can flash the right half successfully. Think those are the only relevant bits in the robo-response not already covered) okay, going back to an older known good build than the one I'd previously tried seems to fix it. Now to just debug why this syntactically correct firmware shouldn't be doing anything meaningfully different than past ones is broken.

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

If I manually deleted all of the changes I'd made since the last known good build and generated a new build, that one works. I'm systematically reapplying all of my changes until I can find the bad change(s). My current guess (that may be wildly incorrect) is a secret size limit on combo names

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

Yes, I agree that's the behavior I'm seeing. If I then turn off the right half, the left half works, but only after power cycling it. I've confirmed the right half is running matching firmware as the left, so it's not a case of firmware version mismatch (great catch!!)

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

when the left half is nonfunctioning, the nice!view also shows a "0" in the bottom right corner of the graph yeah, the workflow job is just set to grab the latest workflow file from zmkfirmware/zmk/.github/workflows/build-user-config.yml@main rather than a specific tag or commit, I wonder if something got pushed upstream that has issues with our hardware

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

ah, yeah, same here, I just hadn't been testing with the graph showing any numbers

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

looks like dependabot automatically updated a dependency in that file 10 hours ago I assume this issue is new as of today for you? (otherwise it hasn't been touched in 3 weeks, so if it's not that it's unlikely to be the culprit)

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

I'm trying a build now pinned at the commit prior to that one No dice, that would have been too easy have you tried flashing with the reset firmware yet? (I'm flashing with settings-reset, and then flashing with a firmware that has USB logging enabled) settings-reset firmware did not make a difference. well, there's a clear (if not very verbose) logging error:

[00:00:35.574,096] <dbg> zmk: split_central_eir_found: Found the split service
[00:00:35.574,096] <dbg> zmk: zmk_ble_put_peripheral_addr: Found existing peripheral address in slot 0
[00:00:35.574,127] <dbg> zmk: stop_scanning: Stopping peripheral scanning
[00:00:35.574,371] <dbg> zmk: split_central_eir_found: Initiating new connection
[00:00:35.681,854] <dbg> zmk: connected: Connected thread: 0x20006ce8
[00:00:35.681,854] <dbg> zmk: connected: SKIPPING FOR ROLE 0
[00:00:35.681,976] <dbg> zmk: split_central_connected: Connected: D8:0C:A0:1C:96:40 (random)
[00:00:35.681,976] <dbg> zmk: split_central_process_connection: Current security for connection: 1
[00:00:35.682,037] <dbg> zmk: split_central_process_connection: New connection params: Interval: 6, Latency: 30, PHY: 1
[00:00:35.682,037] <dbg> zmk: start_scanning: All devices are connected, scanning is unnecessary
[00:00:35.691,528] <dbg> zmk: split_central_service_discovery_func: [ATTRIBUTE] handle 28
[00:00:35.691,558] <dbg> zmk: split_central_service_discovery_func: Found split service
[00:00:35.705,810] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 2
[00:00:35.705,841] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 5
[00:00:35.736,236] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 7
[00:00:35.736,267] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 10
[00:00:35.750,793] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 12
[00:00:35.750,823] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 14
[00:00:35.773,284] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 17
[00:00:35.773,315] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 22
[00:00:35.788,269] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 24
[00:00:35.788,330] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 26
[00:00:35.803,344] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 29
[00:00:35.803,344] <dbg> zmk: split_central_chrc_discovery_func: Found position state characteristic
[00:00:35.803,436] <dbg> zmk: split_central_subscribe: [SUBSCRIBED]
[00:00:35.833,343] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 32
[00:00:35.833,374] <dbg> zmk: split_central_chrc_discovery_func: Found run behavior handle
[00:00:35.863,342] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 35
[00:00:35.863,372] <dbg> zmk: split_central_chrc_discovery_func: Found select physical layout handle
[00:00:35.863,433] <err> bt_att: Error signing data

[00:00:35.574,096] <dbg> zmk: split_central_eir_found: Found the split service
[00:00:35.574,096] <dbg> zmk: zmk_ble_put_peripheral_addr: Found existing peripheral address in slot 0
[00:00:35.574,127] <dbg> zmk: stop_scanning: Stopping peripheral scanning
[00:00:35.574,371] <dbg> zmk: split_central_eir_found: Initiating new connection
[00:00:35.681,854] <dbg> zmk: connected: Connected thread: 0x20006ce8
[00:00:35.681,854] <dbg> zmk: connected: SKIPPING FOR ROLE 0
[00:00:35.681,976] <dbg> zmk: split_central_connected: Connected: D8:0C:A0:1C:96:40 (random)
[00:00:35.681,976] <dbg> zmk: split_central_process_connection: Current security for connection: 1
[00:00:35.682,037] <dbg> zmk: split_central_process_connection: New connection params: Interval: 6, Latency: 30, PHY: 1
[00:00:35.682,037] <dbg> zmk: start_scanning: All devices are connected, scanning is unnecessary
[00:00:35.691,528] <dbg> zmk: split_central_service_discovery_func: [ATTRIBUTE] handle 28
[00:00:35.691,558] <dbg> zmk: split_central_service_discovery_func: Found split service
[00:00:35.705,810] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 2
[00:00:35.705,841] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 5
[00:00:35.736,236] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 7
[00:00:35.736,267] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 10
[00:00:35.750,793] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 12
[00:00:35.750,823] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 14
[00:00:35.773,284] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 17
[00:00:35.773,315] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 22
[00:00:35.788,269] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 24
[00:00:35.788,330] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 26
[00:00:35.803,344] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 29
[00:00:35.803,344] <dbg> zmk: split_central_chrc_discovery_func: Found position state characteristic
[00:00:35.803,436] <dbg> zmk: split_central_subscribe: [SUBSCRIBED]
[00:00:35.833,343] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 32
[00:00:35.833,374] <dbg> zmk: split_central_chrc_discovery_func: Found run behavior handle
[00:00:35.863,342] <dbg> zmk: split_central_chrc_discovery_func: [ATTRIBUTE] handle 35
[00:00:35.863,372] <dbg> zmk: split_central_chrc_discovery_func: Found select physical layout handle
[00:00:35.863,433] <err> bt_att: Error signing data

lazerwalkerOP•6mo ago

FYI: https://github.com/zmkfirmware/zmk/issues/2461

GitHub

As of mid-day 9/6, new GitHub builds cause BT signing error for int...

I have a wireless Corne using two nice!nanos and two nice!views. Starting earlier today, new builds seem to error out when trying to connect both halves. The way I experience this: if the right (se...

lazerwalkerOP•6mo ago

I'm logging off for the night, but curious to poke at the Docker angle. I once again reverted my git repo to a commit that had previously built properly, and the new build is not working while the historic firmware files I do from that commit still do.

Unknown User•6mo ago

Message Not Public

lazerwalkerOP•6mo ago

Looks like it should theoretically be fixed for new builds, Pete reverted some split-related code that got merged today. I’m headed to bed for the night, but if anyone else in here has the ability to test, could be useful to chime in on the GH thread.

Unknown User•6mo ago

Message Not Public

Gaming

Programming

Left side stopped working after flashing

Did you find this page helpful?