I2C alive?

Hi Alex,

Im guessing you first send a control byte to the RTC in master Tx mode. The RTC is obliged to respond with an ACK/NACK to signal whether it got the message or not. You could poll the NACK bit in I2CSTR for a few cycles in this case to see if its alive or not.

Next, when you swtich over to master receiver to get the data you would first send out the address you want to read and the RTC must acknowledge in which case you could again poll the NACK bit but then you would have to establish some kind of timeout period when it starts transferring data over.

This is a good start, but I still think the fix for the data transfer is not optimal.

Is there any way we can aviod the timeout period during teh data transfer? Is there any status bit that tell us tha the I2C is receiving/transmitting data?

Data transfers can be pretty long ( depending on the number of bytes), so I was hoping to check a simple bit to see if the I2C is still talking to the RTC.

Do you think connecting the I2C clock signal to a DSP GPIO for diagnostic will be a solution?

Thank you

Maybe you could. If the RTC is slower than the MCU it should, according to the I2C spec(v2.1), pull the clock line low (stretch) until it can put some data on the line. You could look for an indeterminately long low clock on the SCL line(by connecting it to a GPIO) and then make a decision based on that. But again that is a form of polling itself.

You could use some of the interrupt bits like XRDY/RRDY for transmit/receive respectively but again the I2C will just keep waiting until something is put on the data line. But since this is an RTC dont you only have to read a few bytes??

Im not sure I know of another way to do what your asking. Hope it helps..

Hi Vishal,

The RTC has 16 bytes and the I2C clock bus runs at around 300kHz. So it takes around 1 ms to get all the data. We would like to avoid having to wait 1ms if the RTC is dead.

As I mentioned before, we cannot have interrupts. The GPIO solution is a form of polling itself, but it avoids having to wait 1ms timeout period.

Does the DSP have any other status bits/flags that can use to detect if there is still communications with the RTC? Any other ideas?

Thank you

Alex

I think you could do something like this:

Setup the I2C controller to read 16 bytes
Loop
  If I2C status is idle
    Read out 16 bytes from the I2C FIFO
    If all 16 byte are 0xFF then
      Discard the 16 bytes.
    Esle
      Use the 16 bytes.
    Endif
    Setup the I2C controller to read 16 bytes.
  Endif
  Do other things.
End Loop

Assumes that the RTC is only device on the I2C bus and the I2C comtroller has a 16 byte FIFO.

Vishal Coelho said:

Maybe you could. If the RTC is slower than the MCU it should, according to the I2C spec(v2.1), pull the clock line low (stretch) until it can put some data on the line. You could look for an indeterminately long low clock on the SCL line(by connecting it to a GPIO) and then make a decision based on that. But again that is a form of polling itself.

Im not sure whether this is useful to you or not  but instead of connecting SCL to another GPIO, you can just read the GP(A/B)DAT for which the I2C is on to check the activity of the lines (both SDA and SCL).  This is because according to the Sys Ctrl and Int guide (SPRUFB0D) GP(A/B)DAT reflects the pin input no matter if you are using it for I2C or not.  You could possibly do a check to see if there is activity on the line.

Although you said interrupts were not allowed, one possibly is setting up the external interrupt for that line and just polling/viewing the results (whilst having global interrupts disabled) to see if there have been any transistions in the clock lines.

Hopefully some of these ideas help,

Tim

Back to the question whether the DSP can determine if the RTC is responding. I apologize if I am going over stuff you already know. Others may disagree....

As Vishal has pointed out, the Slave device is oliged to ACK any data written to it. The default state of the bus is high. The Slave device must pull the bus down to ACK. The absence of an ACK is considered a NACK. Checking the NACK bit on the status register will show that Slave device is not responding. On write transactions, the Slave device ACKs every byte written to it. Including the Slave address byte. On read transactions, the Slave device ACKs only the Slave address byte and the Master ACKs the other bytes. On either read or write, the Slave device must ACK at least once.

Assuming no clock stretching or bounded clock stretching, most I2C controllers operating in Master mode will clock the required bits even if the Slave device does not exist. That means that a I2C transction should always complete. You should always see the I2C clock even if the Slave device does not exist. The I2C controller should never stay busy forever. Assumes that the DSP's I2C controller is functioning correctly, that the bus is not shorted to ground or the positive rail and that bad a RTC is not shorting the bus.

The default state of the bus is high. The Slave device must actively pull it down. A unresponsive device will leave the bus in a high state, eg all data read from the device will be 1's or 0xFF.

Is tougher to handle an insane device that is pulling down the bus permanently or intermittently. Usually busy wait loops have counters to limit the number of loops to partially counter that.