[GH-ISSUE #88] Pairing Failed (16) on Seeed XIAO nrf52840

roman commented

2026-10-22 04:59:53 +00:00

Owner

Originally created by @t00fatt on GitHub (Jun 27, 2026).
Original GitHub issue: https://github.com/safijari/openpuck/issues/88

I'm running OpenPuck on a Seeed XIAO nRF52840. To get the project to compile, I had to replace the TinyUSB 1.7.0 library bundled with the Seeeduino board package with TinyUSB 3.6.0.
The firmware builds successfully, and I can connect to the OpenPuck configuration web app without any issues. However, when I attempt to pair my Steam Controller through Steam, the pairing process fails with the error "Pairing Failed (16)." The controller is set to the left-puck pairing mode slot.

Originally created by @t00fatt on GitHub (Jun 27, 2026). Original GitHub issue: https://github.com/safijari/openpuck/issues/88 I'm running OpenPuck on a Seeed XIAO nRF52840. To get the project to compile, I had to replace the TinyUSB 1.7.0 library bundled with the Seeeduino board package with TinyUSB 3.6.0. The firmware builds successfully, and I can connect to the OpenPuck configuration web app without any issues. However, when I attempt to pair my Steam Controller through Steam, the pairing process fails with the error "Pairing Failed (16)." The controller is set to the left-puck pairing mode slot.

roman commented

2026-10-22 04:59:54 +00:00

Author

Owner

@safijari commented on GitHub (Jun 27, 2026):

Thank you for testing. My seeed board arrives in a few days so I'll test and try to fix then.

@safijari commented on GitHub (Jun 27, 2026): Thank you for testing. My seeed board arrives in a few days so I'll test and try to fix then.

roman commented

2026-10-22 04:59:55 +00:00

Author

Owner

@treblechet commented on GitHub (Jul 1, 2026):

Hello, so thanks for the tip of the library, I'm in the same situation with my board choice.

I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board.

@treblechet commented on GitHub (Jul 1, 2026): Hello, so thanks for the tip of the library, I'm in the same situation with my board choice. I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board.

roman commented

2026-10-22 04:59:56 +00:00

Author

Owner

@safijari commented on GitHub (Jul 1, 2026):

Hello, so thanks for the tip of the library, I'm in the same situation with my board choice.

I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board.

Oh it's working? Can you please commit any necessary changes / documentation improvements for that?

@safijari commented on GitHub (Jul 1, 2026): > Hello, so thanks for the tip of the library, I'm in the same situation with my board choice. > > I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board. Oh it's working? Can you please commit any necessary changes / documentation improvements for that?

roman commented

2026-10-22 04:59:56 +00:00

Author

Owner

@t00fatt commented on GitHub (Jul 2, 2026):

Hello, so thanks for the tip of the library, I'm in the same situation with my board choice.

I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board.

Can you share how you compiled the firmware or your binary for the xiao board? I'm in over my head and not sure exactly what I'm doing.

Much appreciated!

@t00fatt commented on GitHub (Jul 2, 2026): > Hello, so thanks for the tip of the library, I'm in the same situation with my board choice. > > I will say I had no issues with pairing my controller to my board, there was a recent controller and puck firmware update so maybe that changed things, but it seems to work well with the Xiao board. Can you share how you compiled the firmware or your binary for the xiao board? I'm in over my head and not sure exactly what I'm doing. Much appreciated!

roman commented

2026-10-22 04:59:57 +00:00

Author

Owner

@treblechet commented on GitHub (Jul 3, 2026):

The following instructions here are for Windows. Go through step three of the build guide, then:

The board package for the XIAO board needs to be added as per these instructions. However, you can install it using
arduino-cli core install Seeeduino:nrf52 --additional-urls https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json

Verify that the board is properly recognized by running arduino-cli board list and that it doesn't just state "unknown."

Now, the "Adafruit TinyUSB Library" needs to be replaced with a newer version than 1.7.0, which, if you installed the Adafruit board package, is present on your computer.

Replace the directory of
%appdata%\..\Local\Arduino15\packages\Seeeduino\hardware\nrf52\1.1.13\libraries\Adafruit_TinyUSB_Arduino
with the directory of
%appdata%\..\Local\Arduino15\packages\adafruit\hardware\nrf52\1.7.0\libraries\Adafruit_TinyUSB_Arduino
or grab the library from here.

Now you can run
arduino-cli compile -b Seeeduino:nrf52:xiaonRF52840Sense --build-property "build.extra_flags=-DNRF52840_XXAA {build.flags.usb} -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64 -DCFG_TUD_VENDOR_TX_BUFSIZE=256" OpenPuck
The same command as present in the build guide but with the FQDN replaced with your board. If it does throw an error, double-check that the Adafruit TinyUSB Library is not version 1.7.0 (and preferably should be 3.6.0 because that has been confirmed to work).

Then you can follow the build instructions again, replacing that the board port and FQDN (and ensuring that the board is in DFU mode, double-pressing the RST button and that you can see the XIAO-SENSE drive in File Explorer).

In my case, I ran
arduino-cli upload -b Seeeduino:nrf52:xiaonRF52840Sense -p COM6 OpenPuck

If everything works, you should see "device programmed", the XIAO-SENSE drive disappear, and the status LED on the board light up.

Also I'd recommend making sure that the controller and puck firmware are up to date before attempting to pair the controller to the board, since that's what I did.

@treblechet commented on GitHub (Jul 3, 2026): The following instructions here are for Windows. Go through step three of the build guide, then: The board package for the XIAO board needs to be added as per [these instructions](https://wiki.seeedstudio.com/XIAO_BLE/). However, you can install it using ```arduino-cli core install Seeeduino:nrf52 --additional-urls https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json``` Verify that the board is properly recognized by running ```arduino-cli board list``` and that it doesn't just state "unknown." Now, the "Adafruit TinyUSB Library" needs to be replaced with a newer version than 1.7.0, which, if you installed the Adafruit board package, is present on your computer. Replace the directory of ```%appdata%\..\Local\Arduino15\packages\Seeeduino\hardware\nrf52\1.1.13\libraries\Adafruit_TinyUSB_Arduino``` with the directory of ```%appdata%\..\Local\Arduino15\packages\adafruit\hardware\nrf52\1.7.0\libraries\Adafruit_TinyUSB_Arduino``` or grab the library from [here](https://github.com/Adafruit/adafruit_tinyusb_arduino). Now you can run ```arduino-cli compile -b Seeeduino:nrf52:xiaonRF52840Sense --build-property "build.extra_flags=-DNRF52840_XXAA {build.flags.usb} -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64 -DCFG_TUD_VENDOR_TX_BUFSIZE=256" OpenPuck``` The same command as present in the build guide but with the FQDN replaced with your board. If it does throw an error, double-check that the Adafruit TinyUSB Library is not version 1.7.0 (and preferably should be 3.6.0 because that has been confirmed to work). Then you can follow the build instructions again, replacing that the board port and FQDN (and ensuring that the board is in DFU mode, double-pressing the RST button and that you can see the XIAO-SENSE drive in File Explorer). In my case, I ran ```arduino-cli upload -b Seeeduino:nrf52:xiaonRF52840Sense -p COM6 OpenPuck``` If everything works, you should see "device programmed", the XIAO-SENSE drive disappear, and the status LED on the board light up. Also I'd recommend making sure that the controller and puck firmware are up to date before attempting to pair the controller to the board, since that's what I did.

roman commented

2026-10-22 04:59:58 +00:00

Author

Owner

@safijari commented on GitHub (Jul 3, 2026):

I can possibly set up CI to start emitting UF2 files for this board.

Gotta figure out the pairing failed thing first though

@safijari commented on GitHub (Jul 3, 2026): I can possibly set up CI to start emitting UF2 files for this board. Gotta figure out the pairing failed thing first though

roman commented

2026-10-22 04:59:58 +00:00

Author

Owner

@4itor commented on GitHub (Jul 3, 2026):

Willing to test with a Xiao as well. (Currently with a supermini, but I like the formfactor, and case options for the Xiao way more).

I use xiaos as dongles for my keyboards (zmk) so I have several to try with.

Also XIAOs have a RGB user led. Ideal for setting the color of the current mode, i.e.

White -> Steam Controller
Green -> Xbox Controller
Red -> Nintento Switch
Blue -> PS Controller

A man can dream... :)

@4itor commented on GitHub (Jul 3, 2026): Willing to test with a Xiao as well. (Currently with a supermini, but I like the formfactor, and case options for the Xiao way more). I use xiaos as dongles for my keyboards (zmk) so I have several to try with. Also XIAOs have a RGB user led. Ideal for setting the color of the current mode, i.e. White -> Steam Controller Green -> Xbox Controller Red -> Nintento Switch Blue -> PS Controller A man can dream... :)

