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.

TM4C1294 i2C vs TM4C123, Do both have the masterbusy update error?

Hello everyone,

So i am gona start pretty soon to teach I2C to my colleagues.

We use the TM4C123 launchpad.

There is a problem, (it can be solved but i consider this a hardware error) like here is said : http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/368493.aspx

I know some peripherals from the TM4C1294 are different , but i am not sure about the Inter-Integrated Circuit (I2C) Interface.
Could someone confirm this? I would like to know, you never know, if i use a really (maybe stupidly) low baud rate, maybe this problem can arise on the TM4C123.

Also is there anywhere clearly stating the problem with the TM4C1294 i2c, reason for it and fix? If not it would greatly appreciated if it was provided. Maybe in the errata or datasheet?

  • Hello Luis,

    That is an excellent point. We know that till very low baud rates of 80Kbps and System Clock at 80MHz we haven't seen this issue on TM4C123, which would be the same range as that on TM4C129.

    On TM4C129 we have not put it down as an errata or data sheet. The entire reason for moving away from the Busy flag was to have better interrupt mechanism for I2C, which was implemented on TM4C129. This way an application can always be interrupted by another module and yet come back to the main while loop where it waits for the flag to be set according to the I2C Interrupt.

    Regards

    Amit

  • Well, i migrated a code from the TM4C123 to the TM4C1294 and it didn't work, it actually made me hate the I2C on the TM4C1294, just because that flag wasn't updated fast enough, 

    So, in place of masterbusy flag, what interrupt should i use for this case? (code taken from TM4C123)

    //
    // Tell the master module what address it will place on the bus when
    // writing to the slave.
    //
    I2CMasterSlaveAddrSet(ulI2CBase, ucSlaveAdress, 0);
    
    //
    // Place the command to be sent in the data register.
    //
    I2CMasterDataPut(ulI2CBase, ucReg);
    
    //
    // Initiate send of data from the master.
    //
    I2CMasterControl(ulI2CBase, I2C_MASTER_CMD_BURST_SEND_START);
    
    //
    // Wait until master module is done transferring.
    //
    
    while(I2CMasterBusy(ulI2CBase)) {}
    
    //
    // Check for errors.
    //
    if( I2CMasterErr(ulI2CBase) != I2C_MASTER_ERR_NONE)
    {
    return 0;
    }
    
    //
    // Place the value to be sent in the data register.
    //
    I2CMasterDataPut(ulI2CBase, ucValue);
    
    //
    // Initiate send of data from the master.
    //
    I2CMasterControl(ulI2CBase, I2C_MASTER_CMD_BURST_SEND_CONT);
    
    //
    // Wait until master module is done transferring.
    //
    
    while(I2CMasterBusy(ulI2CBase)) {}
    
    //
    // Check for errors.
    //
    if( I2CMasterErr(ulI2CBase) != I2C_MASTER_ERR_NONE)
    {
    return 0;
    }

  • Hi Amit,

    May I take a shot in the attempt to add to the neat guidance you've just provided?

    My sense (I'm not entirely sure) is that TM4C129 - while servicing a peripheral interrupt (specifically I2C here) may itself be "interrupted" by a higher priority peripheral's service - yet will return to the (temporarily bypassed) I2C service - when the higher priority interrupt service completes.  This is desirable as it makes for seamless & efficient, (near automatic) interrupt service operations.

  • Hello cb1,

    Actually my reference was to the processor doing another operation (outside an interrupt service routine) and an interlock created by the I2C transaction completion.

    However due to software compatibility reason, what we notices that a lot of the customers were OK to use the I2CMasterBusy instead of relying on the interrupt flags, and this created an issue with the new I2C controller

    Regards

    Amit

  • Hello Luis

    As mentioned in the previous post, the I2CMasterBusy is what a lot of the customers prefer using due to s/w compatibility when moving from LM3 to LM4 (TM4).

    In the specific case you have mentioned it would be the I2CIM bit-0 which we use to set a flag that replaces the I2CMasterBusy.

    Regards

    Amit