UCD90120A: I2C communication failure

Do your i2c master support clock streching? are there any other i2c slaves on the same bus?

I did not see what you described below in the waveform, instead, there is a very small pulse before 9ths clock. Is this what you complained about?

Do you have a waveforum when i2c communication was failed with UCD90120A?

soren.moller said:

What I can see from scoping the SCL/SDA is the SCL is pulled low by the UcD90120A just (0.2us) after the 9th rising edge of the access (in the middle of the ACK/NACK) regardless of the address sent on the I2C bus.

I can see that the SCL is first pulled low by the UcD90120A and then 50ns later by the I2C controller and held low for 1.25us before the I2C controller continues generating 400kHz clock pulses.

Regards

Yihe

Thanks for the fast reply.

Yes, the master supports clock stretching.

- If you look at the white traces, it is from a good board where the UcD90120A ends up clock stretching. Also note that the ACK is present.

- The yellow and blue traces is from the same access on a board that fails. Also note that there is a short NACK-like pulse.

No, there are not any other devices on the I2C bus, neither slaves nor masters.

Yes, it is the very small pulse before the 9th clock that actually is the 9th clock, but being pulled low by the UcD90120A immediately after the rising edge.

I tried reducing the pull-up on the SCK to better see the difference between the master (lower impedance) and the UcD90120A (slightly higher impedance) driving low.

And here is a zoom of the pulse (250ns div):

Here it is clear (if the image was less shaken) that the clock is pulled up (by the pull-up) for 250ns, then driven low for 50-100ns (by the UCD), then driven low by both (probably) for 20-50ns and at last driven low by only the master.

The thing I find very strange is that one board went from working to failing when I downloaded a new configuration via JTAG - I have done this tens of times before without problem. All boards have the same configuration.

Regards,

Søren M.

Soren

Thanks for the descriptions.

I could not think about how UCD pull-low the SCL when master is activly driving it. for a 400KHz speed, the clock pulse shall stay high at about 1.25us. based on the waveform, the SCL was pull-low completed around 700us. if it is UCD who pull low the SCL, i would expect the SCL shall look more like below since i2c host still driving the clock even if UCD try to pull low the SCL.

but based on the real captured waveform, i2c host also stops driving the clock early.

Is this same waveform repeable? can the TI USB-TO-GPIO Dongle talk to the sane UCD when i2c host is isolated? are theire any hardware or i2c host software chagnes among those boards? 

Regards

Yihe

I cannot see either how the UCD can drive the SCL low in this way without violating the I2C specs. 

SCL is pulled high by a 100 Ohm resistor for this scope shot (normally this is 1k) to be able to distinguish between the master and the UCD driving SCL low (there is nothing driving SCL high - only the pull-up).

With 1k pull-up the regions 3, 4 and 5 look to be at the same voltage (<0.1V) , but the width of the high pulse is the same.

1: SCL driven low by master (for 1.25us as expected - only last 1us visible on scope)

2: SCL pulled high by pull-up

3: SCL driven low by UCD <- this happening is what I find very strange

4: SCL driven low by both UCD and master

5: SCL driven low by master (for 1.25us - only first 1us visible on scope)

I guess the master drives SCL low when it senses it low and expect it to be high as a part of its clock stretching support.

The UCDs that are exhibiting this behavior do it consistently. 

The 100 boards made are identical and the first batch of a larger run. These have only been programmed once during production testing.

The board which went from working to non-working after one of many configuration updates is part of a prototype run of 35 boards.

We don't have a USB-TO-GPIO - we only have a UCD90SEQ64EVM-650 which we use for generating configurations with the Fusion Digital Power Designer.

To program the UCD we use a Segger j-link and OpenOCD with a SVG generated by Fusion Digital Power Designer.

We have to use JTAG as the I2C is pulled low by unpowered chips until the UCD turns on the power.

Regards,

Søren

Hi again,

we have tried to program a board 1000 times via I2C without problems.

This is done from Linux running on the board.

But as stated earlier, we cannot initially program via I2C without a significant schematics/layout change, but use JTAG during production.

Is it possible that the SVF generated from Fusion Digital Power Designer can trigger a programming/change of a hidden parameter when used with OpenOCD/j-link?

- If so, then how can we prevent that happening?

It is quite annoying that we brick 5% of the boards during production.

Regards,

Søren