I’m trying to use the I2C interface on our STR912 board, in this case to talk to a SDP600 sensor.
I am using the ST library functions for I2C, and Yagarto to build the project.
Everything appeared to be working fine, I can read serial number out of the device, and can set sensor registers.
However, I’ve suddenly hit a problem. The sensor uses a “hold-master” sequence (also called a “clock-stretching” operation, I think) in order to indicate when it is done with a conversion. I don’t see anything in the ST library code that will deal with this operation at all. How do I solve this problem??
I was thinking of just treating the I2C pins as GPIO pins for this purpose, and bit-banging the clock line as required using GPIO_WriteBit() and GPIO_ReadBit(), but I don’t know if that will actually work or not. I also don’t know if it will nuke the state of the ST I2C module. Has anyone else here dealt with this issue on this chip ??
Clock stretching is part of the I2C spec, and (although I didn’t check) I would think the STR9 hardware would be able to deal with it. That should be one of the advantages of using dedicated I2C hardware as opposed to bit-banging.
The STM32 parts have a bit in one of the control registers to disable clock stretching (enabled by default). You might wade through the library code and make sure the equivalent bit, if any, isn’t gettting set in the ST library code.
The STM32 parts also have a fixed timeout (something like 10 msec or 25msec depending on [not sure]). If the SDP600 is holding the clock low for longer than the timeout (if any) on the STR9, bit banging might be your only option.
I guess the first question is what the failure mode is; timeout, or NACK, or what.
As it turned out, when I looked at the signals with a logic analyzer, I realized that the CPU was generating the clock-stretching as required. I was just mis-led about this because the topic isn’t discussed in any of the manuals for the chip; it’s just there and working. So our problem wasn’t the lack of clock-stretching, it was apparently some problem with the I2C device itself, which I am discussing with the manufacturer!!
Just goes to show, there’s no substitute for looking at the bus!