• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 33 subscribers
  • Views 1516 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C1294NCPDT: a question about I2C clock

Snaku Lee26
Intellectual 310 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: ISO1540, SW-TM4C

Hi,

I have a question about the I2C of TM4C1294. My TivaWare version is 2.1.0.12573, CCS 5.4, Compiler is TI v5.0.4.

My question as below picture, the upper image is capture from a logic analyzer, and the bottom picture is capture from a scope. The speed of I2C is 100KHz. You can see the 4th clock of the second byte is missing, only remain a very short pulse. It doesn't happen every time I2C transmission, but the opportunity is very high, 10% may be.

There are two components on the TM4C1294's I2C channel, a optical sensor (slave device), and a I2C isolator (TI ISO1540, SCL and SDA both bi-direction). The SCL pin of the optical sensor is a simple input pin, it doesn't have I2C clock stretching feature.

The yellow channel on the scope is the waveform between the TM4C and the isolator, and the green channel is the waveform between the isolator and the optical sensor.

I did not enable the glitch filter of TM4C1294 I2C channel, and I set I2CMCLKOCNT to 0xFF, I tried other value doesn't change this issue.

Now I have three solutions can fix this issue: (1) TM4C enables the glitch filter, (2) to reduce the pull up resistor on the optical sensor from 10K Ohm to 1K Ohm, make the rising edge better, (3) Add a little capacitor (e.g. 100pF) on the SCL of the optical sensor.

But I don't understand why this clock pulse missing, if the isolator pull low at that moment and TM4C clock stretching is working, why there only 8 clock pulse? Why glitch filer can fix this issue?

[ my I2C initialization code ]

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
ROM_GPIOPinConfigure(GPIO_PB2_I2C0SCL);
ROM_GPIOPinConfigure(GPIO_PB3_I2C0SDA);
ROM_GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);
ROM_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
ROM_I2CMasterInitExpClk(I2C0_BASE, ui32SysClock, false);
ROM_I2CMasterIntDisable(I2C0_BASE);

Thank you,

Snaku

  • 0
    TI__Guru 72500 points
    I cannot see the time scale on the scope picture, but I do not think you are meeting the rise time requirement for I2C on the sensor side. Please see www.ti.com/.../slva689.pdf for determining the correct pull-up resistor value, or reference the original Phillips I2C specification.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob Crosby said:
    or reference the original Phillips I2C specification.

    Bravo for that!    *** LIKE ***    *** LIKE ***    (only regular/outside poster Robert warrants THREE NEW (extra effort) (currently/mistakenly banned) LIKES!

    Would it not - most always - "Pay such posters to "Prove their I2C implementation w/a "known good" simple I2C device (such as small capacity EEProm?)     Such "proof" would establish the correctness of user's MCU implementation of I2C.    

    Burdening (or "holding hostage") the I2C channel to the "unknown effects of a "strange device"" proves NOT the most efficient means to proceed.

    KISS - so well represented here - demands "Small, simple, measurable (thus provable) steps" - implemented systematically - which is not revealed by poster, here...

  • 0
    TI__Guru*** 135355 points
    Hello Snaku,

    Also would like to chime in on a slightly off-topic but important note. If you are in new development, you should be using the latest TivaWare which is 2.1.4. You can get the latest TivaWare here: www.ti.com/tool/sw-tm4c
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Indeed - well advised - yet too is the advice to, "NOT start w/an unknown, too-complex I2C device" which may challenge the (perfectly innocent) MCU!

    It MUST be noted that a "mis-performing, overly complex, foreign device" is quite capable of "Holding HOSTAGE" the (perfectly performing & capable) vendor MCU!

    KISS - firmly/repeatedly rejected here - prevents such (unwise) practice!     (yet the KISS silence (thus rejection) persists - and is NEVER justified!)     (surely because it cannot be justified - and this "unpro" marriage of "MCU <-> overly complex/unproven device" occurs w/unbounded repetition!)