Switch actions can lead to a reset loop

[Thomas Arthofer]

Not sure what exactly is causing this, but sometimes short/light switch taps put it into a reset loop as seen here: https://youtu.be/z4fk0mKlS8I

Click combos stop working until power is removed.

2nd video where it happens here: https://youtu.be/W-rEuqEievQ?t=107
It starts with the reset loop state and at 1:47 I manage to get another reset loop.

[Thomas Arthofer (arthofer-thomas)]

Managed to reproduce it on my testbench with a scope connected. https://i.imgur.com/dqbykIJ.png

1) It was pretty interesting contact bounce.
2) Pushing reset doesn't help (even pushing for >10s)
3) Only power cycling helps
3) Resets happen each ~1.2s (WDT resets?)
4) No clear way to reproduce, but it seems like a bouncing button helps

I'm trying a workaround where the WDT is the first thing to be deactivated on boot as this seems to be a common cause for reset loops on AVR. (as noted here: http://ww1.microchip.com/downloads/en/AppNotes/doc2551.pdf )

[Thomas Arthofer (arthofer-thomas)]

Played around a bit with the workaround flashed.

I managed to get the BLF Q8 into a state where a button press brought it into the Poweron-Reset mode we discussed in another feature request.

I think that confims that a noisy button creates a WDT reset and that the WDT timer need to be cleared on boot.

ToDo:
1) Search further why switch actions can cause a lockup
2) Disable WDT on boot by addint WDT_off() right after cli() in main()

[Selene ToyKeeper (toykeeper)]

Any idea which version of the firmware was installed? I mean, which branch and revision?

Also, I wonder if it could be waiting so long for the switch to settle that it could trigger another WDT tick before the previous one was finished. It sounds like the boot-time change could probably stop it from looping, but I'd like to fix whatever started the loop first.

[Thomas Arthofer (arthofer-thomas)]

I agree on needing to fix it instead of just using a workaround.

In general, disabling the WD on boot seems to be best practice for AVR.

 I was always using the fsm branch.

Other than that, it seems like the bug was "always there" since around when the D4S was released and I started flashing Anduril on most of my lights.

The other problem is reliably reproducing the bug.

[Selene ToyKeeper (toykeeper)]

I was mostly wondering if it still happens after the recent event system rewrite. But it sounds like it probably does still happen, because it's likely more related to the WDT and sleep ticks, and less related to how logical events are handled.

If my guess is right, it probably only happens in builds where sleep ticks are enabled. And it's not the only bug related to sleep ticks; it also has issues detecting button presses if the timing lines up exactly with one of those ticks.

Anyway, it'd be helpful to know if it happens post event-system-rewrite, and if it happens with sleep ticks disabled. But I've only ever seen it happen once, so I don't have a good way to test whether the bug is still there or not.

[Thomas Arthofer (arthofer-thomas)]

Yes, it still happens with the event system rewrite.

The sleep ticks are a possibility because I've only seen it on lights that have that enabled (D4S, Q8, Skilhunt H03, Astrolux S43) and not on those without it (D4)

I'll try to reproduce it with sleep ticks disabled, but sadly I also don't have a proper way to reproduce it yet.

[Selene ToyKeeper (toykeeper)]

I haven't seen this happen in at least six months, and haven't heard any reports about it either. I think it may be fixed, but it's hard to say for sure since it was really rare and hard to reproduce even when it was definitely still an issue.