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.

TMS320F28022: I2C CLKH and CLKL, want to go real slow

Part Number: TMS320F28022

I am having troubles with I2C stability, and want to slow the I2C clock to 1/10 it's normal speed so I can use my PC sound card to capture the I2C signals. The sound card is limited to 20KHz. I thought a 10KHz I2C clock might work.

See below for the numbers I used for the prescaler and clocks.

It seems to work OK (sort of) at 100KHz, (I2CCLKL and I2CCLKH both set at 45d or 0x2d.)

But when I use 450d (0x1c2) for both hi and lo clocks the communication break down

I have a FTDI FT201x USB to I2C chip, A PurePath CC8030 wireless chip, and also an Analog Devices ADAU1701 on the I2C port.

Any ideas?

Thanks, Mark.

Here is my attempt:

The Piccolo is running at 50MHz.

// setup the prescaler for the I2C module. must be between 7-12 Mhz on module clk
I2caRegs.I2CPSC.all = 4;        // 50MHz / 5 (PSC + 1) = 10.0MHz
                                // setting PSC to 4 makes d = 5

// here is the math: for 100KHz where d is 5 (based on the prescale, above)
// 10,000,000 / (45 + 5) + (45 + 5)
// 10,000,000 / 50 + 50
// 10,000,000 / 100 = 100.0 KHz
// if we want 100k clk freq, use 45 and 45 respectively
// 100KHz is 10uS pulse cycle. 9 bits per byte is 90uS per byte
    I2caRegs.I2CCLKL = 45;                // NOTE: must be non zero
    I2caRegs.I2CCLKH = 45;                // NOTE: must be non zero
// lets try to slow it down to a 10Khz rate
    I2caRegs.I2CCLKL = 450;                // NOTE: must be non zero
    I2caRegs.I2CCLKH = 450;                // NOTE: must be non zero

  • Hi Mr. Javelin,

    Your calculation/configuration looks right and you should be able to clock the I2C bus at low speeds, like 10KHz.

    Is your f2802x device the only master on the bus? The master device controls the SCL clock line (unless clock stretching is occurring).

    Could you probe the I2C bus with less devices on the bus, or even none other than the f2802x, to see if the clock speed is what you expect? Could be the other devices affecting the clock speed.

    When you say the communication breaks down, what do you mean (or see) exactly? Could you capture and provide some waveforms of the issue?

    Best,
    Kevin

  • Thanks Kevin:

    The 28022 IS the only master.

    I have been having an issue getting my head around the various errors returned by the various devices in the bus. The ADAU is pretty straightforward, but the FTDI is tricky.

    For example, the FTDI chip (when addressing via its slave address) will NACK the address phase (if reading) if there is not a byte in it's buffer to be read.

    When that happens, the Piccolo I2C will release the bus (BB goes away) and will not further clock the bits into it's receive reg so RRDY never gets set.

    This took me a long time to figure out the proper loops and traps. Sometimes I waited tor ARDY, sometime I waited for RRDY, and sometime I would have to check the BB bit.

    I feel I have it figured out now, and would like to write a white paper on the specific workings of the FTDI chip and the Piccolo.

    Can you point me to a place to post such a work for peer review?

    Thanks, Mark.

  • Hi Mark,

    That's good, happy you were able to figure this out and understand the relation between the registers and what's happening on the bus.

    Are you wanting to post your findings somewhere on TI.com for review or just looking for general suggestions? I'm not certain that we have such a service and would need to get back to you. You're always welcome to post your findings on this thread as well.

    Best,
    Kevin