Ghosts causing progmode?

[rueckix]

Folks, on stm32, I am observing something rather strange and I was wondering if anybody has ever come across that.
Hours, sometimes days into the operation, progmode turns on without user interaction. I am using this board [https://docs.platformio.org/en/latest/boards/ststm32/blackpill_f401ce.html] with the builtin_led as progled and user key as progbutton.

None of my code is touching this LED or the button. I already replaced the board, suspecting a hardware issue.

[jeff25]

Same in my Site on samd21 . My.feeling is that this is related to progbutton and rhe debouncing

[rueckix]

Um... strange. Ok, I am not alone with this. Makes me feel better. I think you might be right.

Let's assume something is causing that edge event, i.e., button-up. I reckon bad board design... without proper hardware debounce.

Now, the below code indeed only prevents that a single button press is detected as more than one. Sort of a cool-down time of 200ms.

knx/src/knx_facade.cpp

Line 21 in 4f6c837

if (millis() - lastpressed > 200){

The code does not require a button press to be sufficiently (=humanly) long. If we get a single event upset pulling the pin down for a few millis, we would indeed see progmode toggle. With the current interrupt logic we cannot detect this reliably.

Options...
a) handle on-CHANGE interrupts
b) do away with interrupts altogether
c) reset progmode periodically

Thoughts?

[madon]

There is no 'strong' pull-up on most boards. This means that the input impedance is rather high and makes it sensitive to interferences. This has nothing to do with debauncing. Debaucing would prevent the event to trigger more than once on a single button press. To get rid of this the best approach would be adding a stronger Pull-up and maybe a small capacitor to the input. To work around this in Software you could ignore short pulses. Not using interrupts will only reduce the frequency the issue occurs, but not the source of the problem. Marc Am 10. Mai 2022 21:05:43 schrieb rueckix ***@***.***>:

…

Um... strange. Ok, I am not alone with this. Makes me feel better. I think you might be right. Let's assume something is causing that edge event, i.e., button-up. I reckon bad board design... without proper hardware debounce. Now, the below code indeed only prevents that a single button press is detected as more than one. Sort of a cool-down time of 200ms. https://github.com/thelsing/knx/blob/4f6c837b78603dbdfc67c192d116ce9c78be4f57/src/knx_facade.cpp#L21 The code does not require a button press to be sufficiently (=humanly) long. If we get a single upset event pulling the pin down for a few millis, we would indeed see progmode toggle. With the current interrupt logic we cannot detect this reliably. Options... a) handle on-CHANGE interrupts b) do away with interrupts altogether c) reset progmode periodically Thoughts? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[rueckix]

Right, that's what I meant when suggesting detect a reasonably long button press. The problem is the current interrupt logic in the code. It just triggers on RISING. To ignore short pulses, we need to determine their length.

I was wondering if there is a preference in this community for either of the proposed options. If using interrupts, we need to handle state and timestamps across interrupts. Alternatively, the entire logic is implemented without interrupts. Third option is to accept the fact and periodically reset the progmode.

[jeff25]

oh sorry you are right, debouncing is only in case you press the key, in your case should be the pull up resistor.

[thelsing]

The software should check if the button was pressed long enough IMO.