New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard not responding after flashing firmware #558

berti opened this Issue Feb 5, 2019 · 2 comments


None yet
3 participants
Copy link

berti commented Feb 5, 2019

Today I tried to update the firmware on my Model 01 for the first time using macOS Mojave to the latest master from GitHub (no customizations). I followed these instructions (both command-line and Arduino IDE), but after the firmware is uploaded (with no apparent errors) the keyboard does not respond anymore.

This is the output of make flash:

BOARD_HARDWARE_PATH="/Users/salmeron/Documents/Arduino/hardware" /Users/salmeron/Documents/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope/bin//kaleidoscope-builder flash
Building output/Model01-Firmware/Model01-Firmware (0.0.0-gv1.22-51-gf272) ...
- Size: firmware/Model01-Firmware/Model01-Firmware-0.0.0-gv1.22-51-gf272.elf
  - Program:   24982 bytes (87.1% Full)
  - Data:       1416 bytes (55.3% Full)

To update your keyboard's firmware, hold down the 'Prog' key on your keyboard,
and then press 'Enter'.

When the 'Prog' key glows red, you can release it.

Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

After pressing PROG and Enter, the keys in the left half of the keyboard start flashing red in sequence, a bit faster each time. It does four “passes”, and on the fourth it stops on the “X”, which is lit red for a couple of seconds before the keyboard goes completely dark. After that there’s no additional output in the command line and “make flash” simply terminates.

The keyboard does not register any input as far as I know, e.g. the “LED” key does nothing. Also the “LED” key does not light up blue after reconnecting the keyboard, which it used to do, but a few random keys across both halves light up with random colors. There seem to be no errors about the keyboard in dmesg or /var/log/system.log, neither when flashing or connecting the keyboard.

I tried flashing the previous version, and also version 0.3.3+44 default from Chrysalis, but neither worked.

Flashing the default firmware that shipped with the keyboard made it work again.

This was originally reported on the Keyboardio forums:

@algernon algernon added the bug label Feb 5, 2019


This comment has been minimized.

Copy link

obra commented Feb 5, 2019

algernon added a commit that referenced this issue Feb 6, 2019

Repurpose EEPROMSettings' version
We want to be able to notice when the layout of the EEPROM *settings*
changed (which the CRC does not cover). For this reason, we're repurposing the
existing version setting, which wasn't widely used: it is now internal.

We use the version to determine whether the EEPROM has been written to yet, or
if it is uninitialized. This helps us make sure we're starting up with sensible

Fixes #559, and fixes #558.

Signed-off-by: Gergely Nagy <>

This comment has been minimized.

Copy link

algernon commented Feb 6, 2019

For the curious, the issue here is that while I made sure that the setting that controls whether we use only custom (EEPROM) layers or not is safely updated, in a manner that is compatible with uninitialized EEPROM, the initial reading of the same setting did not get that treatment. As such, it defaulted to "on", which meant the firmware started using the EEPROM keymap only, without fallback to the built-in layers. Since EEPROM is all 0xff bytes when uninitialized, every key was transparent, and did nothing.

The workaround is to use Chrysalis to disable the setting, but I have a PR coming up that fixes the problem on the firmware side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment