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.

CCS/MSP430F5529: I2C Diver library usci_b_i2c.c

Part Number: MSP430F5529
Other Parts Discussed in Thread: MSP430WARE

Tool/software: Code Composer Studio

Hi

I use a function from this library to recieve bytes from a slave device.

Here is the original code:

uint8_t USCI_B_I2C_masterReceiveMultiByteFinish (uint16_t baseAddress)
{
    uint8_t receiveData;

    //Send stop condition.
    HWREG8(baseAddress + OFS_UCBxCTL1) |= UCTXSTP;

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

    //Wait for Stop to finish
    while (HWREG8(baseAddress + OFS_UCBxCTL1) & UCTXSTP);

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

    return receiveData;
}

This code didn't work for my device. However, when I move the data recieve line to the bottom of the code it worked. Am I doing something wrong or is this a bug. My understading is that the processor should recieve the RXIFG interrupt before reading the data not after.

Here is how I modified the code:

uint8_t USCI_B_I2C_masterReceiveMultiByteFinish (uint16_t baseAddress)
{
    uint8_t receiveData;

    //Send stop condition.
    HWREG8(baseAddress + OFS_UCBxCTL1) |= UCTXSTP;

    //Wait for Stop to finish
    while (HWREG8(baseAddress + OFS_UCBxCTL1) & UCTXSTP);

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

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

    return receiveData;
}

  • Hello Pejwaak,

    How many bytes are you trying to receive?  

    It looks like the function is assuming that there is already data ready and reading that out first, before waiting for 1 last byte to make sure the stop is sent.  I'm not sure, but I imagine that there is one more byte still to read after this function.  

    You could also just use USCI_B_I2C_masterReceiveMultiByteNext() to read the buffer and USCI_B_I2C_masterReceiveMultiByteStop() to set the stop bit.  You'd have to manage polling the flags yourself that way.  

    Thanks,

    JD

  • This (the original) doesn't match with my copy of MSPWare 3.80.06.03 (nor 03.07 nor 02.10). My first guess is a stray mouse-click that moved the line. It might be prudent to re-install, just in case something else got glitched.

    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)
    
        // 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));
    }

  • Hey Bruce,

    I just looked at this again and saw you you see here.  The disagreement seems to be that these are slightly different functions:  EUSCI_B_I2C vs the USCI_B_I2C  (no e).   

    Depending on the device, will depend on what module is available.  But honestly, I'm not really sure why these functions would be different.  Let me have my software team investigate.  

    Thanks

    JD

  • Thanks, JD. I must have looked at that 10 times and didn't see it. But I agree that the other one (that doesn't wait for RXIFG) really doesn't look right.

    [Edit: It's probably also something that works-by-accident much/most of the time.]

  • Bruce, Pejwaak,

    I don't see anything functionally different between the eUSCI and USCI modules that would cause this change is software flow.  So, I think that this is a bug in MSP430Ware driverlib.  Sorry about that.  

    I think the eUSCI is more common in devices and so that function is the one used the majority of the time.  Because of this, this bug may have somehow gone undetected for a while.  

    I've filed a bug report with the MSP430Ware team.  They will review and issue fixes in the quarterly MSP430ware updates. I'm going to close this thread for now, but will try and issue an update in the next few weeks once this has been fully reviewed.  

    Thanks

    JD

**Attention** This is a public forum