Xiao Seed BLE (nRF52840) Random disconnect and issues reconnecting

[aymane-eljerari]

I'm trying to debug a connectivity issue that occurs randomly. I am using a split keyboard each with a nRF52840. A third nRF52840 connected to my computer acts as the controller. I am currently using tio to view the output logs with only (Connected and Disconnected messages showing). Using the docs, I tried adding support for logging as per the last commits a06bb6a, but all builds have failed.

When a half, or both half fail, calling the &sys_reset binding doesn't fix the issue. However connecting the keyboard to a power source is usually enough to get the problem fixed. Other times, a re-flashing of the keyboard half is required to get it to work again.

How can I enable the highest level of logging for my configuration to begin trying to pinpoint the issue?

[caksoylar]

I think enabling Studio here causes a problem with logging, when I look at the build that should have otherwise worked. I assume the messages from tio might be related to Studio too, given it shouldn't present a COM port without logging otherwise.

I assume it could work if you used the Studio snippet as documented, but unless you specifically need to debug Studio, you can just remove the Kconfig I linked.

For the actual problem though, have you tried https://zmk.dev/docs/troubleshooting/connection-issues#split-keyboard-halves-unable-to-pair?

[lesshonor]

You mistyped seeeduino_xiao_ble in
aymane-eljerari/forager-zmk-module-dongle@a06bb6a.

Remember to check the contents of your build logs when a build fails: https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures

[aymane-eljerari]

Thank you for the feedback! Yes, I realized I had made a typo and fixed it after looking through the build output. Disabling ZMK Studio is what actually fixed the issue. I can now view the full log. I will let it run until the disconnection issue occurs. Hoping the logs will give an idea about what might be causing this.

I did look at the Connection Issues page, and I am wondering if this might be caused by transmission power. Maybe CONFIG_BT_CTLR_TX_PWR_PLUS_8 could fix this?

[aymane-eljerari]

One of the half randomly disconnected as I was using it. Here is the log output around where it happened:

[00:10:47.031,250] <dbg> zmk: peripheral_event_work_callback: Trigger key position state change for 31
[00:10:47.031,311] <dbg> zmk: zmk_keymap_apply_position_state: layer_id: 2 position: 31, binding name: key_press
[00:10:47.031,341] <dbg> zmk: on_keymap_binding_released: position 31 keycode 0x70062
[00:10:47.031,372] <dbg> zmk: hid_listener_keycode_released: usage_page 0x07 keycode 0x62 implicit_mods 0x00 explicit_mods 0x00
[00:10:47.031,372] <dbg> zmk: zmk_hid_implicit_modifiers_release: Modifiers set to 0x00
[00:10:47.031,402] <dbg> zmk: zmk_endpoints_send_report: usage page 0x07
[00:10:47.037,109] <dbg> zmk: split_central_notify_func: [UNSUBSCRIBED]
[00:10:47.037,231] <dbg> zmk: disconnected: Disconnected from D6:1F:F9:C1:BA:3B (random) (reason 0x08)
[00:10:47.037,261] <dbg> zmk: disconnected: SKIPPING FOR ROLE 0
[00:10:47.037,384] <dbg> zmk: split_central_disconnected: Disconnected: D6:1F:F9:C1:BA:3B (random) (reason 8)
[00:10:47.037,384] <dbg> zmk: release_peripheral_slot: Releasing peripheral slot at 1
[00:10:47.037,963] <dbg> zmk: start_scanning: Scanning successfully started
[00:10:47.038,024] <dbg> zmk: peripheral_event_work_callback: Trigger key position state change for 19
[00:10:47.038,085] <dbg> zmk: zmk_keymap_apply_position_state: layer_id: 2 position: 19, binding name: key_press
[00:10:47.038,116] <dbg> zmk: on_keymap_binding_released: position 19 keycode 0x70028
[00:10:47.038,146] <dbg> zmk: hid_listener_keycode_released: usage_page 0x07 keycode 0x28 implicit_mods 0x00 explicit_mods 0x00

