nrf/modules/machine: Catch exceptions from pin interrupts #13368
Conversation
|
Code size report: |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #13368 +/- ##
=======================================
Coverage 98.39% 98.39%
=======================================
Files 161 161
Lines 21078 21078
=======================================
Hits 20739 20739
Misses 339 339 ☔ View full report in Codecov by Sentry. |
|
Side note: The reason I didn’t see the problem of getting stuck after printing the first character on the nRF52840, as @tb4450 points out in #13520, is that the 840 uses USB CDC for stdout, which is a different code path. I have now confirmed that the problem does occur on the nRF52840 when writing to a hardware UART, and is also fixed by this commit. |
It destroys a few manual alignments, but these seem minor compared to the benefit of automated code style consistency. Signed-off-by: Christian Walther <cwalther@gmx.ch>
Exceptions in pin interrupt handlers would end up crashing MicroPython with a "FATAL: uncaught exception". In addition, MicroPython would get stuck trying to output this error message, or generally any print output from inside a pin interrupt handler, through the UART after the first character, so that only "F" was visible. The reason was a matching interrupt priority between the running pin interrupt and the UARTE interrupt signaling completion of the output operation. Fix that by increasing the UARTE interrupt priority. Code taken from the stm32 port and adapted. Signed-off-by: Christian Walther <cwalther@gmx.ch>
acf1178 to
56b23d9
Compare
|
Rebased on master to deal with the STATIC removal, no other changes required. |
|
This is a good improvement, thanks. Note that pin interrupts on the nrf are always hard interrupts. Ideally they'd be soft interrupts by default, but...
Yes, it should be, eventually. That can be done another time. For now this PR is good. |
|
Rebased and merged in 5e926b2 |
|
Thanks! |
Exceptions in pin interrupt handlers (including the "TypeError: function takes 0 positional arguments but 1 were given" that happens when a function taking the wrong number of arguments was set as an interrupt handler) would end up crashing MicroPython with a "FATAL: uncaught exception". This is particularly annoying on a device such as the DS-D6 where the reset pin is not easily accessible.
In addition, on the nRF52832 (apparently not on the nRF52840, I haven’t checked why), MicroPython would get stuck trying to output this error message, or generally any print output from inside a pin interrupt handler, through the UART after the first character, so that only "F" was visible. The reason was a matching interrupt priority between the running pin interrupt and the UARTE interrupt signaling completion of the output operation. Fix that by increasing the UARTE interrupt priority.
Code taken from the stm32 port and adapted.
(This is just something I happened on and fixed on the side. It’s less important to me than the other nrf PRs. I am also wondering whether the whole thing should be rewritten using shared/runtime/mpirq.c, but am not putting in that effort now.)