You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that some (multiple random) hardware in the fields suffers from weird factory resets without somebody pressing the button (it is physical not possible that someone could reach the button). I've noticed that it only happens with hardware that supports GPIO IRQs and which uses gpio-button-hotplug.
Problem seems to be that:
CPU registers a really short 1 on the GPIO line
IRQ is triggered
gpio-button-hotplug handles the IRQ and noticed that the GPIO line is 0
gpio-button-hotplug thinks that this was a button release after a really long button press
factory reset is triggered by /etc/rc.button/reset
It looks like this can be fixed by checking if the button was actually pressed before calculating the holding time and sending the userspace event.
But there is a possible second problem caused by the missing debounce. The (incorrect) 1 on the GPIO line could be there long enough that the interrupt handler registers a press then directly receives a button release. This would trigger a REBOOT (even when not wanted). This (maybe) can be fixed by using a 5ms timer until accepting a key press.
The text was updated successfully, but these errors were encountered:
Eventhough I have added 60 (ms) debounce-interval in the device tree, still my device reboots with a small pulse width of 8us, could you please help to fix the problem.
this should be fixed by: [[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=afc056d7dc833bbd714386007db1bfcf48188954|gpio-button-hotplug: support interrupt properties]] and the following patches. Which have also been ported to openwrt-19.07.
charlemagnelasse:
I've noticed that some (multiple random) hardware in the fields suffers from weird factory resets without somebody pressing the button (it is physical not possible that someone could reach the button). I've noticed that it only happens with hardware that supports GPIO IRQs and which uses gpio-button-hotplug.
Problem seems to be that:
It looks like this can be fixed by checking if the button was actually pressed before calculating the holding time and sending the userspace event.
But there is a possible second problem caused by the missing debounce. The (incorrect) 1 on the GPIO line could be there long enough that the interrupt handler registers a press then directly receives a button release. This would trigger a REBOOT (even when not wanted). This (maybe) can be fixed by using a 5ms timer until accepting a key press.
The text was updated successfully, but these errors were encountered: