This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C slave AAS and SCD

Other Parts Discussed in Thread: LAUNCHXL-F28069M

Hi there,

I have multiple slaves on a I2C bus, some of which are LAUNCHXL-F28069M boards.

On these boards the SCD interrupt is triggered whenever any message is completed. To determine whether or not a particular message was destined for a particular board I have been listening to the AAS interrupt, and I know the next stop condition on the bus marks the end of that message. This works great, but sometimes for short messages (one byte) the AAS is triggered after the SCD interrupt, which causes the board to think that the message was not for it.

Does anyone have any advice on how to proceed?


Thanks!


EDIT: Reducing the speed to 100kHz seems to help, but I need the communication to run around 250kHz at least.

  • If reducing the speed helps, have you tried using a stronger pull-up? Check the signals on a scope and make sure that the rise time is short enough not to interfere with the next bit.

    Do all the board have unique addresses? Is it not possible to use the RRDY interrupt?

  • The rise time of the signal is already about 200ns and I don't want to increase it much more.

    The reason I wasn't using the RRDY interrupt is if I sent two messages back-to-back like:

    [<W to 0x9><0x00><0x01><0x02><0x03>][<W to 0xA><0x00><0x01><0x02><0x03>]

    On the device with address 0x0A when I receive the SCD interrupt from the first message there are times when I have already received data from the second message, so then I process the incomplete message. I process the message when I receive the SCD interrupt and only if I have received some data. In these cases the message handler would receive the message [0x00] and then later [0x01,0x02,0x03].

    If I can fix either of these problems the system will work


    Ben

  • Could this be an interrupt latency problem? The AAS bit is cleared when a stop condition arrives, so if it takes long enough to get to the ISR, you could miss the AAS state altogether. You are clearing SCD, right? You either need to write a 1 to the bit or read I2CISRC when it contains 0x6.

    Does your data have a fixed length or a fixed format? In other words, is it possible to figure out how many bytes to expect?

    Are you using FIFO mode, or are you receiving one byte at a time?
  • I think that is what must be going on. I am clearing the SCD bit by reading I2CISRC.

    The solution I decided to go with is sending a "command" byte and determining how many bytes I expect based on the command. I'm using FIFO mode.

    Thanks!