Keyboard not responding after flashing firmware

[berti]

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: https://community.keyboard.io/t/keyboard-not-responding-after-flashing-firmware/2493/8

[obra]

What I suspect you're seeing is an issue with the newish support for EEPROM-based configuration. We're on it. ᐧ

…

On Tue, Feb 5, 2019 at 3:37 AM Alberto Salmerón Moreno < ***@***.***> wrote: Today I tried to update the firmware on my Model 01 for the first time using macOS Mojave to the latest master from GitHub <keyboardio/Model01-Firmware@f2729e5> (no customizations). I followed these instructions </~https://github.com/keyboardio/Model01-Firmware> (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 </~https://github.com/keyboardio/Chrysalis>, but neither worked. Flashing the default firmware <https://raw.githubusercontent.com/keyboardio/Model01-Firmware-Builds/master/v1.22-MP2-BUILD/atmega32u4_firmware.hex> that shipped with the keyboard made it work again. This was originally reported on the Keyboardio forums: https://community.keyboard.io/t/keyboard-not-responding-after-flashing-firmware/2493/8 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#558>, or mute the thread </~https://github.com/notifications/unsubscribe-auth/AACxaPZk5Yodu50lvgdjQl8CO1CJEqQyks5vKWz2gaJpZM4ajCAD> .

[algernon]

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.