Skip to content

Recovery

This page is a cookbook: find the symptom, then follow the recipe. Every recipe states its safety level and whether it has been tested on hardware (by us, by the owner of the boards we measured, by a third party) or not at all, with the firmware it was tested on. The thing to know first: most "dead" halves are not dead. A half parked in its bootloader, halves on different firmware, and a broken link between the halves all look alike to a user, and each has a different, mostly low-risk cure. The list of commands never to send is on Troubleshooting.

You can damage a half. Read the safety notes first.

Recipes marked HIGH write firmware, wipe data or drop Bluetooth bonds. Make first attempts on a donor board. Recipes marked UNTESTED have never been run on hardware by anyone we know of.

How to read a recipe

Safety levels:

  • SAFE: read-only.
  • LOW: nothing stored changes, or the change is fully reversible.
  • MEDIUM: writes stored configuration, recoverable from a backup.
  • HIGH: writes firmware, wipes data or drops bonds; can brick a half or lose data.

Tested markers: TESTED (us) with firmware and date, meaning measured on the owner's boards; TESTED (third party), meaning reported by someone else and not repeated by us; UNTESTED.

Recipe Symptom Safety Tested
R1 half dark, not typing, bootloader PID LOW TESTED (us), 3.35.4 and 3.41.0
R2 bootloader PID only, "primary image not valid" HIGH UNTESTED
R3 peripheral dark but typing, empty replies HIGH TESTED (us), 3.35.4 and 3.41.0
R4 right half's keys never arrive SAFE (diagnosis), HIGH (repair) TESTED (us), 3.35.4
R5 white, amber or dim after a flash MEDIUM TESTED (us), 3.35.4 and 3.41.0
R6 whole board dark, typing works LOW to MEDIUM our steps TESTED (us) one by one, 3.41.0; the ceiling re-send TESTED (third party)
R7 right half and its module dark after LED writes MEDIUM hazard TESTED (third party); fixes UNTESTED
R8 3.28.7 half frozen after a write LOW TESTED (us), 3.28.7
R9 module not recognized, no light LOW TESTED (us), 3.28.7 with modules on 2.1.2
R10 every key stopped after a write LOW TESTED (us), 3.41.0
R11 frozen after the wireless-output key LOW TESTED (us), 3.41.0
R12 stuck on an upper layer LOW TESTED (us), 3.41.0
R13 reads answer 16 00 MEDIUM meaning TESTED (us); restore TESTED (third party) only
R14 NayaFlow "Failed to verify written data" LOW to MEDIUM TESTED (us), 3.41.0
R15 computers forgotten after an update LOW vendor documentation
R16 module will not charge LOW vendor documentation

First checks

Read-only; do these before any recipe

Safety SAFE. TESTED (us) on every firmware we have.

Before any recipe MEASURED:

  1. Quit NayaFlow and any other tool. One program per port: on Windows a held port gives "Access is denied", and a killed script's Python process can still hold it.
  2. Read fe/1002 (firmware version) on each half's own port, and on the left port at dst 0x51: a half can silently miss an update (Versions).
  3. Look for a half at a bootloader PID (0x006F left, 0x00D3 right), twice, 3 s apart (Bootloader).

Then, for a dark half: a bootloader PID on the second look is R1 or R2; different firmware versions are R3; a right half whose keyscan events arrive but whose keys do not reach the computer is R4; lighting that is only wrong is R5, R6 or R7.

R1 Half dark and not typing, shows up as a bootloader device

Safety LOW. TESTED (us) on 3.35.4 and 3.41.0, 2026-09-16 to 2026-09-22.

It sends one SMP reset; nothing stored changes.

The half shows no lights and does not type. It enumerates as 0x006F (left) or 0x00D3 (right) with two serial ports, and it is still there on a second look 3 s later MEASURED.

  1. Find the port that answers SMP os echo (the other port only logs).
  2. Send SMP os reset (group 0, id 5, version-1 header) to that port. The half returns to its application in about 8 s; a transport error on the reset means it worked.
  3. If it does not come back, re-send every 30 s; right after an upload, allow minutes.
  4. A power cycle also works when the primary image is valid.