roman commented

2026-10-22 04:59:59 +00:00

Author

Owner

@t00fatt commented on GitHub (Jul 5, 2026):

@treblechet Thank you for confirming your process! I am doing the same but still getting the pairing failed 16 error. Rather than flashing the hex file with Arduino CLI, I am converting it a UF2 and installing via DFU drag and drop.

@t00fatt commented on GitHub (Jul 5, 2026): @treblechet Thank you for confirming your process! I am doing the same but still getting the pairing failed 16 error. Rather than flashing the hex file with Arduino CLI, I am converting it a UF2 and installing via DFU drag and drop.

roman commented

2026-10-22 05:00:00 +00:00

Author

Owner

@xamindar commented on GitHub (Jul 8, 2026):

I got some of these boards to use as well. By following the process from treblechet (adjusted for Linux), and verifying the Seeeduino package contains version 3.6.0, it does not work.

After flashing the board, the led just blips red every half a second, like maybe the board is in a boot loop. Nothing shows up in dmesg or usb devices when it is connected.

@xamindar commented on GitHub (Jul 8, 2026): I got some of these boards to use as well. By following the process from treblechet (adjusted for Linux), and verifying the Seeeduino package contains version 3.6.0, it does not work. After flashing the board, the led just blips red every half a second, like maybe the board is in a boot loop. Nothing shows up in dmesg or usb devices when it is connected.

