I2C Cypress CLK low problem

[CarstenOlsen]

I have run into a strange I2C-problem on a Cypress 68013A microcontroller - and been stuck there for some weeks

The I2C-bus is connected to several devices - among them an SmBus bridge to a "Smart Battery". The "Smart Battery" regularly transmits control messages and alarm messages to the charger device (LTC4100) and its host. When we read values from the battery, the I2C bus locks up from time to time. Everything else is working perfectly.

The lock up happens under the following conditions:
- The microcontroller (master) is transmitting the first byte (addres) of a write-cycle.
- The master has issued 5 - 8 clock-cycles after the start-condition.
- The CLK is in high-state.
- The SDA is in high-state.
- The battery starts to transmit, pulling SDAn low while CLK is high, causing a start-condition.

When the microcontroller pulls the CLK low again, it keeps the CLK low forever - locking the bus. I have verifyed, that it is the microcontroller who pulls CLK low.

The condition can be seen in the two pictures. The second one is a zoom of the bus-collision. There are small delays between the I2C-bus and the SmBus from the SmBus-bridge. These delays actually reveal who is talking the Cypress on I2C or the Smart Battery on the SmBus.





I have not been able to get the Cypress microcontroller out of this state without cycling power. Even pulling reset low does not bring the I2C back to life.

Any suggestions or experience with this kind of behavior?

Thank you very much.

Kind regards,

Carsten

 

[karthikkrv85]

Hai...

What is the SCL clock frequency?

All the slaves support the speed of master's transmission?

I suspect, there may be the reason of clock stretching due to fast SCL by master and slow slaves.

Thanks

 

[CarstenOlsen]

The clock speed is 100KHz - as specified by the SmBus.

Actually I don't think it is normal clock-stretching, because it is microcontroller (master) who pulls the CLK low. According to the Cypress datasheet its I2C block can only function as a master. Or maybe I'm wrong:-o

Carsten

 

[karthikkrv85]

FX2 provides I2C compatible master control only, it is never an I2C-compatible slave.

Yes you are right. I2C in this chip supports only master mode.

Can you upload the schematic? And what are the other slaves? Have you monitored the I2C bus using scope?

---------- Post added at 17:49 ---------- Previous post was at 17:12 ----------

The "Smart Battery" regularly transmits control messages and alarm messages to the charger device (LTC4100) and its host.

What is this mean? Is this using the same I2C bus to transfer messages to host and charger device or LTC4100 reads from thermister? If it uses the bus to transfer the data to LTC then u r in soup. because you are trying to use the feature of multimaster when the FX2 is only master. Please check and let me know

 

[CarstenOlsen]

Hi karthikkrv85,

Thanks for your interest.

I'll try to explain our setup, as the schematic is huge.

On the I2C bus directly wired to the Cypress, we have a couple of 24C512 EEproms, a DS1339u RTC, a NEO-6Q GPS and the PCA9515 I2C/SmBus-bridge. The bus is pulled up by 2K2 resistors. The battery and charger (LTC4100) are wired to the other side of the I2C/SmBus-bridge and pulled up by 4K7 resistors. During normal operation, the I2C-bridge is disabled so the battery and charger is essentially decoupled from the I2C-bus. Here the Cypress is the only master on the bus and we see no problems.

When we need to read values from the battery (like State of Charge), the I2C-bridge is enabled effectively connecting the battery and charger to the rest of the I2C-bus. In this condition, we have two masters - the Cypress and the battery. There is no way to stop the battery from sending messages, so we will have potential collisions with the Cypress no matter what we do. According to the Cypress reference manual it can handle bus-contention.

No problems most of the time, but once every couple of hours during heavy stressing of the system, the Cypress I2C locks up. During normal use of our products, the time between bus-lock-ups is from hours to days.

Sorry, a meeting is waiting - I'll get back later.

Carsten

 

[FvM]

I'm somewhat surprized that a battery takes a master role, but I just will take it as granted.

Supposed, the FX2 I2C controller has all prerequisites for handling multi-master operation, may it be the case that your firmware doesn't correctly? E.g. not checking for free bus before starting a transaction, ignore status bits that signal bus collisions. Ultimately, each single step in the transaction can be checked.

 

[CarstenOlsen]

Hi FvM,

It is part of the Smart Battery Specification, that the battery transmits charger-setup-packages each 10 - 60 seconds and alarm messages each 10 seconds, if such a condition exists.

I can see from my Logic-analyzer captures the neither the battery or the or the Cypress check the bus before they start transmitting. There is nothing I can do about the battery:-0 As far as I now, it is not possible to check the bus-lines in the Cypress before transmitting. Please let me know if I'm wrong.

When doing stress-tests there are a lot of collisions, without any problems, but then suddenly the Cypress pulls the CLK low as seen in the captures in my first post.

I have had an oscilloscope on the lines also - nothing unusual. I have not been able to trigger it right at the time of fault, though.

Thanks.

Carsten

 

[FvM]

I've never been using the FX2 I2c controller. From a short datasheet review, it is a rather simple one. But according to the datasheet, it should also be able to detect a bus error and then tri-state the bus lines, which apparently doesn't happen. May be it's just a silicon bug.

A possible solution is to implement a software I2C controller to replace the hardware one, as you would do with a basic 8051.

An oscilloscope with a pulswidth trigger should be able to detect the low blocked SCL line easily. If your instrument doesn't have it, an external RCD filter can generate a level trigger from the fault condition.

 

[karthikkrv85]

Hai.. I have some suggestions. If it is useful you can go ahead. otherwise you can skip it.

1. Just like FvM said, you can use bit banging method.
2. you can connect the I2C bridge between Battery and charger --> Explanation as follows

At present, the I2C bridge is enabled during the time of Cypress controller tries to take over the bus (I guess). As per the suggestion when you have the I2C bridge between battery and charger, let the bridge be disabled during the cypress wants to have its transfer otherwise keep it enabled. So that the collision can be avoided.

I have read some portions in the smart battery.

The Smart Battery may enter the “Off State” whenever the SMBus Clock and Data lines both remain low
for greater than 2.5 seconds. A Smart Battery may enter this “Off state” in less time, however, in no case
can it enter the off state in less than 250 ms. The SMBus lines may go low because the battery is removed
from the system; the SMBus Host forces them low in order to reset the battery; or power is removed from
the SMBus (for example, when the system is turned off)

May be this could have been a reason for your SCL low. I am not sure, it is just a suspection.

thanks

 

[CarstenOlsen]

@FvM

Yes, it's a rather simple I2C controller - maybe way too simple I just got an email from Cypress support, that there is no way to reset the controller from software.

I will see if I can get a trigger on an oscilloscope. It should be possible with the equipment, I have. Thanks for the suggestion.

We have started looking into board-changes to solve this problem. We have an FPGA, that can run the SmBus communication, or we can try to do it in software in the Cypress. It looks like using an OpenCore I2C-Master-Slave block in the FPGA is the safest solution.

@karthikkrv85
Actually I was not aware of the battery off-state. As I have verified that the Cypress is holding the SCK low, I don't think that's the problem. (traces cut and SCK-pin pull-up on Cypress-side.)

Thank you very much both of you for your questions and suggestions.

I'll keep you updated on our progress and decisions.

Carsten