Frames and details: Bootloader.

The first SMP answer after entering the bootloader can take a minute: in the logged flash runs it came 60.8 to 69.0 s after entry on the left half and 24.4 to 26.1 s on the right (once only 3.8 s), while OpenFlow re-probed about every 2 s, without any idle period (owner's board, 2026-09-20 and 2026-09-22) MEASURED. Part of that wait was the host's: OpenFlow then reopened the answering port for every request and never read the half's second (log) port. Holding both ports open for the whole visit and reading the log port, as NayaCore does, cut identifying the running image from 63 s to 26 s in a module update (owner's board, left half, 3.41.0, 2026-09-23) MEASURED (open question).

R2 Bootloader device only, primary image not valid (untested)

Safety HIGH. UNTESTED: nobody we know of has done this on a Create.

It writes firmware to a half that already fails to boot. Make the first attempt on a donor half.

The half enumerates only as a bootloader device, and its log port says "Image in the primary slot is not valid". MCUboot's standard answer is to put a good image in the secondary slot and let it swap in INFERRED[^mcuboot]:

  1. Record the console output first.
  2. Identify side and generation from the PID (Bootloader).
  3. Read image state. Stop if the PID and the slot hashes disagree on side or generation.
  4. Upload the matching stock resource, whole, to image: 2 (never 0 or 1).
  5. Send os reset and wait minutes (swap and decrypt), re-sending as needed.

A swap onto an already-invalid primary has never been tried on this hardware. OpenFlow's planner currently refuses a half whose running image it cannot identify, so it would need a PID-only path first. The scenario comes from a third party's report of a half stuck in its bootloader, which we do not cite REPORTED (open question).

R3 Halves on different firmware

Safety HIGH (the fix writes firmware). TESTED (us): halves put on different firmware and matched again, 3.35.4 and 3.41.0, 2026-09-20 to 2026-09-22.

Both halves type, but the peripheral's LEDs are dark, and the peripheral's own port answers the handshake and then returns empty payloads. Its version stays readable through the central's port at dst 0x51: the left port read the right half's version 3.35.4 while the right's own port was hollow MEASURED2. Bluetooth identity reads sent to 0x51 on the left port answer for the left half, not the right (Transport). OpenFlow has no automatic retry through that route. NayaFlow refuses its pairing flow ("Devices have different firmware versions").

Fix: flash both halves to the same version, the central (left) first (Flashing). Everything recovers once they match.

R4 Right half scans but its keys never arrive

Diagnosis.

Safety SAFE (reads only). TESTED (us), 2026-09-20.

Turn on keyscan on the right half (fe/1008): if events arrive, the right half is alive. Then compare, on both halves, the own address (be/1008), the pair address (be/1002) and the bond table (be/1005). Healthy is mutual: each half's pair address is the other half's own address. The measured failure: the right half held a bond to the left, but the left's bond table held one host address twice and no bond to the right MEASURED (owner's board, 2026-09-20; addresses not published). See Split link.

Clearing Bluetooth bonds on the computer does not fix this. The link between the halves lives in each half's own pair address and bond table, and the 2026-09-20 repair needed commands to the halves only MEASURED INFERRED.

Repair.

Safety HIGH: drops every Bluetooth host bond. TESTED once by hand (us), 3.35.4, 2026-09-20; the owner reports a repair on 3.41.0 as well. No tool has automated it on hardware.

Put both halves on the same firmware first (R3). Save both halves' own and pair addresses before sending anything.

In NayaCore's pairing order MEASURED STATIC3:

  1. be/1001 SET_PAIR_ADDRESS on each half, with the other half's own address;
  2. wait 300 ms;
  3. be/1010 CLEAR_ALL_SPLIT_LINKS on each half;
  4. be/1004 UNPAIR_ALL on each half;
  5. wait 1 000 ms and wait for the peer;
  6. ee/10ce NORMAL_RESET (on 2026-09-20 it was sent to the left half);
  7. check that the pair addresses are mutual.

