Ctrl and OS keys swapped in Ergodox EZ

[kyren]

Edit: See this comment, if you're having this issue: https://github.com/qmk/qmk_firmware/issues/6589#issuecomment-524042457

• Drashna

Issue

Hey, when building and flashing 1c805b3d008a98a5a15112b0655ba14b42dbae67 for an ergodox ez my OS and CTRL keys are swapped. I tried macos and linux and observed the same behavior.

If I swap to commit 6a79b05cf02d5a6f07b17474344e272b44c77988 (right before PR #6110) the problem goes away

System Information

• Keyboard: ergodox ez
  • Revision (if applicable):
• Operating system: macos and linux (nixos)
• AVR GCC version: avr-gcc (GCC) 7.4.0
• ARM GCC version: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]
• QMK Firmware version: 1c805b3d008a98a5a15112b0655ba14b42dbae67
• Any keyboard related software installed?
  • [ ] AutoHotKey
  • [ ] Karabiner
  • [ ] Other:

Additional Context

Firmware is built using the toolchain from shell.nix

[drashna]

Resetting the EEPROM will fix the issue.

[kyren]

Oh, okay that makes sense. Sorry if this is a basic question but I can't quite figure out how to reset the eeprom on an ergodox without changing my firmware to give it the ability to do that from a keypress? I'm using the QMK toolbox GUI and there's a "reset eeprom" button but it doesn't appear to do anything. Is there a way to do this from cli using dfu-util?

[kyren]

I tried to use the method you mentioned here: https://github.com/zsa/wally/issues/7 to reset the eeprom, but after doing this the issue is still there, so I'm not sure if I was successful?

[drashna]

Edit:

Ways to reset the eeprom:

• Update your repo and reflash.
• ~If Bootmagic is enabled, Space + Backspace when plugging it in will wipe EEPROM~
• ~If Bootmagic Lite is enabled, the bootmagic key when plugging it in will wipe eeprom and reset to bootloader. Reflash or unplug and plug back in~
• ~If Command is enabled, Command keys (Both Shifts usually) plus backspace will wipe EEPROM~
• ~Add the EEP_RST (or EEPROM Reset in the configurator) to your keymap and hit that. You may need to unplug and plug back in the keyboard, though.~
• ~Use the QMK Toolbox to wipe the eeprom, put into bootloader first, and hit the Reset EEPROM button.~
• ~Save this file as a hex file, and flash it, then flash your normal firmware.~
• ~Add eeconfig_disable() to the keyboard_pre_init_user, or matrix_init_user function, flash the board, remove `eeconfig_init(). and reflash it~
• ~Flash the board with :dfu-split-left or :avrdude-split-left, as this will also wipe the eeprom~

If you are using VIA, there is a collision right now. To fix that add the following to your config.h file:

#undef EEPROM_MAGIC_ADDR
#define EEPROM_MAGIC_ADDR 34
#undef EEPROM_VERSION_ADDR
#define EEPROM_VERSION_ADDR 36
#undef RGB_BACKLIGHT_CONFIG_EEPROM_ADDR
#define RGB_BACKLIGHT_CONFIG_EEPROM_ADDR 37
#undef DYNAMIC_KEYMAP_EEPROM_ADDR 
#define DYNAMIC_KEYMAP_EEPROM_ADDR 68
#undef DYNAMIC_KEYMAP_MACRO_EEPROM_ADDR 
#define DYNAMIC_KEYMAP_MACRO_EEPROM_ADDR 668

If that does not work, then revert d534c72a544454132b3c6c05af85c821f6a93d65

[drashna]

Try this hex: https://drive.google.com/open?id=1jHLYA1gwx_umdJxiySzDz9d-K9XFjh4a

[kyren]

Yep, flashing that hex did the trick, thank you so much!

Should I close this issue or let #6590 close it?

[drashna]

Let the PR close it.

And actually, I'm going to pin this for now.

[drashna]

Specifically, the reason that this has happened is that a new block is being used for the EEPROM. Unfortunately, because it's a block that wasn't used previously, it has not been zeroed out properly, so it has a random value.

This means that the Ctrl-GUI swap may be enabled, because the bit used for it was on, randomly.

We are looking at both short term and long term solutions for this issue, so that this doesn't happen again, in the future.

[wilba]

thanks for the heads up @drashna

🙄

[drashna]

@Wilba6582 sorry about the collision!

[bcat]

Had the same issue on a Via-supporting board (Instant60) and the config.h workaround above fixes it. For now I've added this to my personal config.h in my userspace, but should I also send a pull request to fix this in the keyboard's config.h instead? Or is someone doing a batch update of all the Via boards?

[wilba]

@bcat I will update the VIA keyboards

[drashna]

Actually, keeping this open, for those that are using VIA.

[ilpsxnus]

As a Windows only user I was unable to reset the EEPROM through the QMK Toolbox or by activating the mapped "EEPROM Reset" key combo on my keyboard. It's probably not overwriting the specific memory address which holds the swap value. What worked was assigning "MAGIC_UNSWAP_LCTL_LGUI" to a key then activating it, but this needs to be done each time the keyboard is plugged in.

[yanfali]

There's a bug in the way toolbox erase's eeprom with atmel-dfu right now, it needs dfu-programmer atmega32u4 erase before running the erase eeprom command.

[orbitingorca]

Seeing this issue on zeal60. My hacky fix was to comment out code in quantum/keycode_config.c.

[drashna]

@orbitingorca that's because there is a collision. The block that the CTRL GUI swap is in is using the same block that VIA uses. If you add the block I've posted above into your personal keymap's config.h, it will fix the issue without disturbing anything else.

[Pimentoso]

Issue was happening with my Pro Micro based keyboard (redox rev1) Solved the issue with

cd qmk_firmware
git pull
make clean
make git-submodule

and then reflashing my keymap with make redox/rev1:xxxxx:avrdude

[stanrc85]

My ESC key no longer works on the first layer, seems to have just started since this issue came up and was resolved. No matter what keycode I try the ESC key doesn't work on the default layer, if I switch layers then it works fine.

[drashna]

@stanrc85 that's really odd. And from what you describe, I'm not sure that it's related to this issue (but it's hard to tell).

I can't reproduce your issue, locally. Are you using grave escape?

[stanrc85]

I usually have a custom tap dance there, but also tried with grave escape (shift+esc, gui+esc didn't work either), regular escape and even a KC_1 just to test. Just as reminder its a HS60/v2 board since that usually seems to make a difference.

I didn't know if it might be related to EEPROM stuff moving around since I only noticed it around the same time.

[stanrc85]

@Wilba6582 is this still being worked on to fix the via boards?

[drashna]

This should be fixed now. Closing.

[makenova]

I ran into this issue, left Ctrl and the left OS key were swapped, but I am using an instant60. My local repo was a bit stale but even after rebasing upstream, the issue persisted. Trying to reset the EEPROM with QMK Toolbox didn't work. I eventually mapped "reset eeprom" to a layer and that worked. I don't want to reopen this issue, I've resolved it for myself. I'm simply adding this in case someone else runs into this issue or if the repo owners want more info to fix this.

[arialdomartini]

This happened to me today on DZ-60, out of the blue.

• MT(MOD_LCTL, KC_D) and MT(MOD_RCTL, KC_K) just acted as KC_D and KC_K (MT being ignored)
• MT(MOD_LGUI, ... behaved as MT(MOD_LCTL, ...

I confirm that the following fixed the problem:

• assign QK_CLEAR_EEPROM to a random key
• flash the firmware
• press the key programmed with QK_CLEAR_EEPROM: this re-initializes the keyboard's EEPROM (persistent memory)
• flash back the original desired keymap

That worked for me. 🥳