roman commented

2026-10-22 05:00:01 +00:00

Author

Owner

@13jmb3 commented on GitHub (Jul 12, 2026):

The following instructions here are for Windows. Go through step three of the build guide, then:

The board package for the XIAO board needs to be added as per these instructions. However, you can install it using arduino-cli core install Seeeduino:nrf52 --additional-urls https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json

Verify that the board is properly recognized by running arduino-cli board list and that it doesn't just state "unknown."

Now, the "Adafruit TinyUSB Library" needs to be replaced with a newer version than 1.7.0, which, if you installed the Adafruit board package, is present on your computer.

Replace the directory of %appdata%\..\Local\Arduino15\packages\Seeeduino\hardware\nrf52\1.1.13\libraries\Adafruit_TinyUSB_Arduino with the directory of %appdata%\..\Local\Arduino15\packages\adafruit\hardware\nrf52\1.7.0\libraries\Adafruit_TinyUSB_Arduino or grab the library from here.

Now you can run arduino-cli compile -b Seeeduino:nrf52:xiaonRF52840Sense --build-property "build.extra_flags=-DNRF52840_XXAA {build.flags.usb} -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64 -DCFG_TUD_VENDOR_TX_BUFSIZE=256" OpenPuck The same command as present in the build guide but with the FQDN replaced with your board. If it does throw an error, double-check that the Adafruit TinyUSB Library is not version 1.7.0 (and preferably should be 3.6.0 because that has been confirmed to work).

Then you can follow the build instructions again, replacing that the board port and FQDN (and ensuring that the board is in DFU mode, double-pressing the RST button and that you can see the XIAO-SENSE drive in File Explorer).

In my case, I ran arduino-cli upload -b Seeeduino:nrf52:xiaonRF52840Sense -p COM6 OpenPuck

If everything works, you should see "device programmed", the XIAO-SENSE drive disappear, and the status LED on the board light up.