The result was a clean mutual bond and both halves typing. UNPAIR_ALL also drops every host bond, so pair the computers again afterwards. The power cycle used that night to leave the bootloader was unnecessary: os reset on the port that answers SMP does it (R1). The repair sequence ends with a reset command (ee/10ce NORMAL_RESET); on 2026-09-20 a power cycle was also done afterwards. Whether the reset alone is enough is untested; a test on the donor board settles it.

NayaCore refuses its own pairing operation with "Pairing failed: missing device(s) (left=%1, right=%2)" or "Devices have different firmware versions". Its sibling ClearBLEDevices operation runs CheckBLEFWVersion, WaitForPairAddress, StorePairedHalfAddressBeforeClear, ClearConnections, VerifyConnectionsCleared, Respawn, RecheckBLEStatus, WaitForBLEStatus and VerifyBLEFWVersion. The rule that matters: store the partner's address before clearing anything STATIC3.

The vendor's guidance on pairing the halves: power the left half on before the right, and "make sure your two halves are paired together using the device manager" DOC4.

R5 Lights wrong after a flash or a bootloader pass

Safety MEDIUM: a layer-list write. TESTED (us and the owner): 2026-09-10 after a runtime effect; 2026-09-20 and 2026-09-22 after flashes (3.35.4 and 3.41.0).

Write back only the bytes you just read from the same board, and only to the left half. Other layer ids would replace the layer identities.

A half comes back from a flash or any bootloader pass white, a darker amber, or dim, while its stored LED maps are byte-identical MEASURED:

  1. Read the layer list with 30/1001 on the left half.
  2. Write the same entries back with 30/1002 (wire params 00 00 followed by the entries). Both halves return to their stored lighting in one frame, and nothing stored changes.
  3. If the board is dim, re-send the maximum brightness: ed/1013 with value 100, params 00 00 64.

