ChibiOS Free Embedded RTOS

The only recovery option for the particular board design was sledge hammer model (assert and watchdog). The I2C device had lost its mind, locked the bus up and couldn't be convinced to respond. Did you try a RCC reset approach on the specific I2C bus? That has worked well for ArduPilot using the in...

Thanks for starting this discussion! A few random thoughts .... I'm not keen on setjmp/longjmp if it can be avoided. It can make debugging hard and also hard to reason about locking. There are places in things like interpreters where the flow of control needed means using jumps makes sense, but I'm ...

I applied the first two patches on trunk, I also added some extra DMA disable on another MSG_TIMEOUT exit path. In addition I made similar changes to I2Cv2 and I2Cv3, I think the DMA-disable-on-timeout problem existed there too. I've had a look at your changes. I am concerned that they limit the DM...

Thanks. I've now just found another I2Cv1 case of an unhandled interrupt. This one is SB set without BUSY set. I've got a reproducible test case where it can happen if I unplug an I2C compass while it is actively transmitting. In this case the storm doesn't seem to persist forever. Most I've seen is...

The SPI drivers are structured a bit differently, as the thread suspend happens not in the low level driver but up in the higher level hal code. It also is much less likely that SPI will suffer from the issues in this discussion as it doesn't have any handshaking, so the state of the peripheral (at ...

I2Cv2 and v3 have similar structure to I2Cv1 so it isn't surprising that they have the same issues. Here are places where dma is enabled in interrupt context without checking to see if an I2C transaction is actually in progress: https://github.com/ChibiOS/ChibiOS/blob/master/os/hal/ports/STM32/LLD/I...

This is a follow-up of the discussions here: http://www.chibios.com/forum/viewtopic.php?f=35&t=5298&start=10 We need to audit the code for similar issues. The issues are: (1) DMA being enabled from within an interrupt handler for a peripheral due to spurious interrupts outside of the context...

Those busy loops are there to wait the end of STOP from previous operation, there is no way to have an interrupt for that. ok, but could we make the timeout much shorter? It looks like the maximum would be Tbuf, which is max 4.7us. At the moment it uses the timeout provided for the next transaction...

one thing I didn't like the look of in I2Cv2 and I2Cv3 is the busy loop waiting for I2C_ISR_BUSY to be clear: https://github.com/ardupilot/ChibiOS/blob/master/os/hal/ports/STM32/LLD/I2Cv2/hal_i2c_lld.c#L1199 https://github.com/ardupilot/ChibiOS/blob/master/os/hal/ports/STM32/LLD/I2Cv3/hal_i2c_lld.c#...

About the audit, it would be a good idea. great. I'll start having a look at SPI next. I guess CAN would be the other one to look at. I'm not sure it applies to UARTs, or at least not in the same way. I think I2Cv1 is the worst offender definitely. I2Cv1 bugs have crashed a lot of aircraft over the...