Also I'd recommend making sure that the controller and puck firmware are up to date before attempting to pair the controller to the board, since that's what I did.

Followed this process on my Fedora machine. Puck is recognized by steam but pairing fails.

@13jmb3 commented on GitHub (Jul 12, 2026): > The following instructions here are for Windows. Go through step three of the build guide, then: > > The board package for the XIAO board needs to be added as per [these instructions](https://wiki.seeedstudio.com/XIAO_BLE/). However, you can install it using `arduino-cli core install Seeeduino:nrf52 --additional-urls https://files.seeedstudio.com/arduino/package_seeeduino_boards_index.json` > > Verify that the board is properly recognized by running `arduino-cli board list` and that it doesn't just state "unknown." > > Now, the "Adafruit TinyUSB Library" needs to be replaced with a newer version than 1.7.0, which, if you installed the Adafruit board package, is present on your computer. > > Replace the directory of `%appdata%\..\Local\Arduino15\packages\Seeeduino\hardware\nrf52\1.1.13\libraries\Adafruit_TinyUSB_Arduino` with the directory of `%appdata%\..\Local\Arduino15\packages\adafruit\hardware\nrf52\1.7.0\libraries\Adafruit_TinyUSB_Arduino` or grab the library from [here](https://github.com/Adafruit/adafruit_tinyusb_arduino). > > Now you can run `arduino-cli compile -b Seeeduino:nrf52:xiaonRF52840Sense --build-property "build.extra_flags=-DNRF52840_XXAA {build.flags.usb} -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64 -DCFG_TUD_VENDOR_TX_BUFSIZE=256" OpenPuck` The same command as present in the build guide but with the FQDN replaced with your board. If it does throw an error, double-check that the Adafruit TinyUSB Library is not version 1.7.0 (and preferably should be 3.6.0 because that has been confirmed to work). > > Then you can follow the build instructions again, replacing that the board port and FQDN (and ensuring that the board is in DFU mode, double-pressing the RST button and that you can see the XIAO-SENSE drive in File Explorer). > > In my case, I ran `arduino-cli upload -b Seeeduino:nrf52:xiaonRF52840Sense -p COM6 OpenPuck` > > If everything works, you should see "device programmed", the XIAO-SENSE drive disappear, and the status LED on the board light up. > > Also I'd recommend making sure that the controller and puck firmware are up to date before attempting to pair the controller to the board, since that's what I did. Followed this process on my Fedora machine. Puck is recognized by steam but pairing fails.

roman commented

2026-10-22 05:00:01 +00:00

Author

Owner

@treblechet commented on GitHub (Jul 13, 2026):

I'll mention this, I'm not exactly sure what results in pairing failed but I am encountering it on my Macbook (don't have my Windows device readily available so I can't exactly narrow down if it's build-specific or if it's OS specific).

I have essentially two builds, one that I did earlier on a Windows device (which was where I made the above guide from) and a newer one that I made remotely from a Linux VM (build process on macOS is a mess due to Arm library incompatibilities) and then converted locally from a .hex to .uf2.

The older build allows pairing between the microcontroller and the controller, but for some reason the newer one does throw errors during pairing (on macOS, cannot currently confirm for Windows). Ended up using the v12, pairing, then flashing the most current version which worked.

Here are my two firmware files if y'all just wanna kludge it together to get it functional, use the v12 and then v17 (or build whatever's most recent, should work the same).

xiao_openpuck_v12.uf2.zip
xiao_openpuck_v17.uf2.zip

