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.
I am using an MSP430F5438 as an I2C master and trying to write the slave address of another device, but without sending any data bytes, and without sending a stop condition. I would expect 7 address bits to be clocked out, 1 read/write bit, and 1 more clock cycle for the acknowledge from the slave. I'm not seeing that, only 8 bits are clocked out, and the ONLY way I've found to get the 9th bit for the acknowledge is to send a stop condition, which is not compatible with what the slave device is expecting. Following is a code snippet:
Boolean_t Ack;
GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P3, GPIO_PIN1 + GPIO_PIN2);
USCI_B_I2C_masterInit(USCI_B0_BASE, USCI_B_I2C_CLOCKSOURCE_SMCLK, UCS_getSMCLK(UCS_BASE), USCI_B_I2C_SET_DATA_RATE_100KBPS);
USCI_B_I2C_setSlaveAddress(USCI_B0_BASE, COPROCESSOR_WRITE_ADDRESS);
USCI_B_I2C_setMode(USCI_B0_BASE, USCI_B_I2C_TRANSMIT_MODE);
USCI_B_I2C_disableInterrupt(USCI_B0_BASE, 0xFF);
USCI_B_I2C_enable(USCI_B0_BASE);
USCI_B_I2C_masterSendStart(USCI_B0_BASE);
while(USCI_B_I2C_getInterruptStatus(USCI_B0_BASE, USCI_B_I2C_START_INTERRUPT)) ;
Ack = !USCI_B_I2C_getInterruptStatus(USCI_B0_BASE, USCI_B_I2C_NAK_INTERRUPT);
This only clocks out 8 bits, and it doesn't look like the my method of checking for the ack works either: it always returns success. According to the user's manual:
"When performing multiple consecutive I2C master transactions without the repeated START
feature, the current transaction must be completed before the next one is initiated. This can
be done by ensuring that the transmit STOP condition flag UCTXSTP is cleared before the
next I2C transaction is initiated with setting UCTXSTT = 1. Otherwise, the current transaction
might be affected."
After reading this I tried clearing the UCTXSTP bit after checking for the ack, but this had zero affect on the lines. I also tried simply sending another start condition, I thought this might be a work around, but this also had no affect lines. It seems like it should be so simple, I'm sure it's due to my lack of experience. Any help is appreciated.
Thanks,
Samuel
Now I'm having a problem sending a start condition. The MSP430x5xx states that after setting the UCTXSTT bit in UCBxCTL1 that the bit is cleared after the start condition and address are sent. If that's the case why does the following code deadlock?
HWREG8(USCI_B0_BASE + OFS_UCBxCTL1) |= UCTXSTT;
while(HWREG8(USCI_B0_BASE + OFS_UCBxCTL1) & UCTXSTT) ;
Is there an errata for the I2C hardware? I'm getting the impression the I2C hardware is either missing features or full of bugs.
The reason I was not getting a start condition is because I was not writing any data to UCBxTXBUF. A more specific question, and also the answer to my original question can be found here:
**Attention** This is a public forum