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.

TCA6424A not responding, times out

Other Parts Discussed in Thread: TCA6424A, MSP430F5638

Ok, I have a TCA6424A stuck on the I2C bus as the only I2C device out there.

The MSP430F5638 is the MC"U here.  I issue  a WRITE to the device and the darn thing times out.

The ADDR pin is tied to GROUND so in theory the 7-bit address SHOULD be 0x22.. which isn't responded to.

	ioBuf[0] = ioBuf[1] = ioBuf[2] = 0;

	// Probe the expander to make sure it's alive and talking

	ioBuf[0] = ReadPorts[0];
	if(I2C_Write(0x22, ioBuf, 1) != TRUE)
	    return FALSE;  

..returns FALSE.  Here's I2C_Write:

Bool I2C_Write(unsigned int DevAddr, unsigned char *pBuf, int nLength)
{
	Bool retVal = FALSE;
	unsigned int taskKey;

	// For I2C, the sequence is:
	//
	// - Send multi-byte START (START + read first byte)
	// - Send multi-byte READ NEXT for length - 2 (one already sent, see above)
	// - Send multi-byte finish (read last byte + STOP)
	//
	// If we're only sending one byte, it's a single API call and we will
	// special-case tht in the code below.

	taskKey = Task_disable();					// Disable task switching

	// You can't change bus modes without resetting the bus.  So,
	// let's reset the dang thing into RECEIVE mode

	I2C_Init(TRUE);

	SetI2CTarget(DevAddr, TRUE);

	if(nLength == 1)
	{
		// Just send a single byte out and return
		retVal = USCI_B_I2C_masterSendSingleByteWithTimeout(I2C_BASE,  *pBuf, I2C_TIMEOUT);
        USCI_B_I2C_clearInterruptFlag(I2C_BASE, USCI_B_I2C_TRANSMIT_INTERRUPT);
    	Task_restore(taskKey);						// Resrtore task switching
		return retVal;
	}

	// True multi-byte send, process

	if(USCI_B_I2C_masterMultiByteSendStartWithTimeout(I2C_BASE, *pBuf++, I2C_TIMEOUT) == TRUE)
	{
		nLength--;								// First byte went out
		while(nLength-- > 1)
		{
			USCI_B_I2C_masterMultiByteSendNext(I2C_BASE, *pBuf++);
		}
		if(USCI_B_I2C_masterMultiByteSendFinishWithTimeout(I2C_BASE, *pBuf, I2C_TIMEOUT) == TRUE)
			retVal = TRUE;						// Everything succeeded
	}

    USCI_B_I2C_masterMultiByteSendStop(I2C_BASE);

    USCI_B_I2C_clearInterruptFlag(I2C_BASE, USCI_B_I2C_TRANSMIT_INTERRUPT);

	Task_restore(taskKey);						// Resrtore task switching

	return retVal;
}

..I've also tried replacing 0x22 with 0x44, based on some other treads on this topic, and no love.  UCB1STAT coming out of the write attempt is 0x50, it looks like it thinks the bus never becomes un-busy?

Probing SCL and SDA I don't even see the SCL line wiggle.  Weird.

My hardware guy is out so this is kind of the edge of my EE skills.  Anyone have any suggestions as to where to look?  This is the first spin of this board so is it possible that if a pullup is missing I wouldn't see anything come out?

All help appreciated!

  • Hi Edward,
    The 7-bit slave address for this device is 0x22. So you are referencing the correct address. Where are you probing the SDA/SCL?
    Can you send schematic of your design?

    Thanks,
    Rajan
  • I'm putting our scope on SCL/SDA out, pins 65 & 66 using USCI B1 as the I2C master. In order to get a clip of the wiring I',, need my hardware guy, who is out.. I'm just a poor software engineer forced to do hardware stuff as well.

    I'll see what I can do..
  • Edward,
    Make sure the SCL and SDA are pulled up to VCC as shown in the TCA6424A datasheet. The fact that you are not seeing any signal on SDA and SCL could be due to the fact that these lines are just floating.

    Thanks,
    Rajan
  • Ok, I'll grab my hardware guy.. I'll go over the I2C connections and see how the pullups are implemented on this board. When I was running I2C on our breadboard, via a different port, it worked.. so maybe something's gone wrong there.

    Great suggestion - thanks a ton!

    Ed Averill