A runtime LED effect (ed/1011) survives layer, LED-map and module writes; only a layer-list rewrite or a power cycle clears it MEASURED (owner's board, 2026-09-10). Layer list format: Layers.

R6 Board dark but typing

Safety LOW to MEDIUM (settings writes). Each step TESTED (us) on its own, 3.41.0; re-sending the ceiling to a board dark for weeks TESTED (third party: the nayactl PR #6 author, 3.41.0).

The keys stay dark while both halves type. Work through these steps in order MEASURED INFERRED:

  1. Check fe/1002 on both halves: a firmware mismatch darkens the peripheral (R3).
  2. Re-send the brightness ceiling ed/1013 with value 100, params 00 00 64. The ceiling scales the whole key array and is stored: on the owner's board a ceiling of 30 dimmed every key and 100 restored them (3.41.0, 2026-09-13) MEASURED. A stored ceiling of 0 would therefore be a board that stays dark across reboots INFERRED, which is what the nayactl PR #6 author reports REPORTED6. Module LEDs are outside the ceiling, per the same author REPORTED.
  3. Rewrite the layer list as in R5; it clears runtime LED effects.

If the keys stay dark. Scan mode is not a likely cause: switching ed/1012 off and on changed only a flicker that shows on camera MEASURED (owner's board, 3.41.0, 2026-09-13), so a zeroed scan mode should not darken the keys INFERRED. A cold boot (Resets and power) clears runtime lighting states but cannot clear a stored ceiling INFERRED. Nothing beyond these steps has been tested by us, and 30/10ca, which wipes the stored configuration, is on the never-send list. This differs from naya-create-kb, whose dark-board recipe goes on to that wipe (with params 01, where NayaCore sends 00 00) and a snapshot restore1.

R7 Right half dark after LED commands sent to it

Safety MEDIUM. The hazard is TESTED (third party), 3.41.0; the suggested fixes are UNTESTED by anyone.

One third-party run of a nine-write LED recovery sequence sent to the right half's own port (dst 0x51), including RESUME (ed/1010) and an RGB override (ed/1050), left the right half's LEDs and its docked module dark while it still typed; eight of the nine writes were acknowledged (3.41.0, 2026-09-22), and whether a stock NayaFlow flash relit it was left unconfirmed REPORTED1. Which write did it is unknown. A single ceiling write (ed/1013 00 00 64) to the right half's own port was acknowledged and did not park it (owner's board, 3.35.4 and 3.41.0, 2026-09-20 and 2026-09-22) MEASURED. Commands sent to the left half do reach the right half's lighting: one layer-list rewrite on the left restores both halves (R5) MEASURED.

Why the left port can relight the right: the central (left) drives both halves' LEDs from its own 136-entry map over the split link INFERRED (from measured bay blocks and the layer-list restore of both halves, 2026-09-08 to 2026-09-10).

The right half is not deaf by design: on its own port it answers the handshake (fe/1001, fe/1002) and system, Bluetooth, module and fa/1001 reads MEASURED, and it acknowledges the ceiling write above. What it lacks is the configuration stores: keymap, LED maps, layer list and module configurations are all on the left (Flash layout).

Untested candidates for a right half parked this way, least invasive first INFERRED: the R5 layer-list rewrite sent to the left half, which restores both halves' stored lighting; the ceiling re-sent to the right half's own port (ed/1013 00 00 64), which relit a dim right half after a flash; and the keyboard's own LED keys, which are firmware &rgb_ug records and need no host. In the stock profile they sit on the System layer (Layer 2, held at position 73), mostly on the right half: positions 9 to 12 select effects, 24 and 40 raise and lower brightness, 25 and 41 change speed, and 39 turns the LEDs on and off MEASURED (NayaFlow's stock profile read back, 2026-09-08).

R8 A 3.28.7 half stops answering after a write

Safety LOW (unplug and replug). TESTED (us), 3.28.7, 2026-09-19.

Right after a keymap or LED write, a 3.28.7 half stops answering and typing while its LEDs keep the old map. The write needed three CDC frames (byte 3 counting 02 01 00), which 3.28.7 cannot receive. Unplug and replug the half: no damage (it came back at 4.21 V). From then on, split large writes on record boundaries into writes of at most two frames, each starting 00 <layer> again (at most 482 record bytes per write) MEASURED. 3.41.0 takes NayaFlow's own three-frame writes, and single 30/100e frames of up to 253 bytes were accepted on 3.41.0 (owner's boards, 2026-09-16 and 2026-09-21) MEASURED. The nayactl PR #6 author reports that 30/100e writes of 241 and of 41 bytes wedged the parser until a power cycle (3.41.0) REPORTED6; since 253-byte frames were accepted, that is a different limit, not defined by size INFERRED.

R9 Module dead

Safety LOW (a key press). TESTED (us), 3.28.7 with modules on 2.1.2, 2026-09-19; untested on 3.41.0.

A module is not recognized when docked and shows no light. Measured on 3.28.7 with modules on 2.1.2: hours of charging did not help, and the module recovery key did (a Tune and a Touch came back) MEASURED DOC. Press the key (System layer LA5, record type 06 with parameter 401) on the half whose bay holds the module. It puts that half's LEDs out and disables the module while active, times out by itself (repeat when it does), and a restart ends it. The vendor's cure for this firmware pair was a later firmware plus Force Module Update. Details: Module firmware.

R10 Every key stopped after a keymap write

Safety LOW (after the fact). TESTED (us), 3.41.0, 2026-09-03.

A hold-tap flavor value of 4 was accepted and stored and stopped every key; rewriting the record did not help; unplugging the board (a power cycle) did, and nothing on flash was damaged. Rewrite the record with a flavor of 0 to 3 MEASURED. See Settings and timing.

R11 Keyboard frozen after switching output to wireless

Safety LOW (a power cycle). TESTED (us), 3.41.0, 2026-09-10 and 2026-09-11.

On battery, pressing the wireless-output key with no reachable wireless host froze the keyboard: nothing typed and layer switching stopped. A power cycle recovers. Pressing the USB-output key after selecting a Bluetooth device with no host also made the board look crashed (its USB ports stayed up); a power cycle cleared it MEASURED.

