!NiceNano V2 halves not connecting (direct pin config)

[manic basin]

if you have a [supermini](#hardware message), try disabling its external crystal.

[red parcel]

I am using a wireless nicenano v2

[manic basin]

i'm trying to understand if it's an actualnice_nano_v2 (not purchased from Taobao or AliExpress) or one of the sorta-clones

[red parcel]

oh got it, yeah, it's a genuine nicenano

[manic basin]

Are those blue LEDs constantly lit, or did you just catch them at an interesting time?

[red parcel]

That pic was when I first setup the board. The lights were on because I hadn't flashed them yet.

[manic basin]

since you've flashed the left half's firmware on the right, you will absolutely have to go through the settings_reset procedure on both. I would suggest temporarily adding USB logging to all your builds—including settings_reset, because that way you can see if it's actually erasing settings:

  - board: nice_nano_v2
    shield: settings_reset
    snippet: zmk-usb-logging
    cmake-args: -DCONFIG_LOG_PROCESS_THREAD_STARTUP_DELAY_MS=8000

(the additional cmake argument delays logging output so you have a chance of catching things near boot; this is particularly troublesome on Windows)

[red parcel]

Thanks, I will try this now and report back 🙂

[red parcel]

ツ ❯ sudo tio /dev/tty.usbmodem11101
[22:37:05.520] tio 3.8
[22:37:05.521] Press ctrl-t q to quit
[22:37:05.525] Connected to /dev/tty.usbmodem11101
] <dbg> zmk: connected: Connected 3C:06:30:3E:36:57 (public)
[00:00:24.223,937] <dbg> zmk: update_advertising: advertising from 0 to 0
[00:00:24.223,968] <dbg> zmk: connected: Active profile connected
[00:00:24.224,060] <dbg> zmk: split_central_connected: SKIPPING FOR ROLE 1
[00:00:24.224,700] <dbg> zmk: zmk_usb_get_conn_state: state: 3
[00:00:24.224,700] <dbg> zmk: get_selected_transport: Both endpoint transports are ready. Using 0
[00:00:24.518,524] <dbg> zmk: security_changed: Security changed: 3C:06:30:3E:36:57 (public) level 2
[00:00:24.996,520] <dbg> zmk: le_param_updated: 3C:06:30:3E:36:57 (public): interval 12 latency 0 timeout 72
[00:00:29.251,098] <dbg> zmk: le_param_updated: 3C:06:30:3E:36:57 (public): interval 12 latency 0 timeout 72
[00:01:00.366,851] <dbg> zmk: vddh_sample_fetch: ADC raw 3014 ~ 4415 mV => 100%
[00:02:00.366,851] <dbg> zmk: vddh_sample_fetch: ADC raw 3011 ~ 4410 mV => 100%

[red parcel]

ツ ❯ sudo tio /dev/tty.usbmodem401301
[22:38:09.903] tio 3.8
[22:38:09.904] Press ctrl-t q to quit
[22:38:09.907] Connected to /dev/tty.usbmodem401301
raw 3016 ~ 4415 mV => 100%
[00:00:00.371,917] <dbg> zmk: zmk_battery_update: Setting BAS GATT battery level to 100.
[00:00:00.466,430] <dbg> zmk: zmk_usb_get_conn_state: state: 6
[00:00:00.466,491] <dbg> zmk: zmk_usb_get_conn_state: state: 1
[00:00:00.466,491] <dbg> zmk: zmk_usb_get_conn_state: state: 1
[00:00:00.522,888] <dbg> zmk: zmk_usb_get_conn_state: state: 3
[00:00:00.522,918] <dbg> zmk: zmk_usb_get_conn_state: state: 3
[00:00:00.920,593] <dbg> zmk: split_svc_pos_state_ccc: value 1
[00:00:00.920,684] <dbg> zmk: security_changed: Security changed: F6:8D:A3:D9:C8:F6 (random) level 2
[00:00:00.935,974] <dbg> zmk: split_svc_select_phys_layout_callback: Selecting physical layout after GATT write of 0
[00:01:00.362,854] <dbg> zmk: vddh_sample_fetch: ADC raw 3013 ~ 4410 mV => 100%
[00:02:00.362,854] <dbg> zmk: vddh_sample_fetch: ADC raw 3015 ~ 4415 mV => 100%

[red parcel]

11101 is the left half

[manic basin]

I'm not sure I see anything wrong here, but I also don't see the startup sequences where the pins are initialized and saved pairing information is loaded. Can you reset the left half with tio running?

Feel free to dump text files into this thread, though I'm hours past my bedtime—I gotta bounce

[red parcel]

Sure, no problem, thanks for the help.

[red parcel]

First is left half

[sage lintel]

I'm also not seeing anything weird

Could you perhaps flash reset to both halves, then flash a known firmware like that of the sweep (cradio) and see if the n!n are happy to connect?

[ruby dawn]

kscan is wrong https://github.com/tiltedapp/mini18/blob/main/config/boards/shields/mini18/mini18.dtsi#L13-L36

[sage lintel]

Just to verify that it is indeed on the firmware side, proper n!n should be reliable but it can't hurt to check

[red parcel]

WHat part of the kscan do you the error in?

[ruby dawn]

Check the kscan section with the "split keyboard" tab selected. https://zmk.dev/docs/development/hardware-integration/new-shield#kscan

[red parcel]

Checking now

[ruby dawn]

I also see potential signs of LLM generated code, zmk/zephyr/devicetree is a niche language to LLMs and those generated code are almost always wrong.

[red parcel]

Yeah, there is, I was trying to troubleshoot it with an llm just now. I pushed a few builds that failed.

[red parcel]

I see, I need to set it up this way, like in the tab

[ruby dawn]

The ideal way to do this (IMO) would be, use &pro_micro 2 - 9 in kscan for the left side, use 10 - 21 on the right side, then set the matrix-transform col-offset to 8 on the right side.
This way the position of the first key on the right side would be number 0 plus col-offset of 8, position 8 in the keymap (ninth, counting from 0)

But because your left and right side doesn't share any pins at all, technically you could just remove the col-offset in _right.overlay and it should also work.

[red parcel]

Got it. Ok, thank for that tip

Any other quirks when doing direct to pin?

[ruby dawn]

I'm not aware of any.

[red parcel]

ok, thank you, I'll throughly go through that documentation you linked, and set it back up like that.

thank you

[light salmon]

You can also see https://github.com/zmkfirmware/zmk/blob/main/app/boards/shields/cradio/cradio.dtsi as a direct pin example

[red parcel]

Great, I will check that out too

[ruby dawn]

Using the first key on the right side as an example, currently it's getting a kscan position of 8 (&pro_micro 19 is ninth in kscan), then it's getting a column offset of 8. Key position 8+8 = 16 (17th, counting from 0) and it's outside of your keymap.

[red parcel]

Ok, so it is registering the 19 pin, which is correct, but the offset is throwing it off?

am I understanding correctly?

[ruby dawn]

Yeah. Two ways of solving it

1. The ideal way: fix the kscan so &pro_micro 19 is the first pin in kscan on the right side, then apply offset.
2. Remove the offset because your kscan already have &pro_micro 19 at ninth position.

[red parcel]

Got it

[red parcel]

Implementing all of this now