facchinm
commented
3 years ago Hi Daniel,
mbed-os derived cores implement a protection against misuse of some non re-entrant APIs (like new, malloc or Mutex) inside ISR to prevent nasty runtime bugs.
Both Wire and Serial classes make use of mutexes to allow thread safety, so they can't be used inside an interrupt handler.
analogRead() is a bit different since it creates an AnalogIn object when called for the first time, so calling it in setup() at least once will allow subsequent runs inside IRQs.
A common pattern to deal with this issue is using events, which allow a thread that's waiting for a value to sleep until the IRQ occurs instead than busy looping.
@per1234 @sebromero should we add some of this tips to the knowledge base?
per1234
DanielSart
Hey,
I have a problem with my 33 BLE and Nano Connect. I work with a MCP23017 (an I2C Shift Register) and I want to read out the values of its ports inside an ISR after an external interrupt. But both the 33 BLE and Nano Connect crash inside the ISR or get stuck in there. If I set a glonbaflag within the ISR and read out the MCP23017 inside the loop or even a loop2 (with Scheduler.h) it works totally fine. Additionally the read-out of the MCP23017 inside an ISR works as expected with no problems on my 33 IoT. So I guessed this should be a Mbed OS problem.
Other functions that trigger the same problem on Mbed OS devices are Serial.print/println and as I saw in other forum post analogRead as well, but I didn't test that one. My guess is that perhaps I2C and Serial functions rely internally on interrupts themselves and therefore for some reason trigger the same ISR I created instead of the one that they meant to call, so the device gets stuck in an infinite loop. I saw in a different git post that this might be related to the problem that multiple interrupts aren't working properly. Like here:
But this is just a guess.
Cheers, Daniel