R12 Stuck on an upper layer

Safety LOW (a power cycle). TESTED (us), 3.41.0.

A toggle-layer binding to layer 0 (&tog 0) pressed from a higher layer strands the board there until a power cycle. NayaFlow does not allow that binding MEASURED.

R13 Reads answer 16 00

Safety MEDIUM (the restore writes the keymap). Meaning TESTED (us, 3.28.7; third party, 3.41.0); the restore after a format TESTED (third party) only.

30/1001 or 30/1003 answering 16 00: status 0x16 means nothing is stored for that read. Right after 30/10ca that is expected; restore from the snapshot as described on Factory reset MEASURED REPORTED.

R14 NayaFlow says "Failed to verify written data"

Safety LOW to MEDIUM. TESTED (us), 3.41.0, 2026-09-09 and 2026-09-17.

Known causes: second-bank records that NayaFlow's profile does not describe, a tapping term other than 200, and a NayaFlow flash right after 30/10ca. None affects typing. Fixes and details: Factory reset MEASURED.

R15 Bluetooth hosts forgotten after an update

Safety LOW. From the vendor's documentation; not reproduced by us.

Updating from Bluetooth v1 firmware (3.31.1 or older) to v2 (3.35.4 or newer) erases the saved hosts, and the link between the halves fails until both halves are on v2. Update both halves and pair the computers again DOC8 (Versions).

R16 Module will not charge

Safety LOW. From the vendor's manuals.

Check the cable and the computer, and seat the module flat. If it stays unresponsive, use the manual's Recovery Mode keybinding (R9). Undock modules for long storage (battery protection), and charge from a computer, not a wall outlet DOC54.

Resets and power

