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.

MSP430FR5729: DRIVERLIB potential bug: EUSCI_B_I2C_masterReceiveMultiByteFinish()

Part Number: MSP430FR5729

I believe I've discovered a bug in DRIVERLIB version 2.91.13.01.  In the file usci_b_i2c.c, in the function EUSCI_B_I2C_masterReceiveMultiByteFinish() is the following code:

uint8_t EUSCI_B_I2C_masterReceiveMultiByteFinish (uint16_t baseAddress)
{


//Send stop condition.
HWREG16(baseAddress + OFS_UCBxCTLW0) |= UCTXSTP;

//Wait for Stop to finish
while (HWREG16(baseAddress + OFS_UCBxCTLW0) & UCTXSTP)         <--- NOTE NO SEMICOLON

// Wait for RX buffer
while (!(HWREG16(baseAddress + OFS_UCBxIFG) & UCRXIFG)) ;

//Capture data from receive buffer after setting stop bit due to
//MSP430 I2C critical timing.
return (HWREG16(baseAddress + OFS_UCBxRXBUF));

}

I believe there should be a semicolon (;) at the end of the "while (HWREG16(baseAddress + OFS_UCBxCTLW0) & UCTXSTP)" immediately after the "Wait for Stop to finish" comment.  The missing semicolon causes the wait-for-stop while statement to also execute the wait-for-RX-buffer while statement, which might be triggering the bus stall errata USCI37 documented in SLAZ382AH.  It's noteworthy that the EUSCI_B_I2C_masterReceiveMultiByteFinishWithTimeout() function does have a semicolon at the end of that corresponding line of code.

This appears to affect all DRIVERLIB versions except for the MSP430F5xx_6xx version, where the semicolon is present.

Can someone at TI please confirm?

- Brian

**Attention** This is a public forum