Hi!
We have been trying to communicate with the DLPC150 over I2C, but it tends to lock the bus.
The scenario is as follows. We waited HOST_IRQ to go low, then tried to send some commands over I2C.
Mostly after receiving the address (and ACKing it), the DLPC150 would pull SCL line low and keep it this way. Sometimes it would also be able to receiver one or two data bytes (we tried sending different commands, so it doesn't seem to matter what data is transmitted). To get control back over the I2C bus, we had to reset the device with PROJ_ON signal.
This SCL issue is related to DLPC150, because other devices on the same bus communicate without issues, we also disconnected SCL from DLPC150 to see that it was the one pulling the line low.
First this issue occurred with an Arduino, we tried the I2C with clocks from 5 to 100 kHz. When probing the signals, we saw that I2C timing was not the best (SDA changed on the falling edge of SCL, it did not hold data valid after the SCL falling edge for any measurable time). There's an oscilloscope image of Arduino, where DLPC150 receives the address and ACKs it, but there's a visible small jitter on the SDA line. So we thought that the issue of lockup occurs due to Arduino's poor I2C timing. The HOST_IRQ remains low throughout (so DLPC150 doesn't report any errors), but after the the address byte the SCL is pulled low.
Then we moved on to Raspberry (I2C @ 100kHz). Raspberry had better I2C timing, as it had more time between SDA and SCL line changes. The HOST_IRQ remains low throughout, but after transaction ends, the DLPC150 keeps the SCL low (there is an image attached).
We tested with two DLPC150 and the same communication issue occurs with both. Power supply should not be the issue, the board was powered from a lab power supply.
We have used the DLPC150 before, with STM32 I2C, so we know it works. The worrying thing is that we don't exactly know what causes this I2C lockup, is it only I2C timing related? Even if the I2C timings are poor, locking up the bus still seems a bit harsh reaction, we'd expect NACKing or ignoring the transaction.
Do you have any previous experience on how this issue can be avoided? It seems there was a similar discussion before, but the topic was closed before a solution was posted and another similar topic for DLPC350.
Thanks for helping out, looking forward to your reply!