It seems like disconnection occurs due to "reason 8", what is that? I couldn't find it documented anywhere on ZMK. Could this be cause by interference due to having my phone close by? (#718 (comment))

When a disconnect like this usually happens I can fix the issue by plugging the keyboard into a power adapter. This usually makes the onboard led light up in red and bluish color for about a second, then turns completely blue letting me know that keyboard is successfully connected to the controller (@caksoylar, I just noticed you're the main author of the LED indicator module, it works great, I really like it!).

Othertimes plugging the microcontroller into power doesn't do anything, when this happens I have to flash the firmware onto the keyboard half again.

[caksoylar]

I believe reason 8 is just connection timeout: https://docs.zephyrproject.org/apidoc/latest/hci__types_8h.html#ab702caf5cd73431cc9aede8891f74610

This usually makes the onboard led light up in red and bluish color for about a second, then turns completely blue letting me know that keyboard is successfully connected to the controller (@caksoylar, I just noticed you're the main author of the LED indicator module, it works great, I really like it!).

Thanks! Initial magenta (blue+red) blink means that the battery level is reported as zero: Either the battery is very dead, or it isn't detected by the controller. I assume your controller is out of battery somehow and it is resulting in erratic behavior when it is unplugged.

If the smaller green LED doesn't light up when you connect USB, it means it isn't charging the battery. Since it is improbable that the battery is already full, this means either the battery connection is bad, battery is bad, or the charging circuit is broken. I'd assume the first and double check all connections. (If you have a power switch, turn it on, etc.)

[aymane-eljerari]

Interesting, I didn't know that. I'm pretty sure that the batteries are charged. The disconnection issue occured again. I tried pushing the reset button on the microcontroller, but nothing happened. There was no light at all coming from it. However, the second I plug it in the green charging led lights up, then a few moments after the magenta light turns on. Whenever I see the magenta (blue+red) it is always immediately followed by a blue blink indicating the successful connection. So the issue is most definitely not caused by the battery. It seems to me that the magenta lighs up as part of an "initialization" process whenever the microcontroller gets plugged.

The disconnections happen so randomly I can't seem to figure out what is causing it. I am willing to use the reset button as a temporary fix to rerun the firmware every time the disconnection happens. Unfortunately the microcontroller's behavior is also unpredictable when I click the reset button. Sometimes after resetting, it lights up in magenta, then flashes blue and works fine. Othertimes resetting does nothing, so I have to plug it into power to get the same behavior (ie. light up in magenta, flash blue, successful connection). Almost as if plugging it in "revives" it, something the power from the onboard battery can't do.

I was under the impression that using a dedicated dongle would gurantee better connectivity/reliability. This seems like an interesting issue, so I'm wondering if the log output is descriptive enough to debug it. Can logging be set to an even higher level than what I've already shared?

[caksoylar]

Whenever I see the magenta (blue+red) it is always immediately followed by a blue blink indicating the successful connection. So the issue is most definitely not caused by the battery. It seems to me that the magenta lighs up as part of an "initialization" process whenever the microcontroller gets plugged.

The first blink (magenta here) happens after firmware starts running, the second blink is queued right after indicating the connection status. Why do you say that means the issue isn't caused by the battery?

However, the second I plug it in the green charging led lights up, then a few moments after the magenta light turns on.

From everything you said, it really sounds like the battery dies and plugging it into USB starts recharging it, at which point the firmware can boot up (and blink using the RGB LED). I'd assume there is no issue with the firmware, and you can't get any further information from logging if the problem is with power.

If I were you, I'd first leave the controllers connected to USB until the green LED turns off, to make sure they are fully charged. If you have a multimeter, you can also measure the voltage of the battery. If you want, you can post pictures of the soldering and your battery/power switch setups in a Discord help forum post. But GH issues is not the right venue for debugging that in my opinion.

[aymane-eljerari]

You were right! I couldn't believe the issue was battery related since the keyboard was still able to connect successfully and I could use it to type for a considerable amount of time. All I had to do was charge the battery, I was overthinking it a bit thank you for the help!