Holly firmware
Just a recap since there is a lot of chatter above. Testing the Holly macropad. Holly firmware builds fine, flashes, then device is unresponsive. Tried building on mac and windows, same result. Tried flashing the erase firmware first, same result. Flashing the CI nightly build works fine. Build environment is qmk master branch with the holly project in keyboards folder.
16 Replies
Hey, sorry. I am impressed you have one in hand already! We were planning on “launching” it as a Black Friday promotion. Welcome to the party 🕶️
As you have learned docs aren’t up yet! That’s my bad. So the nightly build works, correct?
Do you NEED to change the low power firmware, or you’re just playing around?
The regular firmware does something naughty. It embeds the low power firmware in and jumps to it if it detects it’s on battery. So if the position has changed, or the low power firmware isn’t booting, it’ll hang on boot like you describe.
I’ve been planning a write up in the getting started guide, but haven’t pushed it yet.
1. Nightly build works!
2. Don't need to build the low power firmware, only did it to see if it would fix anything and to know that it works.
What I'm looking to do is build the regular qmk firmware and be able to deploy it.
- Local building works with `qmk compile -kb nullbitsco/holly -km all
- Flashing appears to work, seems the same as the CI built, then device is off/unresponsive.
- Going into bootloader mode after unresponsive still works
Bootloader mode seems super nifty. Different light patters depending on which key you press when turning it on.
Took me a bit to figure out how everything worked with no documentation 🙂
Unrelated: later if you update the VIA keymap from scramble, maybe add the lighting controls in? The scramble doesn't have light controls. But adding them into your VIA json does work, like RGB_TOG or RGB_MOD.
I am impressed you figured all this out without docs. And again, I apologize! Early adopter pains 🙃
So you can load the .json file that’s contained in the VIA folder of QMK into VIA as a draft definition, and it includes lighting controls!
As for this “bootloader” mode — if the lights are flashing, it sounds like it’s actually booting into the low power mode firmware, which should only happen if the battery is in and the switch to the left. Is it happening always?
Here are the flashing steps I do
1. Plug device in holding switch 1
2. Shows up as a usb drive
3. Drag custom built firmware over
4. Usb device gone
5. No lights on device, no key recognized
6. Unplug, flip switch to low power mode, no light
7. Plug back in to usb, no lights, no key recognized
Repeat with CI built and after step 4 the lights are on solid, keys are recognized.
Tried that and it worked great. I saw that file in there and wondered what it was for.
Logs from building here, but nothing that probably helps: https://pastebin.com/460pSEh0
Thanks! Got it. Ok, sounds like it’s not booting as I was thinking earlier. but I’m unclear why. even if the low power mode firmware and the corresponding offset is wrong, the QMK base should boot OK.
Do you have a working tree on GitHub or somewhere with your changes? Or can you take a diff of your Holly folder and send it along?
Easiest way for me to provide input/help you get it fixed (and ensure that it won’t bite anyone in the future!) would be to reproduce the same thing on my side.
Here is the commit: https://github.com/pcm2a/qmk_firmware/commit/978b1253321bccab7f92215ef8358ed8efb5240f, branch https://github.com/pcm2a/qmk_firmware/compare/nullbits_holly. To test on your end I assume you could pull down that branch, build, and deploy. I just updated master to the latest from upstream so everything should be the latest. I tried deploying again in case being a week out of date made a difference.
Awesome! Thank you. This has been super helpful — I’ll take a look at it tonight and make sure I can reproduce the problem.
Apologies the third time for not having any documentation up yet — you’re a trooper.
No problem. With anything qmk related there seems to be involved a lot of sleuthing involved. Part of the fun. Try getting openrgb working...
Fingers crossed that it is reproducible! I did try building it on both mac and windows, so hopefully.
Alright, so my first try...it worked. I cloned your exact branch. I compiled it on Ubuntu, though and not Mac. I'll try my Mac next.
FWIW. Load and see but I'm guessing this works on yours as well.
Aha! I was able to reproduce it with the Mac build. Sweet. Give me a bit of time to dig in and see what’s happening.
Sorry for the slow reply, busy morning. I set up the build environment on a ubuntu machine. It builds and works for me. Only environment untried now is win 11 + WSL. I'll give that a shot today too. My previous win 11 test was not inside WSL but with qmk msys. Since my WSL is ubuntu maybe it will work there also.
This is unrelated, and just my inexperience with VIA. When I flash shouldn't it wipe out changes made by VIA? If I update the key bindings in VIA, then I flash things get weird. Either the VIA keymap is still in place, or nothing works at all. Then I have to flash the eraser firmware, then things can get back to normal.
That might be exactly how things are supposed to work once you make any changes with VIA.
Using QMK toolbox I believe it erases the flash then programs the flash. That might be why I haven't encountered this before.
Afternoon update, tested on WSL and it does work from building there. I used the QMK WSL environment.
Ubuntu - works
Ubuntu WSL (Win 11) - works
Mac - doesn't work
Win 11 QMK MSYS - doesn't work
Got it. Thank you! I’m glad you’re able to get something working from Ubuntu. I think there is a compiler different causing some problems between Ubuntu and MSYS/Macos. I’m still looking into what the heck might be going on.
Sounds good, I'm around to test out any fixes you might come up with.
Any updates on the build issues? Thanks!
It’s still on my list…Haven’t had time to mess with it. I’d recommend building with Ubuntu or WSL for the time being.
Roger that, thanks for the update.