blue_wizard compatibility broken

[wizarddata]

Describe the bug
Compiling and flashing the blue_wizard keyboard firmware causes the keyboard to continually connect to & disconnect from PC.
Board continues to broadcast between disconnect/connect. No errors are produced during compiling.

To Reproduce
Steps to reproduce the behavior:
Working with PR228. Also works with PR185, PR214.

Not working with PR229. Also not working with PR186.

Expected behavior
Expected behavior is for the keyboard to successfully broadcast, connect to the PC, and send keycodes.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Ubuntu
• Browser Chrome
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context

Keyboard uses nrf52832 MCU.

During compiling, arduino IDE reports 35% program space and 54% dynamic memory used.

Matrix on this keyboard is 15x7. This large size caused memory issues unless MAX_NO_LAYERS is reduced to 5.

It was also discovered that TG(Layer) only seems to function on layers 0 and 1. This may or may not be related.

[wizarddata]

I believe I've narrowed it down to between PR228 and PR229. I'm going to verify this in the morning.

[wizarddata]

I've been able to much better describe the behavior this morning with fresh eyes.

[jpconstantineau]

If the issue is related to connecting/disconnecting continuously, can you "forget" from your computer and try connecting again? This will make the two re-negociate the pairing keys.

[wizarddata]

Yes, I've been doing a forget and re-pairing as part of my process for testing each pull request in case that was the issue. Just did that again to confirm.

[jpconstantineau]

One last thing: Does it still happen if you reformat the nrf52 file system. Run this sketch:

and re-flash the firmware.
This will wipe out any keys and settings saved to file on the nrf52 as well.

[wizarddata]

After running the pictured sketch and reflashing firmware built with PR229, the connection resets the same way.

[jpconstantineau]

Ok. What about with 228? I doubt that the changes brought by 229 will impact much, perhaps except for memory usage.

[wizarddata]

After the format, with pr228 the connection is persistent and the keyboard functions correctly.

It is possible that the device is resetting when the connection is lost and I'm misinterpreting the boadcasting as being continuous because the device is booting quickly. I'm using the nRFConnect app on my phone and the dispaly only refreshes about once a second.

[jpconstantineau]

That's good. let's see... Let's try this commit: ee8c80a
It's skips ahead a few commits I did to add a workflow on github actions and troubleshoot it.
I expect that one to work the same... Let me know...

[wizarddata]

That commit does work correctly. Stepping to the next in line, f012b88
brings back the disconnection behavior.

[wizarddata]

I've also flashed my board with the default 'Ergotravel' configuration. That produced the same results.

[jpconstantineau]

Ergotravel too? I wonder about the luddite or the 4x4Macropad. I have been looking too much at the 840 these days... I have a 832 macropad I have been using and that one is ok. I'll give a try to a few 832 boards I have around.

[jpconstantineau]

I assume you tried the one in between: 6f21844

[wizarddata]

My apologies, I'm jumping between the git software I use and the github web interface and I grabbed the wrong pr. The one you linked is the PR that brings about the problems.

[jpconstantineau]

6f has issues? and the one before didnt.