View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000972 | NetDCU10 | NI2C | public | 2012-03-26 11:04 | 2012-10-18 12:06 |
| Reporter | Keller | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Product Version | V1.37 | ||||
| Target Version | V1.38 | ||||
| Summary | 0000972: Rare I2C timeouts on Samsung IIC | ||||
| Description | When transferring data on I2C, sometimes the IIC device is not responding anymore, running in a one second timeout. This happens rather infrequently, but is very annoying when it happens as it stops the whole I2C traffic for a whole second. | ||||
| Steps To Reproduce | In a loop, send data to I2C; once in a while the transfer will stop for one second and I2C Transmission Timeout will occur on the debug port. This happens about once every 100000 writes. | ||||
| Additional Information | We have observed that the time between setting SDA and the next rising edge of SCL is very short and may result in wrongly detecting a stop condition on the bus (if rising SDA is detected after rising SCL), causing the transmission to stop immediately without raising further interrupts. Currently we are doing this: After a byte is transmitted, IIC generates an interrupt. In the interrupt service thread, we put the next byte into the transmit data register IICDS and immediately acknowledge the interrupt in IICCON. Then we wait for the next interrupt to tell us when this byte is transferred. In the error case, we never get an interrupt for this byte. Now by looking at the Linux sources, the I2C driver tells us, that writing to the transmit data register already causes the first bit of the data to appear on SDA. And acknowledging the interrupt will immediately change SCL to high. So this may be too fast. They are doing a setup-delay of 50ns before acknowledging the interrupt. This seems to explain our problem, so we should try this in WinCE, too. BTW they are also inserting this setup-delay after writing the first byte (the device address) and before setting the START bit in IICCON. I have attached the Linux driver file for reference. See functions s3c24xx_i2c_message_start() and i2c_s3c_irq_nextbyte(), look for calls of ndelay(). | ||||
| Forum Link | |||||
| Found Driver Version | |||||
| Fixed Driver Version | |||||