Reset commands MEASURED STATIC:

  • ee/10ce NORMAL_RESET reboots the half through its bootloader. Its port drops at once (a transport error after 7.7 ms on 3.35.4, 2026-09-20); on 3.41.0 the bootloader identity (0x006F) showed 0.65 to 0.84 s after the command for about 1.3 s, and the application was back after about 3 s (owner's board, left half, 2026-09-23) MEASURED (closed question). On Windows 11 the half came back by itself only after the first two restarts in a row; from the third it stayed off USB until its cable was replugged MEASURED (open question).
  • ee/10ae MCU_BOOT_RESET parks the half in its bootloader until os reset (R1).
  • ee/10be DFU_RESET has never been observed by anyone we know of; do not send it.

Power cycles and the power switch. Every power-on passes through the bootloader for 1 to 1.7 s, and powering one half reboots the other when the link comes back, so a one-half power cycle is a two-half reboot MEASURED. With USB plugged in, switching a half OFF shuts it off, and switching it back ON works as a reset (owner, 2026-09-23) MEASURED. That agrees with the manual, which says the Create respects the ON/OFF state even while connected over USB DOC4. So the switch is a usable reset for one half without unplugging. Safety SAFE. TESTED (owner, 2026-09-23).

A cold boot removes every power source: USB out, modules undocked (a docked module can power the keyboard) and both switches off MEASURED DOC.

Action What it does Evidence
os reset (SMP, data port) leaves the bootloader; about 8 s to the application MEASURED
ee/10ce NORMAL_RESET reboots the half through its bootloader (about 1.3 s); its port drops at once and the application is back in about 3 s MEASURED
ee/10ae MCU_BOOT_RESET parks the half in its bootloader until os reset MEASURED
ee/10be DFU_RESET unknown; never observed STATIC
Unplug and replug USB (battery half) reboots through the bootloader (1 to 1.7 s) and reboots the other half at re-link MEASURED
Power switch OFF then ON, USB plugged in shuts the half off, then resets it MEASURED DOC
Cold boot removes every power source MEASURED DOC

Brightness 0 and the brightness keys

ed/1008 with level 0 leaves the keys dark, and the next ed/1008 with a level above 0 relights them: a two-byte write (params 00 00 64) restored a half that a one-byte write had set to 0 MEASURED (owner's board, left half, 3.41.0, 2026-09-09). The stock brightness keys are firmware records (&rgb_ug with its brightness up and down commands and argument 0), so the firmware computes each step and the host puts no step value on the wire; NayaCore's 15 ZMQ events include no LED command, and none of our NayaFlow captures contains an ED frame MEASURED STATIC. How the keys behave at either end of the range has not been measured.

The vendor's own recovery tools

Clear BLE Devices and Test and Format SPI Flash (NayaCore 6.4.0; NayaFlow beta 1.18.0 and stable 1.19.1), module recovery for "battery Zero" (NayaFlow 1.3.8), Force Module Update (1.15.0) and a one-click diagnostics report (1.21.0) DOC79. What the flash test does: Flash layout.

A firmware flash does not fix a stored-state problem, because the stores survive flashes, and NayaFlow's "Test and Format SPI Flash" does nothing on a healthy flash: it formats only the partitions that fail its self-test MEASURED STATIC. Its Danger Zone button "Clear all keymap data" (clear_data) does wipe the stored configuration: it sends 30/10ca itself, with no confirmation dialog STATIC3 (Factory reset). This differs from naya-create-kb, which says nothing in the stock interface formats the data partition1.

"My right half stopped working"

A half that does not power on or enumerate and a pair that is no longer bonded look the same to a user, and NayaFlow has no per-half diagnosis for it (NayaCore carries Japanese-only "one half connected" warnings that are not wired in) STATIC INFERRED3. Use the first checks and the R4 diagnosis to tell them apart.

Tested and untested

Done on the owner's hardware (status 2026-09-23): R1; R3 (different firmware, then matched); R4 (3.35.4, and 3.41.0 per the owner); R5 (restoring layers and lighting after a flash); R6's steps, each on its own; R8; R9; R10; R11; the power switch as a reset on USB; ee/10ce through the bootloader. R12, the meaning of 16 in R13, and R14 are measured too. Not done: R2; the 30/10ca restore (R13); and the other recipes that wait for a donor board. R15 and R16 are vendor documentation only MEASURED.

Open questions

  • OPEN R2 on real hardware: a swap onto an invalid primary (details).
  • OPEN Whether anything but re-sending the ceiling clears a board left dark by a stored ceiling of 0 (the R5 layer-list rewrite, a cold boot), and what relights a right half parked as in R7 (details).
  • OPEN Why a half stays off USB from the third ee/10ce restart in a row until its cable is replugged (details).
  • OPEN What ee/10be DFU_RESET does (details).
  • OPEN Recovery-mode behavior on 3.41.0 with modules on 2.3.3 (details).
  • OPEN Whether the reset command alone completes the pairing repair (on 2026-09-20 a power cycle was also done afterwards); a donor-board test settles it (details).
  • OPEN What wedged the parser in the nayactl PR #6 author's 30/100e writes of 241 and 41 bytes, given that single frames up to 253 bytes are accepted on 3.41.0 (details).

Sources

  1. naya-create-kb, recovery. ↩↩↩

  2. create-legacy-firmware, FLASHING-PROCEDURE.md, "Measured on hardware, both halves (2026-09-20)". ↩

  3. NayaFlow 1.25.1, NayaCore 6.11.0 strings (pairing and ClearBLEDevices steps and messages, the flash repair and ClearAllData steps, ZMQ events, "one half connected" warnings) and NayaFlow's Danger Zone texts. ↩↩↩↩

  4. Naya Create User Manual v1.1.0, pp. 4, 5, 11 and 25; see Manuals. ↩↩↩

  5. Naya Touch, Tune and Track User Manuals v1.1.0, pp. 5 and 7; see Manuals. ↩

  6. nayactl, pull request #6, description by its author. ↩↩

  7. create-legacy-firmware, CHANGELOG.md (vendor release notes). ↩

  8. create-legacy-firmware, CHANGELOG.md L222. ↩

  9. Vendor release notes of the beta channel, NayaTech/NayaFlow-beta-releases, v1.18.0. ↩