Clarification on I2C SCL generation when bus busy condition in MPC8548

[kasi86]

Hi,

I am working in MPC8548 PQ3 processor.

I am facing a issue that I2C bus is busy by keeping SDA as low from slave device. This problem happened due to reset happened in I2C master(i.e., MPC8548 resets) while doing some I2C transaction with I2C slave device. I hope that slave device didn't complete the transaction. And when I2C master came up from rest, it found that bus is busy considering slave is tying to send data '0' in SDA (could be valid data).

When I am referring MPC8548 Reference Manual, I found below piece of steps to do when bus is busy by keeping SDA as low

1. Disable the I2C module and set the master bit by setting I2CCR to 0x20

2. Enable the I2C module by setting I2CCR to 0xA0

3. Read the I2CDR

4. Return the I2C module to slave mode by setting I2CCR to 0x80

Query:

1. Will the above mentioned steps generate 1 clock cycle or 9 clock cycle?

As per I2C Specification, in this kind of scenario we need to generate 9 clock cycle for slave to finish its unfinished transaction

2. If this is the case, Do I need to execute the above mentioned step in a loop of 9 times?

It will be helpful if anyone answer for my queries?

Thanks and Regards,

Kasi

[r8070z · Accepted solution]

1. Read I2CDR generates nine SCL high pulses.

2. Hence you do not need to execute the mentioned step in a loop of 9 times.

[kasi86]

Hi Serguei,

In Linux Kernel codebase (currently I am referring latest Linux Kernel source 3.19), these procedure has been implemented under i2c-mpc.c as below

/* Sometimes 9th clock pulse isn't generated, and slave doesn't release

* the bus, because it wants to send ACK.

* Following sequence of enabling/disabling and sending start/stop generates

* the 9 pulses, so it's all OK.

*/

static void mpc_i2c_fixup(struct mpc_i2c *i2c)

{

        int k;

        u32 delay_val = 1000000 / i2c->real_clk + 1;

        if (delay_val < 2)

                delay_val = 2;

        for (k = 9; k; k--) {

                writeccr(i2c, 0);

                writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);

                readb(i2c->base + MPC_I2C_DR);

                writeccr(i2c, CCR_MEN);

                udelay(delay_val << 1);

        }

}

I got confused by seeing this piece of code. Because in linux kernel they are trying to execute these set of steps for 9 times in a loop when they detected bus as busy before initiating a transaction.

Could you please tell me why this discrepancy is there?

What could be the reason that its executing for 9 times in Linux Kernel I2C MPC driver code?

Thanks and Regards,

Kasi

[r8070z]

I could not say why they wrote this procedure in Linux kernel. But I've read report with signal traces from our expert who implemented procedure from the manual.  Single read I2CDR generated nine SCL high pulses. Of course if one generates 9 pulses 9 times it will also work. Just reset i2C bus 9 times.

[kasi86]

In our scenario, we have an EEPROM device (as a slave device)connected to I2C bus of MPC8548. And that EEPROM is working under base voltage which is always available in the board and there is no reset pin for EEPROM available.

Issue:

Under some unexpected scenario, MPC8548 processor got warm reset by another management controller abruptly. Due to that the last I2C transaction with EEPROM device was unfinished. And I2C was held busy by EEPROM slave device.

When I2C bus is busy for certain timing then in our driver coding, we are executing the above set of procedure for 4 times (I hope executing above procedures single time could be enough to generate 9 clock cycles). But still I2C bus is not freed.

Is there any possible way to free the I2C bus (except by doing power reset)?

Thanks and Regards,

Kasi

[r8070z]

Did you check that 9-clock reset is applied to the EEPROM?
If so did you ask EEPROM manufacturer for possible workaround?