Yeah, it’s a known issue. And an annoying one.
Simon wanted new firmware, so he sent me some drivers to use for development. Nanjg 105d drivers, specifically. I got things working, even though the drivers had particularly bad 7135 chips, and I sent Simon a proof of concept to test. I wanted to find out if he liked it, if he noticed any issues, etc. It wasn’t really finished, but it was far enough to ask for feedback.
I guess there was a misunderstanding, because he then sent that version to production. :person_facepalming:
Not long afterward, I found a bug which occurred on an infrequent random basis, causing the issue described in this thread. It didn’t sample enough bits of SRAM, so some drivers would fail. On some hardware it never happens, on other hardware it happens almost every time, based on random luck. And I fixed it. But that was too late, because Simon had already made a lot of drivers.
Making all this worse, production used different driver hardware. And different fuse values so it ran at the wrong clock speed. And the production hardware seems to have a lot of variation between individual circuit boards, which messes with the button timing. And MCU pin 5 is connected to ground, which makes reflashing difficult.
So… a lot of things went wrong. And now, a year and a half later, it’s still biting people.
Some of it can be fixed by reflashing, but that’s not something people can really be expected to do. Some of it may be fixable by changing or removing components from the driver. But, again, not something people shold have to deal with.
If you do reflash it though, gchart’s Babka has more features. It’s worth a look.