I2C Master Clock Frequency

Exactly, as the frequencies are not matching you might experience few issues. Before commenting any further the code that you're debugging is a sample code or a custom code?

Also please post your queries about F28335 in  C2000 32-bit Microcontrollers Forum !

Regards,

Gautam

Sorry about the wrong forum – I probably selected the wrong favourite and then did not check.

The code setting the clock is as below.  Written by someone who has left the company so I can't ask about it.

    I2caRegs.I2CMDR.all = 0u;             /* Reset and Disable I2C module until clock is set */

    I2caRegs.I2CFFTX.all = 0x0040u;       /* Disable Tx FIFO, clear TXFFINT */
    I2caRegs.I2CFFRX.all = 0x0040u;       /* Disable Rx FIFO, clear RXFFINT */

    /* Own Address register - not required as I2C module is always Master */

    /* Interrupt Enable register */
    I2caRegs.I2CIER.all = 0u;             /* Disable all non-FIFO interrupts */

    /* I2CSTR - Status register - nothing to initialise */

    /* Prescaler register */
    I2caRegs.I2CPSC.bit.IPSC = 11u;       /* Gives I2C Module Clock of 12 MHz */

    /* Clock Low-Time Divider register - Master Clock freq of 400kHz L=H */
    I2caRegs.I2CCLKL = 10u;

    /* Clock High-Time Divider register - Master Clock freq of 400kHz H=L */
    I2caRegs.I2CCLKH = 10u;

    /* Mode register */
    I2caRegs.I2CMDR.all = 0x0020u;        /* Bring I2C module out of reset */

Regards.

Hi,

The above initialization seems to be fine.Please check with all the clock initialization in respective header file.

Regards,

Gautam

Hi.

I'm afraid I don't understand what you mean by "Please check with all the clock initialization in respective header file".

Sure the above code is the clock initialisation?

Regards, Giles

Hi again.

Were you refering to SYSCLKOUT?

We toggle one of the GPIOs every 20ms, and a scope shows this to be happening at this rate.  If SYSCLKOUT were wrong by a factor of ~360/400 (about 10%) it would be noticeable.

Or have I missed some other clock setup?  I've picked up the code from an ex-colleague, but reading sprug03b it looks like it is doing exactly what it should.

Regards.

Hi Giles,

There's a header file named "F2833x_Examples.h" which consists of all clock info. So you'll have to check that file too!

Regards,

Gautam

Where do I find this file?

I have all the sample code under C:\tidcs\c28\DSP2833x, but can't find it there.

There is DSP2833x_Examples.h, but that doesn't help.

What other settings are there?  We have SYSCLKOUT working as expected.  We've set I2CAENCLK to that the I2C peripheral is clocked, and done other setup as shown in the code in my earlier post.  I can't think of anything else.

Regards.

I hope your clock speed is all fine. Secondly "DIVSEL" and "PLLCR" in example.h are configured properly. Also check CPU_RATE variable.

Regards,

Gautam

"DIVSEL" and "PLLCR" read back as set.  And if they were wrong surely we'd get the wrong processor speed?  The TIMER and UART peripherals appear to be working at the correct speeds.  As mentioned above, we are toggling a GPIO and this uses a TIMER, and gives the expected rate.  UART baud rates are getting set correctly.  It just the I2C clock that appears to be ~10% slow.

We are not using DSP2833x_Examples.h, so CPU_RATE is not used.

Regards, Giles

Fine, then it seems to be something where we need to dig up further! Clock variables are fine, i2c initialization also seems to be fine....

Finally just to clear out all doubts in software; did you check out the results with example codes provided by TI?

Regards,

Gautam

Do you have any slave devices on the bus? Perhaps a slave device is clock stretching?

Regards,

 Tobias

I2C is used to communicate with a NVM device.  I believe this is always the slave - the TMS320F28335 is always the master.

"Clock stretching" is new to me.  The NVM spec implies it just uses the clock sent to it, so I can't see why it should do this, but I don't really have enough hardware knowledge to know for sure.

Regards.

Here is all about clock stretching: but I don't think this might be the issue

"Clock stretching using SCL

One of the more significant features of the I²C protocol is clock stretching. An addressed slave device may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data. The master that is communicating with the slave may not finish the transmission of the current bit, but must wait until the clock line actually goes high. If the slave is clock stretching, the clock line will still be low (because the connections are open-drain). The same is true if a second, slower, master tries to drive the clock at the same time. (If there is more than one master, all but one of them will normally lose arbitration.)

The master must wait until it observes the clock line going high, and an additional minimum time (4 μs for standard 100 kbit/s I²C) before pulling the clock low again.

Although the master may also hold the SCL line low for as long as it desires, the term "clock stretching" is normally used only when slaves do it. Although in theory any clock pulse may be stretched, generally it is the intervals before or after the acknowledgment bit which are used. For example, if the slave is a microcontroller, its I²C interface will stretch the clock after each byte, until the software decides whether to send a positive acknowledgment or a NACK.

Clock stretching is the only time in I²C where the slave drives SCL. Many slaves do not need to clock stretch and thus treat SCL as strictly an input with no circuitry to drive it. Some masters, such as those found inside custom ASICsmay not support clock stretching; often these devices will be labeled as a "two-wire interface" and not I²C.

To ensure a minimum bus throughput, SMBus places limits on how far clocks may be stretched. Hosts and slaves adhering to those limits cannot block access to the bus for more than a short time, which is not a guarantee made by pure I²C systems."

Dear Gautam Iyer,

thank for your description of the clock stretching technique, it is very clear.

I have this scenario with the i2c of a TMS320F2802 (the master). the Master send START, SLAVE ADDRESS, R/W, then the slave send the ACK and goes into clock straching state. How can i detect such condition on the master side without sampling SCL line? If you take a look at the register set of my master (the STM320F2802) seems there no information to catch the slave clock stretching.

Regards

Hello,

is there any update on this issue? I too am trying to use I2C on F28027 and have similar problems setting the master clock.

I am using a CPU clock at 60Mhz, I2CPSC is set to 4 for a 12MHz I2C module clock, I2CCLKH=10 and I2CCLKL=11 so the total master clock divider should be (10+11+5+5)=31 (d=5 for I2CPSC > 1). The master clock I was expecting is 12MHz / 31 = 387KHz, however using a logic analyser I see 333KHz, which is 12MHz / 36 if this makes any sense.

I tried with a 10MHz module clock too, setting I2CPSC=5, and I2CCLKH=I2CCLKL=8, to get 10MHz/(8+8+5+5)=385KHz but still get around 330KHz output.

I am building on top of a MotorWare example running on the F28027 Launchpad, so CPU clock is set correctly and verified via PWM, SPI frequency etc. Also, if I assume the I2C clock division works as described in the datasheet and the CPU clock is at fault, the actual CPU clock would need to be 60MHz*(333KHz/387KHz)=51.6MHz which is not an available option as far as I know.

Hello Giannis,

This thread does not seem to be active any longer. Please create a new post for the best chances of receiving help with your issue. If there is pertinent information in this thread you can link back to it in your new post.

Best Regards,
Adam Dunhoft