Hardware I2C buffering question

[peter239955]

Posted on September 23, 2013 at 16:39

I am working with an STM32L151xC, and I'm building a bridging between an USB and an I2C interface.

Since they have different time constraints, I came up with some issues I'm not familiar with. To read out data from my I2C device, I first send the address (and read bit) and wait for an ACK from the device. Then I want to read out the rest of the data. However, since there is USB communication involved, there is a 1ms delay between the address, and the reading of the data. The thing I've been seeing, is that after I send the address with read bit, the controller immediately starts reading two bytes, then 1ms later, when I ask for it, it reads out the rest. Oddly enough, the two bytes that were read out earlier come up correctly 1ms later, so it is working allight. Is this behaviour normal? Why are those two bytes read out automaticly, and why exactly two? Can this be dangerous for stability, and is there a way to prevent this from happening? Sincerely, Peter #stm32 #i2c

[peter239955]

Posted on September 30, 2013 at 13:50

Thanks for this information, with this I was able to solve part of the problem.

The problem consists of two parts, and since they're very similar, I thought the solution was the same for both. After sending the address, the controller does not continue reading now. But the way I wanted to implement it was to allow USB commands to break up the I2C stream into separate parts. Sending the address is one part, and the splitting up after that is now fixed. But I also want to be able to read out a specific amount of bytes, then read out the rest with the next USB command. This means that I will read out say 60 bytes, then 1ms later the other 40. But after reading the first 60 bytes, the controller reads out an aditional 2 bytes and stores them into the data register and the shift register. I tried setting the ADDR bit in an attempt to stall the I2C bus until the USB command is received and the rest can be read, but as excpected, this bit can only be set in hardware. Is there a way to stall the I2C bus halfway reading a response?

[waclawek.jan]

Posted on September 30, 2013 at 21:20

> Is there a way to stall the I2C bus halfway reading a response?

Probably not (*). In ''normal'' I2C applications, the master knows beforehand how many bytes to read. The hardware caters for speed by reading ahead as many bytes as possible. You might be better off by dropping the hardware I2C module and implementing a bit-banged I2C master. JW (*) I mean, not in the intended ways. If you want to hear a couple of unorthodox ideas: you can try to gate the I2C module's clock in RCC; or you can mimic slave's clock stretching by connecting another GPIO in OD mode to SCL. Have fun... ;)

[peter239955]

Posted on October 01, 2013 at 12:19

Thanks for your assistance in this matter.

Clock stretching with a second IO pin did cross my mind, but as you said it isn't a very clean way to work. This issue is currently not problematic, but if it is in the future, I'll look into bitbanging the I2C bus.