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
With Zephyr 1.13 I ran into a similar issue as described in #8252, which was actually fixed in #8815. After a certain point I was unable to receive interrupts on a pin but could confirm with an logic analyzer that the state had changed. Similar to last time the issue was only seen when PWM was used as well. As a workaround, I switched to the hardware based nrfx pwm driver which solved the problem (or at least it is hidden now). I suspect that the rewriting of the nrfx-based gpio shim in combination with the old pwm_sw driver reintroduced overwriting of GPIOTE channels.
pfalcon
changed the title
Possible regression of #8815
Possible regression of #8815 ("Nordic: Directly accessing GPIOTE might create unstable firmware"...)
Sep 17, 2018
With Zephyr 1.13 I ran into a similar issue as described in #8252, which was actually fixed in #8815. After a certain point I was unable to receive interrupts on a pin but could confirm with an logic analyzer that the state had changed. Similar to last time the issue was only seen when PWM was used as well. As a workaround, I switched to the hardware based nrfx pwm driver which solved the problem (or at least it is hidden now). I suspect that the rewriting of the nrfx-based gpio shim in combination with the old pwm_sw driver reintroduced overwriting of GPIOTE channels.
cc: @cvinayak
The text was updated successfully, but these errors were encountered: