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.

RTOS/TM4C1294NCPDT: TM4C1294NCPDT I2C speed question

Part Number: TM4C1294NCPDT

Tool/software: TI-RTOS

I am using a TM4C1294NCPDT on a TI eval board and I have the I2C all working well.  I am using the RTOS API to use the I2C.  My sudo code is as follows:

   init_i2c_devices(); // inits the device pins and calls  I2C_init(); 

    I2C_Params_init(&i2cParams);
    i2cParams.transferMode = I2C_MODE_CALLBACK;
    i2cParams.transferCallbackFxn = I2C_completeCallback0;  // specify the callback here.
    i2cParams.bitRate = I2C_100kHz;  // Here is where I set the I2C speed.

    // Open I2C 0  for channel 0
    i2c_Handle[I2C_CH0] = I2C_open(0, &i2cParams);
    if (i2c_Handle[I2C_CH0] == NULL)
    {
        System_abort("Error Initializing I2C 0\n");
    }

My question is I have a device the Tiva talks to via I2C that would be more reliable if I used a slower speed than 100k when I update it's firmware.

I tried using the following call and where I would set the variable slowI2C to different numbers and got un predictable results for the I2C speed.

ROM_I2CMasterInitExpClk(I2C0_BASE, SysCtlClockGet()*slowI2C, 0);

What would be the recommend method to slow the I2C down and do some operations and then restore the speed back to the 100K speed?  For example, if I wanted to slow theI2C from 100kHz to 50kHz and do some operations and then restore the I2C speed back to 100kHz. 

Thanks,

Doug

  • Hello Doug,

    I don't believe TM4C supports lower than 100kbps. If it does, I haven't seen any sources of that working before.

    From the datasheet:

    ■ Four transmission speeds:
    – Standard (100 Kbps)
    – Fast-mode (400 Kbps)
    – Fast-mode plus (1 Mbps)
    – High-speed mode (3.33 Mbps)

    From a standard standpoint, it is allowed to go under 100kbps, but the TM4C is not built to do so with the I2C peripheral.
  • That's odd since most devices can just slow a clock down to lower the baud rate. 

    On the Stellaris, I was able to do it but I was not running TI RTOS since I was using a lower lever API. for the I2C on the Stellaris..

    Doug

  • Hello Doug,

    Looking through and comparing datasheets, I think you would be able to do the same for TM4C. We don't really support that from an API standpoint but with DRM calls, it would be possible.

    That said, I don't know if you could get that working with TI-RTOS. I am going to pass this thread over to the TI-RTOS team to comment on that.
  • It's OK if I don't change the I2C speed via the RTOS API. I want to use the RTOS API but when I do a firmware update to an I2C slave, I would like to slow the I2C speed for the download only then restore the original I2Cn speed after the download is complete. It's fine to use non RTOS API calls like ROM_I2CMasterInitExpClk() to change the I2C speed but I got un predictable results where some values of slowI2C in the function call ROM_I2CMasterInitExpClk(I2C0_BASE, SysCtlClockGet()*slowI2C, 0); would slow it down and others would have no effect on the I2C speed..

    For simplicity assume I want to use 100k I2C speed for everything but I want to slow the I2C down from 100k to 50k and just do a firmware download to a I2C slave device then restore the I2C speed back to 100k.
    Is using the function ROM_I2CMasterInitExpClk () the way I should slow down the I2C and then restore the speed? If that is the right function call to use ROM_I2CMasterInitExpClk(), what parameters should I use to slow it down to 50kHz and then restore it back to the normal 100kHz?

    Thanks,
    Doug
  • Hello Doug,

    I2CMasterInitExpClk will not allow you to do anything but 400kbps and 100kbps. If you check the function in i2c.h in DriverLib, you will be able to understand why.

    You would need to do Direct Register calls to the I2C registers to achieve this, no TivaWare APIs will slow down the I2C that much.

    How such DRM calls and using I2C outside of the TI-RTOS frame affect the system are elements you should want feedback on from the RTOS team.
  • Hi Ralph,

    Thank you for your help with this! After talking with Doug earlier, I wanted to share some additional input. First off, you are absolutely correct that indeed we do support 100Kbps and 400Kbps via the TivaWare Peripheral Driver Library. So, to go any lower than that, we’d need to modify the MTPR register which then needs to be written to manually, if it is in RTOS or somewhere else outside of PDL.

    However, what is very interesting about this is that the TI bq gas gauge group is the one suggesting to Doug to run the I2C peripheral at 'half-speed'. We are somewhat confused by this recommendation since while a firmware update might require delays after load (to give the CPU time to implement the update) we don't understand why the I2C data rate itself would need to be configured lower for data communications during the upload.

    I was hopeful we might get some input from the gas gauge team to help provide further clarification to Doug on this. In the end, we can implement a lower I2C speed, but want to understand WHY to do this before actually doing so.

    Thank you,
    Chris
  • Doug,

    I can't address the question of what function to call and what arguments to use to slow the clock down. As far as I can tell though, if you surround that function call with Hwi_disable() and Hwi_restore() so that the register update operations are atomic, I think the I2C driver functionality won't be affected.

    Alan

  • Can I mark this as resolved?