Corne right half not changing firmware
Hi everyone!
I build my firmware using the zmk-project on github as instructed on the support page. Before this, I used zmk-studio as far as I could.
I have no issues with the build-process itself, but when I flash the firmware with changed keymap the right half of my corne does not update. Instead it keeps the old keymap. The left changes as it should. I checked the filehashes of the firmware-files of the right half and they differ when I do changes.
Can someone point me into a direction? I suspect it fails flashing and reverts to the last working firmware (if such feature exists), but how could I troubleshoot this?
Here is my corne.keymap - the rest of the configuration is unchanged...
15 Replies
It sounds like you're having trouble flashing the right half of your Corne.
First, ensure you're entering the bootloader by double-tapping the reset button on the right half before flashing. You should see a
NICENANO drive appear.
If that doesn't work, try a different USB cable or device. You can also try manually shorting the RST and GND pins on the nice!nano with tweezers to enter the bootloader. See our Entering Bootloader guide for more info.
If the issue persists, it could be a problem with the right half's nice!nano. You can try re-flashing the bootloader using the guide from Nice Keyboards linked in the bootloader guide.
Let me know if you need further assistance!Entering the Bootloader | Typeractive.xyz Documentation
Learn how to enter the bootloader on your nice!nano.
Getting into bootloader is not an issue. The flashing process happens as usual when I copy the new firmware file. But afterwards the keymap of the right side does not change.
with zmk-studio, you still see your zmk-studio changes right? Iirc you will need to restore it back to stock settings
(option here incase you never found it, cause it took me 5-10 mins to remember where it was myself just now)
Thank you, with this tip I was at least able to flash the right half again. Am I correct in thinking, that I have to choose then between zmk-studio and the direct method, or was this just a bug?
I mentally have filed it away as "works as intended" as ZMK Studio is a higher level above my firmware.
My firmware has all the fancy tap-dance/tap-whatever definitions.
Then the firmware keymap is there as a default
then zmk studio can add another custom keymap on top.
So it stands to reason (in my head) - updating the firmware directly changes my devicetree definitions, and changes the default keymap.. and then the active keymap is whatever i've applied via zmk studio.
I haven't tested this out yet, but I think it'd be one of those things where I can be tweaking a setup in studio, go "ah heck, want to change the duration on a modifier" and fix that in firmware, reflash that and not worry that all my current studio keymap testing is thrown out - if that works, that's actually a super nice workflow.
(or if you want to look at it slightly differently - it's like how reflashing doesn't break all your bluetooth pairing setups. if reflashing would reset everything to zero, that would be so annoying)
Thank you, it is a bit confusing, that the keymaps may interfere with eachother but I guess also understandable.
I feel like i am again missing something. After wiping I configured everything as required again. I am german so I set LBKT on a key to write ü. For some reason the right half sends this as SHIFT+LBKT, which is Ü.
On another layer on the right half LBKT is configured again and there it sends just LBKT.....
I opened the keyboard with zmkstudio and it shows the same configuration for both keys
Nevermind, i just found it. In zmkstudio the LSHIFT modifier was somehow selected on that key.....
i'm just playing around with it now - i hit that with err.. { i think
Is
on my keymap i have LBRK and LBRC (testing something) and in studio they both superficially look the same as
{ but one is with shift, and one is without
I think i got esp confused because i was expecting the display to be [Yeah thats where my mistake began...
I find it a bit hard to juggle zmkstudio and firmware - can I somehow solely rely on the firmware? Then I only have one place to look for errors 🙂
i'm doing both - my aim is to use studio because it's fast, and hopefully any issues i have force me to learn and hopefully things bug me enough and i figure it out so i can contrib back cause the potential of studio is so awesome
I agree it is. For me only parameters and custom behaviours are missing. Then I could depend solely on studio.
it's definetly sped up some of my testing today - just being able to experiment with the two things was a win.
(hold tap to get to a mod layer and hold tap for alternate keys - wrote the two behavious up and have been testing how it feels on different keys and with different destinations in studio)