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.
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!