@Zambumon mentioned creating a QMK-specific thread here, so here that is!
Have any questions about QMK in general, or need help with something? Here’s the place to ask that’ll remain in keebserity!
Some relevant links:
I’m sure this has been asked repeatedly in the past, but I had an eeprom question.
Usually during the rare times I have to help people with the QMK configurator and their layout, a common issue I’ve found is:
“Huey I don’t understand, I flashed my hex file with the qmk toolbox but for some reason my caps/ctr and alt keys are getting messed up. It doesn’t make sense!”
Every single time this has happened I’ve recommended them to reset their eeprom on the toolbox and reflash and it has always worked. My question is:
When you flash a new layout, why doesn’t the toolbox simply always reset the eeprom?
One of the answers I’ve received was that the eeprom can be rewrote a limited amount of times. When I asked, I believe the answer was over 1000 times. I know some people change their key map often, but 1000 times seems quite a bit. 3 times a day would bring you pretty close to a year. Of course maybe the figure of 1000 I received is wrong, I just wanted some clarification on this.
Are there any other factors that need to be considered when resetting the eeprom?
ALSO,
Why isn’t KC_TRNS default in config.qmk? Hehe.
3 Likes
also why isnt stuck modifiers enabled by default, and would that solve the following issue:
Using W in a game to walk forward, use a function feature, stop walking until you let go and rehit W
thats a sad shortfall 
1 Like
Shouldn’t this be a “QMK” sub-category with each different question being a new thread instead of a thread where every single QMK question will be mixed with replies, etc?
3 Likes
You have a good point; but I think this thread is just an overall discussion about QMK. If people have particular questions, issues, or comments about specific QMK stuff they can make a new thread in the
“Learning and discussion > Firmware, programming, and hardware compatibility” Category and add an extra QMK Tag under “Optional Tags”
3 Likes
The limited cycle of writes (I think it’s much higher than 1000 for AVR) is what I would cite here as well, but I’m also of the mindset that I don’t want something erasing my EEPROM settings (or any setting in general) without being explicitly told to do so. I think having an option to reset it while flashing (and even guidelines on when you should) would be nice to have though 
We’re trying to imagine what versions of the EEPROM space looks like, and that should make problems you’re referring to much less likely! Basically your keyboard should be able to tell if the EEPROM settings that it’s reading match the version of QMK that it’s running, and if it doesn’t, perform an action that migrates it to the newest version without losing your settings.
We use KC_NO because it’s much easier to imagine/explain that “this key does nothing” than “well, you see there are layers in the keymap, and if there’s a keycode below it, and if that keycode isn’t also KC_TRNS, then that’s the keycode that gets sent” - very much open to other ideas on this!
2 Likes
There’s been some discussion about this in the issues, but I’m not sure we had enough feedback from people to go either way - I’m not opposed to it, after all, it can be turned on/off either way I’m interested in ideas on how to handle issues like this as well - are polls of everyone a good way to get an answer for this, or should it be limited to contributors, collaborators, etc?
This feature specifically (and others) will be coming to the configurator sooner rather than later!
Also, EEPROM is used for other settings, such as the default layer. I’d be annoyed if I had to re-set the board to COLEMAK every time I flashed the board (SUPER OFTEN).
There is a “Reset EEPROM” button on the QMK Toolbox, though.
But maybe there should be a checkbox too?
There is an open PR to default to this behavior, actually.
1 Like
I haven’t run into this issue before, but I usually plan my layers around what I need to use it for. if I’m gaming, I’ll remap keys in the game to what the base layer is.
What is happening for you when you experience that? (do you have layers for gaming menus or abilities, etc?)
40% boards for instance, don’t have a number row, or even a function key row. You’d need to use a layer to get to them.
Meaning that you lose out on a lot of keys, because of the board you’re using. Layers fixes that issue, but can cause problems.
I guess that’s true. Right now, I’m mostly playing FPS’s and using my 60, but everything I need the numrow for, I can get with a scroll wheel on my mouse.
Once you get into RTS and MMO’s though, I can see how that might be an issue. For me though, that would just mean a keyboard change or a dedicated gamepad with whatever keysets necessary mapped to different static layers.
1 Like
F keys in a MMO on a 60% is a great example heh
also QMK is the only firmware afaik that has this issue and it makes me sad 
that’s unfortunate. I don’t know what a solution for that would be software-wise. 
Sometimes my Alt key register gets stuck when I go from Fn3 layer to default one.
Is something wrong with my keymap? It is on my github but I cant include links in my posts.
Or I need to reset EEPROM every time I flash new keymap?
When I got my Zephyr I had to reset EEPROM. It was ignoring all keymap changes !
You Alt key getting stuck may be a result of not having a proper KC_Trans where you are using it or with what you are using it with.
I think if you add it where appropriate you’ll be fine.
I don’t think you need to reset your EEPROM everytime you flash a new keymap. I’ve only had to do it once per board whenever I’ve had an odd hiccup.
Also you should be able to post links once you hit trust level 2 I believe.
If you’re compiling from source, add #define PREVENT_STUCK_MODIFIERS to your config.h, and that may fix your issue.
Hello,
I have a little problem with the ProMicro.
I just finished the build, the keymap is working as intended but the leds are not working at all.
I config:
- D1: for backlit led => the leds just blink non-stop, even if I press BL_TOGG
- D0: num lock => I press the Num Lock key, the led on the other keyboard turned on but on this board, it does not.
- D4: caps lock => same as numlock.
my wiring is: D0 ---- resistor ---- +Led- — GND
the leds are ok, I can confirm this. I shorted the Led+ and VCC and it shone brightly.
I config everything with http://kbfirmware.com, except the D1 for backlit, as it does not appear on the drop down list, I have to download the source code and change then build manually.
anyone know what I could have done wrong?
Don’t use kbfirmware. If its in the QMK repo, use https://config.qmk.fm.
Also, you want to use led_set_user to set this: QMK Firmware
But I’m not 100% sure that the kbfirmware version of QMK supports it, since it’s a year and a half out of date… (which is why I said don’t use it).
1 Like
oh, I don’t know that it’s outdated.
thank you, I will check the “new” link 
Has anyone figured out a way to use Tap Dancing for layer switching. Like hit once for layer 1, twice for layer 2, etc. ? I found my attempts at this to be problematic.