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.

CC2640R2F: Occasional Runt I2C SCK pulse

Part Number: CC2640R2F


Greetings.

I have a CC2640R2 configured as a single I2C master (on the main processor, not the Sensor Controller) and it is connected to two I2C slaves: a Microchip MCP23017 port expander and an MSP430 programmed to be an I2C slave. Everything works 99.9% of the time, but occasionally, I get a runt (~50ns) SCK pulse instead of the normal (~1us) SCK pulse.  The runt pulse shows up in different bit positions, but it always seems to appear in the read portion of the I2C Write/Read transaction.

I have ~4k I2C Pullup resistors and the signals look good on the scope. I read two bytes from the port expander every 20ms in the TIRTOS task context and I'll usually get a failure within a minute or two.

Do you have any idea what might be happening?  Could some noise on the SCK line somehow cause an I2C SCK pulse to be stopped early?

Thank you
Scott Wild
PASCO scientific

This is how I configured the I2C channel:

I2C_Params_init( &i2cParams );
i2cParams.transferMode = I2C_MODE_BLOCKING;
i2cParams.bitRate = I2C_400kHz;
i2cHandle = I2C_open( BOARD_I2C0, &i2cParams );

This is how I read the port expander every 20ms in a task context:

i2cWriteData[0] = 0;
i2cTransaction.writeCount   = 1;
i2cTransaction.writeBuf     = i2cWriteData;
i2cTransaction.readCount   = 2;
i2cTransaction.readBuf     = i2cReadData;
i2cTransaction.slaveAddress = PORT_EXP_SLAVE_ADDR; // 0x20
I2C_transfer( i2cHandle, &i2cTransaction );

This is what I see on the logic analyzer.  This is the read portion of the I2C Write/Read transaction.  Note the runt SCK pulse on the third bit of the last byte.

  • Cannot see your attached image. Can you attach it again?

  • Hmmm.  Strange.  It shows up fine on my Chrome browser.

    Here it is again.

  • Hi

    It is not clear to me what your question is. Are you having problems with your code (does not work as expected), or a you simply wondering why you are seeing the short SCK from time to time?

    What you are seeing might be that the I2C slave hold down the clock because it needs to reduce the bus speed:

    BR

    Siri

  • Hi Siri.

    I don't think it is I2C clock stretching because that can only occur between bytes.  This problem happens in the middle of a byte.  Also, if you count the clocks, the runt clock pulse is treated as a regular clock pulse by the I2C master.  Something is causing the clock generator hardware to terminate the clock pulse early.

    The problem varies depending on where the runt pulse shows up.  If it shows up in the first byte of the transfer which includes the slave address, the transfer will fail because the slave doesn't see the runt pulse which will cause the slave address to be off by one bit.  If the runt pulse occurs in the read data, the data will be corrupted because it will be off by one bit.

    For example, in my image, the value read back is supposed to be 0x29, but since the slave didn't see the runt pulse, the I2C master will read 0x34.

    One of the I2C slaves is on a separate proto board connected via an 8" cable to the main board, so maybe some noise is being introduced somewhere.

    I guess my question is: Are there any known situations that might cause a clock pulse to terminate early?

    Thank you

    Scott

     

  • Hello again.

    It looks like there is a bit of noise coming from a 5V switching supply on the board which is making it onto the SCK signal (~5us burst of +/- 250mV noise every ~30ms).  I'm going to guess that this may have something to do with it.

    I'll look into cleaning up my supply and see if that fixes the problem.

    Thank you

    Scott