@treblechet commented on GitHub (Jul 13, 2026): I'll mention this, I'm not exactly sure what results in pairing failed but I am encountering it on my Macbook (don't have my Windows device readily available so I can't exactly narrow down if it's build-specific or if it's OS specific). I have essentially two builds, one that I did earlier on a Windows device (which was where I made the above guide from) and a newer one that I made remotely from a Linux VM (build process on macOS is a mess due to Arm library incompatibilities) and then converted locally from a .hex to .uf2. The older build allows pairing between the microcontroller and the controller, but for some reason the newer one does throw errors during pairing (on macOS, cannot currently confirm for Windows). Ended up using the v12, pairing, then flashing the most current version which worked. Here are my two firmware files if y'all just wanna kludge it together to get it functional, use the v12 and then v17 (or build whatever's most recent, should work the same). [xiao_openpuck_v12.uf2.zip](https://github.com/user-attachments/files/29981490/xiao_openpuck_v12.uf2.zip) [xiao_openpuck_v17.uf2.zip](https://github.com/user-attachments/files/29981491/xiao_openpuck_v17.uf2.zip)

roman commented

2026-10-22 05:00:03 +00:00

Author

Owner

@KabanFriends commented on GitHub (Jul 15, 2026):

Willing to test with a Xiao as well. (Currently with a supermini, but I like the formfactor, and case options for the Xiao way more).

I use xiaos as dongles for my keyboards (zmk) so I have several to try with.

Also XIAOs have a RGB user led. Ideal for setting the color of the current mode, i.e.

White -> Steam Controller Green -> Xbox Controller Red -> Nintento Switch Blue -> PS Controller

A man can dream... :)

I've lazily implemented this idea on my feat/xiao-mode-led branch with the help of Claude. I'm not sure if this is PR-worthy since XIAO nRF52840 isn't even officially supported device for this project at the moment.
@safijari If you think this is good enough for PR I can open it :)

@KabanFriends commented on GitHub (Jul 15, 2026): > Willing to test with a Xiao as well. (Currently with a supermini, but I like the formfactor, and case options for the Xiao way more). > > I use xiaos as dongles for my keyboards (zmk) so I have several to try with. > > Also XIAOs have a RGB user led. Ideal for setting the color of the current mode, i.e. > > White -> Steam Controller Green -> Xbox Controller Red -> Nintento Switch Blue -> PS Controller > > A man can dream... :) I've lazily implemented this idea on my [feat/xiao-mode-led](https://github.com/KabanFriends/openpuck/tree/feat/xiao-mode-led) branch with the help of Claude. I'm not sure if this is PR-worthy since XIAO nRF52840 isn't even officially supported device for this project at the moment. @safijari If you think this is good enough for PR I can open it :)

roman commented

2026-10-22 05:00:03 +00:00

Author

Owner

@xamindar commented on GitHub (Jul 15, 2026):

I would recommend you submit the PR. He can always just reject it if it is undesirable. I'm sure I am not the only one who would like to get the XIAO working.

@xamindar commented on GitHub (Jul 15, 2026): I would recommend you submit the PR. He can always just reject it if it is undesirable. I'm sure I am not the only one who would like to get the XIAO working.

roman commented

2026-10-22 05:00:04 +00:00

Author

Owner

@t00fatt commented on GitHub (Jul 17, 2026):

@treblechet Thank you for the images! Your v17 is working for me! V12 would give me a pairing failed (8) error.

When putting it into switch mode, it shows up in windows as a switch pro controller. But my switches do not respond to the puck in any mode.

@t00fatt commented on GitHub (Jul 17, 2026): @treblechet Thank you for the images! Your v17 is working for me! V12 would give me a pairing failed (8) error. When putting it into switch mode, it shows up in windows as a switch pro controller. But my switches do not respond to the puck in any mode.

roman commented

2026-10-22 05:00:05 +00:00

Author

Owner

@13jmb3 commented on GitHub (Jul 19, 2026):

I'll mention this, I'm not exactly sure what results in pairing failed but I am encountering it on my Macbook (don't have my Windows device readily available so I can't exactly narrow down if it's build-specific or if it's OS specific).

I have essentially two builds, one that I did earlier on a Windows device (which was where I made the above guide from) and a newer one that I made remotely from a Linux VM (build process on macOS is a mess due to Arm library incompatibilities) and then converted locally from a .hex to .uf2.

The older build allows pairing between the microcontroller and the controller, but for some reason the newer one does throw errors during pairing (on macOS, cannot currently confirm for Windows). Ended up using the v12, pairing, then flashing the most current version which worked.

