Reply
New Contributor
gadit
Posts: 2
Registered: ‎09-22-2008

i2c problem in C8051F120

I'm using c8051F120, I2C in the micro is slave.
After examining some I2C communication errors, which appear with some customers (not all)
I see that both clock and data lines are being held low for approximately 100ms which is in violation of the MSA I2C spec.

my configuration is as follows:
SMB0CN = 0x44
SMB0ADR = 0x80
SMB0CR = 0x00

Any ideas on whey this is happening? why only with occasional I2C masters and not all?
Esteemed Contributor
erikm
Posts: 6,180
Registered: ‎08-13-2003

Re: i2c problem in C8051F120

I'm using c8051F120, I2C in the micro is slave.
After examining some I2C communication errors, which appear with some customers (not all)
I see that both clock and data lines are being held low for approximately 100ms which is in violation of the MSA I2C spec.

no violation of IIC, but a violation of SMB.

you need to set the slave up to NAK when it is not ready to respond (which the above seems to indicate that you have) and set the master up to retry when getting NAKed.

The IIC 'engine' in the derivatives (f0x-f2x) but not in the deviates (f3x-up)is identical to the NXP engine and the descriotion in the user guide for the P89LPC938 or the p89c66x is waaaay more informative than the skimpy description in tyhe SILabs datasheets. note there is a 'trap' in this engine for NAKing, it never NAKs the address, just the first data byte if it is held so, when driving a slave with this engine, status 0x20 can not happen.

Erik


[This message has been edited by erikm (edited September 22, 2008).]
erik
Esteemed Contributor
Tsuneo
Posts: 6,303
Registered: ‎02-15-2004

Re: i2c problem in C8051F120

I see that both clock and data lines are being held low for approximately 100ms

Just from your description, I don't tell this is the case.
But this SCL/SDA trouble occurs on the slave side, when SMBus interrupt is delayed by disabling interrupt, or by another interrupt.

When SMBus interrupt is delayed on slave, the bus sequence stops at the SMBus interrupt. The SMBus (I2C) engine of the slave holds SCL low to pause the bus sequence (slave Clock Low Extension), until the pause is released by the slave firmware (clearing SI bit). At the same time, the master puts low to SDA as the MSBit of the next data byte, SDA line is also kept in low.

Do you disable interrupt for a while?
Or any other heavy ISR?

Tsuneo

[This message has been edited by Tsuneo (edited September 23, 2008).]
New Contributor
gadit
Posts: 2
Registered: ‎09-22-2008

Re: i2c problem in C8051F120

i do disable interrupt for a while.
and do some heavy ISR.

however, why does it happen only with certain masters and not all?
Esteemed Contributor
Tsuneo
Posts: 6,303
Registered: ‎02-15-2004

Re: i2c problem in C8051F120

i do disable interrupt for a while.
and do some heavy ISR.


Then, my above theory is feasibly applied to your case.
To make it sure, confirm it actually occurs.
For example,
- At the entry of the SMBus ISR, pull a spare port pin to low
- At the exit of the SMBus ISR, put high to the pin.

Then the port pin shows the execution of SMBus ISR.
Observing SCL and this pin on a scope, you'll know how long SMBus interrupt is delayed, when SCL is kept low.

The execution time of the SMBus ISR may be too short to observe it on the scope with SCL.
In this case, flip the pin just at the entry of the SMBus ISR.
Then the rising and falling edge of this pin shows the start of the SMBus ISR.


however, why does it happen only with certain masters and not all?

The delay is caused by your heavy ISR and/or the routine which disable interrupt.
The next step is specifying the routine which causes this delay.
You can apply above pin method to each suspicious routine or ISR.

Now the question is converted to this one.
Why this routine takes so much time just for specific inputs?
The answer surely lies in your source code of this routine /

Making the interrupt priority of SMBus to high and the heavy ISR to low, you'll temporarily treat this delayed interrupt problem. But I recommend you to specify the real cause, and fix it radically.

Tsuneo

[This message has been edited by Tsuneo (edited September 23, 2008).]