UCD90120A: I2C communication failure

soren.moller

Prodigy 130 points

Part Number: UCD90120A
Other Parts Discussed in Thread: SEGGER

We have produced a new batch of boards and see this problem ~1% of the time.

This time I have received 5 of the failed UcD90120As and have tested them in the UCD9064SEQ EVM.

There are a couple of interesting observations: (All 5 behave the same)

The I2C address is detected incorrectly:

I have set J13 to the two 84.5K resistors (shouldn't these be 90.9k?).

- With a OK UcD90120A this gives the I2C address 0x68 as expected.

- With a bad UcD90120A this gives the I2C address 0x5C which corresponds to one bin below for both PMBUS_ADDR pins.

When measuring the voltage on the PMBUS_ADDR pins during initialization, the voltage on a OK device is 0.86V and on a bad only 0.73V.

This indicates that the 10µA (+-1µA) bias current source is at 8.6µA for a bad device which is out of spec.

The EVM can communicate with the bad devices, but the I2C communication looks a bit different than for a good device:

On the bad devices, there is a short pulse on SDA just before the ACK and there can sometimes be seen a spike on SCK 0.5µs after the pulse on SDA:

(This spike messes with the I2C controller on our board which detects clock stretching. On the EVM, the T(SCK,low) is a bit longer (1.5µs vs. 1.25µs) and the 150ns low just after the spike barely hits the clock pulse)

Zoomed in:

And a good device for reference:

These observations could indicate that some calibration (PMBUS_ADDR bias current and I2C timing) of the UcD90120A could be corrupted when programming the configuration via JTAG.

What could cause this and what can I do to avoid it?

I am generating the SVF for JTAG programming with Fusion Digital Power Designer and programming the devices with a Segger j-link Base using openocd under Windows.

Regards,

Søren M.

over 6 years ago

0 yihe over 6 years ago

TI__Guru 66310 points

Hello

svf instruction is not a industrial standard and which is up to how the JTAG tool intepret the scrip file. Based on what you descrbied, the device's address was changed somehow. it could be that the ADC trim data was corrupted.

Could you contact your local TI representive so that we can share the test step to confirm this?
Regards
Yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Hi,

I talked with Arrow, which is the local distributor and they informed me that there is no local TI representative as TI doesn't do local support anymore.

Thus I don't know who to contact.

Do you have the email of a TI representative, I can contact?

Regards,

Søren

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hello

please run the UCD Device Debug Tool on the unit and the report will tell you whether trim is good or bad. you can also share the report if you can not parse it.

Regards

Yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Ok,

The UCD Device Debug Tool reports that a bad device have Invalid Integrity Code (0xFFFF) and all the trims are at max. (0x7F, 0x3F, 0x7F and 0x7).

And a good device is 0x61BC, 0x45, 0x12, 0x52 and 0x5.

This explains the problems I see.

I guess I can't fix the bad devices as they are individually trimmed. Correct?

But how do I prevent this from happening?

All our boards are programmed during an automated production test. Thus the circumstances surrounding the programming of the UcD90120A are the same every time.

Regards,

Søren

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hello
From the debug report, the bad unit has trim corrupted which will impact the ADC accuracy causing address wrong
As said, svf(JTAG) is not a industiral stadard and it is really up how JTAG tool inteprets the insturctions. We had see this issues before from other customers and they are movign to PMBUS instead of JTAG program.
What's your JTAG tool vendor? couldy you please provide yoru scv file?

Regards

Yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Hi,

Unfortunately the PMBUS is unpowered (and thus low) until the UcD90120A enables power to the system. Thus we can't use PMBUS in production, but we can update the UcD90120A from the system later on.

I am generating the SVF for JTAG programming with Fusion Digital Power Designer and programming the devices with a Segger j-link Base using openocd 0.10.0 under Windows:

https://www.segger.com/products/debug-probes/j-link/models/j-link-base/

http://openocd.org/

I have attached the openocd.cfg and the .SVF we are using in production.

Regards,

Søren

Power-sequencer.zip

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hello
Thank you for the sharing.
Regards
Yihe

0 yihe over 6 years ago in reply to yihe

TI__Guru 66310 points

Hello
In the svf file, one state approach is used. Could you please try runtest mode instead?
Regards
yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Hi,

I am actually using two state approach because runtest always fail with this error:

Error: tdo check error at line 111
Error: READ = 0x000020b8e
Error: WANT = 0x138458554
Error: MASK = 0x1fffffffe
Error: fail to run command at line 1352
Error: tdo check error at line 111
Error: READ = 0x000020b8e
Error: WANT = 0x138458554
Error: MASK = 0x1fffffffe

I also had some problems getting "one state" to work, but it seems to work as good as "two state" now.

Regards,

Søren

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hi Soren

That's the complication of using JTAG. it is up to how the JTAG vendor interpretes the svf file and sometime they do not support the command in the svf file or mis-use causing programming issue.

Here is what we observed

I found something potentially problematic in OpenOCD's Jlink code. In the file jlink.c where the program manages RUNTEST commands from SVF, jlink_runtest() it indicates that if the RUNTEST begins when you are not in IDLE state then transition to IDLE and then do the RUNTEST.

So that means an SVF command block like this from our file:

STATE IDLE;
STATE IRPAUSE;
RUNTEST IRPAUSE 25E-6 SEC ENDSTATE IRPAUSE;

would got to IDLE then IRPAUSE then IDLE then IRPAUSE wait for 25 usec and go to IRPAUSE when it should really perform as follows:
IDLE then IRPAUSE then stay in IRPAUSE wait for 25 usec and go to IRPAUSE

The extra transition to IDLE will cause the instruction execution process - which does the programming - to either not execute or execute in a non-deterministic manner since this initiates the restart that executes the loaded instructions

The code in jlink.c that is problematic is

if (tap_get_state() != TAP_IDLE) {
jlink_end_state(TAP_IDLE);
jlink_state_move();
/* num_cycles--; */
}

in jlink_runtest()

I think that removing that code might fix it but I have no way to test it and verify it. I also don't know if there might be other side effects

I think the check should actually be to determine if you are in a stable state (IDLE, PAUSE) and if not move to one

As is, the combination of Jlink/OpenOCD/SVF and the UCD device will not work

Regards

Yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Hi Yihe,

yes, unfortunately SVF is a vender specific 'standard' format.

Thanks for the thorough explanation of the problems with OpenOCD and RUNTEST.
That is probably the explanation why SVF generated with the RUNTEST option does not work with OpenOCD.

I might look into compiling a fixed version of OpenOCD if I can't find another solution.

But I then still have to verify that the current problem with the TRIM values being reset has gone.

I have tried Seggers JlinkLoad, but that doesn't support TRST, thus I looked at alternatives.

And OpenOCD/Jlink with SVF files generated with the "Two state" option works fine 99% of the time and bricks the chip 1% of the time. It might be the cheapest option to live with having to replace 1% of the chips.

Another option could be to buy pre-programmed devices from TI. Is that possible?

Or can you recommend another way of programming the devices via JTAG during production?
I think the production test system is using NI equipment controlled by a Windows PC.

Is it possible to rewrite the TRIM values to a chip with the EVM? (Or via JTAG)
I will probably need to be able to do that if I choose to fix OpenOCD.

Regards,
Søren

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hi Soren
TI does not pre-load user configuration device.
The trim data is characterised during the final test and the data is device by device. It can not rewrite the TRIM value unless you know the values.

You can try to modify the svf file to remove the two preceeding lines before RUNTEST IRPAUSE 1 SEC ENDSTATE IRPAUSE to workaround with openOCD. this is just a trial.

STATE IDLE; (delete)
STATE IRPAUSE;(delete)
RUNTEST IRPAUSE 1 SEC ENDSTATE IRPAUSE;

Regards
Yihe

0 soren.moller over 6 years ago in reply to yihe

Prodigy 130 points

Hi Yihe,

I looks like I have to change the JTAG programming either by changing the .SVF or by changing the OpenOCD handling of SVF.
Or maybe using something other than jlink and OpenOCD.

But to test I need to reprogram via JTAG many times as the current failure rate is only 1 in 100 and I would use the EVM to do this.

Thus it would be useful if I could write the trim data to a device if the JTAG programming deletes it.

I can read the trim data with the UCD Device Debug Tool and the EVM.

But can I reprogram the trim data using the EVM if I know the values to use?

Regards,
Søren

0 soren.moller over 6 years ago in reply to soren.moller

Prodigy 130 points

Hi again,

If I choose a JTAG programmer from the list of target controllers/programmers (Agilent 3070, Asset RIC-1000, Asset USB-100, Corelis, GOEPEL electronic, JTAG Technologoes or Teradyne) and use their SW to program the UcD90120A, can you then guarantee that it will work?

Regards,

Søren

0 yihe over 6 years ago in reply to soren.moller

TI__Guru 66310 points

Hello

There is no extensive test on those target controllers and programmers with UCD devices.

Regards

yihe

0 yihe over 6 years ago in reply to yihe

TI__Guru 66310 points

Hello
I haven't heard back from you and assume that you find a way to solve it. please a reply if not.
Regards
Yihe

Power management

Power management forum

UCD90120A: I2C communication failure