Here are my two firmware files if y'all just wanna kludge it together to get it functional, use the v12 and then v17 (or build whatever's most recent, should work the same).

xiao_openpuck_v12.uf2.zip xiao_openpuck_v17.uf2.zip

Using treblechet's V12 for pairing and V17 Worked for me on Fedora. V12 alone would not pass along any inputs, and V17 alone would fail to pair (8).

@13jmb3 commented on GitHub (Jul 19, 2026): > I'll mention this, I'm not exactly sure what results in pairing failed but I am encountering it on my Macbook (don't have my Windows device readily available so I can't exactly narrow down if it's build-specific or if it's OS specific). > > I have essentially two builds, one that I did earlier on a Windows device (which was where I made the above guide from) and a newer one that I made remotely from a Linux VM (build process on macOS is a mess due to Arm library incompatibilities) and then converted locally from a .hex to .uf2. > > The older build allows pairing between the microcontroller and the controller, but for some reason the newer one does throw errors during pairing (on macOS, cannot currently confirm for Windows). Ended up using the v12, pairing, then flashing the most current version which worked. > > Here are my two firmware files if y'all just wanna kludge it together to get it functional, use the v12 and then v17 (or build whatever's most recent, should work the same). > > [xiao_openpuck_v12.uf2.zip](https://github.com/user-attachments/files/29981490/xiao_openpuck_v12.uf2.zip) [xiao_openpuck_v17.uf2.zip](https://github.com/user-attachments/files/29981491/xiao_openpuck_v17.uf2.zip) Using treblechet's V12 for pairing and V17 Worked for me on Fedora. V12 alone would not pass along any inputs, and V17 alone would fail to pair (8).

roman commented

2026-10-22 05:00:06 +00:00

Author

Owner

@NightHammer1000 commented on GitHub (Jul 24, 2026):

https://github.com/NightHammer1000/openpuck/tree/feat/xiao-nrf52840

Pairs with my Controller on Windows fine. Everything seems to work.

I also adapted @KabanFriends RGB Feature into it.

Fable and Opus did the most work here. Should be clean enough to Upstream.
Please test it and let me know if it pairs now for you guys. Then I can open a PR.

@NightHammer1000 commented on GitHub (Jul 24, 2026): https://github.com/NightHammer1000/openpuck/tree/feat/xiao-nrf52840 Pairs with my Controller on Windows fine. Everything seems to work. I also adapted @KabanFriends RGB Feature into it. Fable and Opus did the most work here. Should be clean enough to Upstream. Please test it and let me know if it pairs now for you guys. Then I can open a PR.

roman commented

2026-10-22 05:00:07 +00:00

Author

Owner

@safijari commented on GitHub (Jul 24, 2026):

@KabanFriends yes please

@safijari commented on GitHub (Jul 24, 2026): @KabanFriends yes please

roman commented

2026-10-22 05:00:08 +00:00

Author

Owner

@Jakkumn commented on GitHub (Aug 4, 2026):

Not sure if this is the right place to put this. I am using a makerdiary board (which is no-softdevice). I removed the build flag for including sd and then ran into a similar pairing issue (instead of 16, it was 8). Turns out, at least for nosd (and considering openpuck doesn't actually use it at all due to driving the radios directly) the adafruit internalfilesystem lib is the problem. It expects writeable memory at an offset that is being used as device app memory when compiled as nosd. So the device would attempt to write into the application stack and crash. Remapped that away, and I can safely say that I have the makerdiary working correctly. I am working on a PR that causes all devices to operate as if they are nosd. For sd boards, the sd blob can still exist to handoff to app start (that 0x1000 v 0x2000) but I think its possible to ignore the internalfilesystem lib for better compatibility across boards without having to flash between sd/nosd bootloaders.

@Jakkumn commented on GitHub (Aug 4, 2026): Not sure if this is the right place to put this. I am using a makerdiary board (which is no-softdevice). I removed the build flag for including sd and then ran into a similar pairing issue (instead of 16, it was 8). Turns out, at least for nosd (and considering openpuck doesn't actually use it at all due to driving the radios directly) the adafruit internalfilesystem lib is the problem. It expects writeable memory at an offset that is being used as device app memory when compiled as nosd. So the device would attempt to write into the application stack and crash. Remapped that away, and I can safely say that I have the makerdiary working correctly. I am working on a PR that causes all devices to operate as if they are nosd. For sd boards, the sd blob can still exist to handoff to app start (that 0x1000 v 0x2000) but I think its possible to ignore the internalfilesystem lib for better compatibility across boards without having to flash between sd/nosd bootloaders.

roman commented

2026-10-22 05:00:08 +00:00

Author

Owner

@Jakkumn commented on GitHub (Aug 4, 2026):

Here are the changes for the makerdiary board. https://github.com/safijari/openpuck/pull/217

@Jakkumn commented on GitHub (Aug 4, 2026): Here are the changes for the makerdiary board. https://github.com/safijari/openpuck/pull/217

roman commented

2026-10-22 05:00:09 +00:00

Author

Owner

@TheFilipcom4607 commented on GitHub (Aug 7, 2026):

XIAO nRF52840 Sense, current main, Windows, pairing worked first try. I think the flags in the guide above are the problem: it uses -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64, but current main bakes in CFG_TUD_HID=6 and CFG_TUD_TASK_QUEUE_SZ=512. Per the Makefile, 6 is needed because Steam mode exposes four puck slots plus one HID for mouse and one for WebUSB, and the deeper queue is there because the shallow one deadlocks the loop task under comms load → watchdog reset.

Since PROTOCOL.md notes SDL expects the Steam slot HIDs on USB interfaces 1–4, building with HID=4 on current firmware would plausibly shift the interface layout and break pairing while leaving WebUSB and enumeration fine, which is what everyone here is seeing. It would also explain @treblechet's v12-pairs-but-v17-doesn't: v12 predates the flag change.

Worth trying: rebuild with -DCFG_TUD_HID=6 -DCFG_TUD_TASK_QUEUE_SZ=512 -DCFG_TUD_VENDOR_TX_BUFSIZE=256 (or just make build after adjusting the FQBN, the Makefile has the current values). I also used TinyUSB 3.7.0 rather than 3.6.0; 3.7.5+ won't compile (usbd_edpt_xfer gained an is_isr param), so 3.7.0–3.7.4.

@TheFilipcom4607 commented on GitHub (Aug 7, 2026): XIAO nRF52840 Sense, current main, Windows, pairing worked first try. I think the flags in the guide above are the problem: it uses -DCFG_TUD_HID=4 -DCFG_TUD_TASK_QUEUE_SZ=64, but current main bakes in CFG_TUD_HID=6 and CFG_TUD_TASK_QUEUE_SZ=512. Per the Makefile, 6 is needed because Steam mode exposes four puck slots plus one HID for mouse and one for WebUSB, and the deeper queue is there because the shallow one deadlocks the loop task under comms load → watchdog reset. Since PROTOCOL.md notes SDL expects the Steam slot HIDs on USB interfaces 1–4, building with HID=4 on current firmware would plausibly shift the interface layout and break pairing while leaving WebUSB and enumeration fine, which is what everyone here is seeing. It would also explain @treblechet's v12-pairs-but-v17-doesn't: v12 predates the flag change. Worth trying: rebuild with -DCFG_TUD_HID=6 -DCFG_TUD_TASK_QUEUE_SZ=512 -DCFG_TUD_VENDOR_TX_BUFSIZE=256 (or just make build after adjusting the FQBN, the Makefile has the current values). I also used TinyUSB 3.7.0 rather than 3.6.0; 3.7.5+ won't compile (usbd_edpt_xfer gained an is_isr param), so 3.7.0–3.7.4.

roman referenced this issue

2026-10-22 05:06:58 +00:00

[PR #39] [CLOSED] Enhanced lizard, ds4/5 gyro fix, qam button remap #167

Rows
Columns

[GH-ISSUE #88] Pairing Failed (16) on Seeed XIAO nrf52840 #39