Keyboard sends '=====' after turning on and after flushing firmware

[yanshay]

I have the keyboard for a few weeks now. I face several issues that seem to be related to the same 'family' of issues:

1. When I turn it on connected to a Mac it sends many '=' signs at the autorepeat speed (or actually whatever key is at key position 0). It sometimes stop after a while but sometimes it doesn't and I need to press a key to stop it.
2. On a Windos PC this happens after the first keypress on the keyboard.
3. Many times on the first key press on the right keyboard the first press is followed by a '=' sign
4. When flushing firmware, after flushing I get a very fast long set of '=' signs (much faster than the autorepeat speed)

After this initial sequence all works normally until next time I turn off/on the keyboard.

I tried this with the vanilla firmware after building as well as other versions of firmware.

Also, it wasn't always like that, the flushing scenario started a few days after I started using the keyboard, and the turn on scenario started only a few days ago.

Is this normal? Anyone experiencing this as well? Any fix/workaround?

[ReFil]

firmware.zip
Please try this firmware and let me know if it helps

[yanshay]

Issue doesn't happen with this firmware, what's the difference? Where can I find the config to build it to move to it?

BTW - I noticed there are firmwares built that have a certain size and others (built using other zmk repos) that are smaller. This one is of the smaller sizes. What's the difference between those firmwares ?as the file sizes are meaningfully different) around 20-25% difference in the file size.

Also interesting, after going back to my firmware, the behavior is different. Now on my Mac when I turn on the keyboard on bluetooth it doesn't generate the autorepeat of equal signs, it only adds a single extra character on the first keypress. Is there any kind of state on the keyboard that gets preserved across firmware updates that can be cleaned?

[ReFil]

The changes in #114 should solve this issue, once the checks pass it can be merged, and then if you run "sync fork" on github it should bring these changes into your branch

[yanshay]

I made the changes manually to my config and it solved all issues above and seems to have solved other firmware flushing issues I did not describe. Thanks!

Out of curiosity, can you explain how that change had this effect? Are Kinesis pedals going through the keyboard in the first place?

Do you plan to merge it also to your advantage360 branch to later be merged into zmk and other projects that use that branch?

[ReFil]

This is a change to the board definition, it should not apply to the underlying branch. It just adds back some keys for the type C footpedals kinesis sells for the advantage 360 pro. With the problem solved i'm going to close out this issue now, thanks for letting me know it solved your issue :)

[yanshay]

As part of this change you modified adv360.dtsi which is one of the files you added in PR zmkfirmware/zmk#1454
as app/boards/arm/adv360pro/adv360pro.dtsi. So it needs to be updated there, Isn't that the case?
I believe urob repo for example relies on that board configuration and once zmk merge it, that would be the file people directly using zmk will use.

[ReFil]

Apologies, you're correct, this change will be added there as well. I thought you were referring to the base repo that has the custom lighting features