UCD9090: i2c/PMBus programming

I would highly recommend to order a USB_TO_GPIO adapter at www.ti.com/.../usb-to-gpio.
after receiving the adapter, download the fusion GUI Software @www.ti.com/.../fusion_digital_power_designer

The fusion will provide various flash script file to help you to not dothing everyting from scratch. this will save you lots time to do these basic i2c transcation.
Regards
Yihe

Yihe
I know exactly what i'm boring you. Just tell me. But i must do what is needed. I know about fusion and about adapter and about various flash script and so on... but i MUST do without these tools.
If you're unwilling or unable to answer this particular questions, just tell me
Thank you

Do not get me wrong. the way i suggest is more efficent to solve your problems.
I understand you will nedd develop own software. but GUI is a very useful reference to start with instead of that you do everyting from ground.
the script file exported from GUI will tell you the right way to communciate with the device. you do not have to think the order, format for the commands. they are included at the script file. moreover, GUI has a level I2C/SMBus utility which allow you to send one command by one command manually. This is also a good tool to help your debug your own problem.
Regards
Yihe

Why Phyton cannot use a TI USB_TO_GPIO adapter at www.ti.com/.../usb-to-gpio and the fusion
GUI Software @www.ti.com/.../fusion_digital_power_designer?
The reason of this is simple - we produce our own production grade universal device programmers used for mass programming of multi-PCB panels.
Very often one board carries multiple programmable devices that need to be flashed by one universal device programmer.
Flextronics (https://flex.com/) - a big company having plants in Mexico and already using Phyton production device
programmers- had required us to support programming the TI UCD9090 and UCD9246 devices set on their boards.
Since the UCD9090 and UCD9246 datasheets does not include I2C programming specs and since our reverse engineering
efforts were not fruitful we need an assistance from dedicated TI engineers working with the UCD9090 and UCD9246 devices.

That's how we stand, as of today

We have tried to program two devices. UCD9090 and UCD9246. In both cases we have encountered some obstacle.

1. So, both devices send appropriate ID and data flash might be read correctly. But with regard to programming there are some difference.

In first, i send to device the following sequence:

1. i2c start
2. device address (0x68<<1 | 0 ) 0x68 - address and 0 means writing
3. command (0xe2) PARM_INFO
4. size of command (5)
5. command content (0x02, low offset, high offset, 0x01, 0x04)
6. i2c stop
7. i2c start
8. device address
9. command (0xe3) PARM_VALUE
10. size of command (4 byte chunks)
11. data
12. i2c stop
13. delay 200us

all the sends i have 2 us delay , approximately

Namely, for the UCD9090. First 4 bytes is written without any problem, but further recourse to device is to no avail. (NACK on any first call)

UCD9246 does nothing. I have NACK on step 11 ( NACK on 4th byte)

2. UCD9090 has DFLASHCTRL register. Before programming/ erase i have to clear the protected bit. I do it and it works.

UCD9246 has not such register. ( it implies from content of PARM_INFO. There is no line 4 = Data Flash Control Registers). Righty?

Moreover, we do not have programming specification for this device at all. Can you provide us with this information?

3. Accidentally, i send command 0xd9 (ROM_MODE) to UCD9090. Now i have a "brick". Can i revive device without using Fusion and other native tools?


The situation with our customer from Flextronics is very urgent now, they are pushing us every day.

We will be very appreciated for you prompt and detailed assistance.

i understand you need develop own software, but regardless what, you need fusion gui to provide a input file for your own tool. you can not skip this.  for the test mentioned in the list, do you follow the script generated from fusion GUI?

The attached file is the programming guide which is applied to both UCD devices you are working on.

As for the ROM modde, you have to use fusion GUI to recover. please refer below for instructions

recover UCD9090 from ROM mode.pdf

Regards

Yihe

Somehow one attachment is allowed. here is the programming guide.

Regards

Yihe

1667.Configuration Programming of UCD Devices.pdf

The script file is the input file you have to use. it has all steps about how to program the device. the programming guide is also shared in the previous reply. Do you read the script file? what kind of questions do you have?
Regards
Yihe

Dear Yihe,

As I have written MANY times we are using this script file and do everything according it. BUT can program only 4 bytes in any locations and that's all.

After 4 bytes programming we ALWAYS get NAC from the device. After power off and on we can program the other 4 bytes. But I think it's not a good way.

I have written my sequence many times (you can see it in previous messages), but can't get the answer from you what is wrong.

My question is: can you ANSWER what is WRONG in my sequence or can you connect me with another person in TI with whom I can resolve my question?

let's do one device per time. since both device share the same program instructions.
do you mean you have no issue to send out E2 command but device always NACK on the E3 command?Do you unlock the flash and erase the flash before attempting writing? Do you read back to make sure the erase is completed? you can not write to the flash without erasing first. please list all steps until failure with real data. please also provide your script file? All these request are for UCD9090A device? Once you got a NACK, you can issue the STATUS_CML(0x7E) command to read the status to understand why NACK. please refer PMBUS Spec 1.1 Part2 to understand the structure of the STATUS_CML command.
Regards
Yihe

>do you mean you have no issue to send out E2 command but device always NACK on the E3 command?
No, i dont. Details below

>Do you unlock the flash and erase the flash before attempting writing?

Yes, we unlock the flash sending commands:
PARM_INFO(0x05, 0x04, 0x00, 0x00, 0x01, 0x04), PARM_VALUE(0x04, 0x00, 0x00,0x88, 0x20)
And it works fine. We can see it always getting ACK and trying to program the first 4 bytes into the Flash.

Yes, we erase the Flash before programming sending commands:
PARM_INFO(0x05, 0x04, 0x14, 0x00, 0x01, 0x04) and PARM_VALUE(0x04, 0x00, 0x00, 0x01, 0x00).
And it works fine. We can see it always getting ACK and reading the blank value 0xFF from all locations in the Flash after erasing.


>Do you read back to make sure the erase is completed?
Yes, we are reading the Flash after erasing and all locations are blank with value 0xFF.


>please list all steps until failure with real data.
1.Clearing data flash write protect bit
WriteBlock( PARM_INFO(0x05, 0x04, 0x00, 0x00, 0x01, 0x04) ) and WriteBlock( PARM_VALUE(0x04, 0x00, 0x00,0x88, 0x20) )
2.Erasing data flash
WriteBlock( PARM_INFO(0x05, 0x04, 0x14, 0x00, 0x01, 0x04) ) and WriteBlock( PARM_VALUE(0x04, 0x00, 0x00, 0x01, 0x00) )
3. write block
WriteBlock( PARM_INFO(0x05, 0x02, addr0, addr1, 0x01, 0x04) ) and WriteBlock( PARM_VALUE(0x04, 0x01, 0x02, 0x03, 0x04) ), 200us delay.
The first programming always works fine: we always get ACK from each steps.
BUT ANY next command (from the stage where we are sending the device address) returns NACK.
It can be any command, we can't even start command, because the first sent byte (device address) returns the NACK.

The WriteBlock sequence:
start
step 1. i2c( (Device_Address << 1 ) | 0 ) // Device address byte
step 2. i2c( command )
step 3. i2c( size )
step 4. i2c( all data 0...size, byte by byte )
stop

>please also provide your script file?
We don't have a script. We are creating an embedded code for our internal processor.
I have tried to explain everything we are doing. If you have any questions do not hesitate to ask me.
We really need to resolve this problem, the customer pushes us every day.


>All these request are for UCD9090A device?
We can read, erase all device and program only 4 bytes for one.
It seems that we are very closely to support it completely. And it seems that we need to do something after programming the first 4 bytes.


What concerning UCD9246, we don't have the script file for the flash programming.
We can read it, but can't unlock the Flash. It seems that UCD9246 is a bit different from the UCD9090 .
Can you send me a script for the UCD9090?

Thanks for the details and patience.
From the mentioned steps, i did not see anything wrong. you may try to change the 200us delay to a longer time. Do you run all these steps in a batch file? or you manually do one command per time? i would recommend to one command per time to allow a enough delay?
Bascially you were able to write the first pair of E2 and E3 which would be the first 4 bytes of the data. All the followings are NACK on the address. Do you check the i2c waveform to see whether there are any noise? what are your programming speed, 100KHz or 400KHz?

Just curious, do you try a brand new UCD9090 IC? I am not sure how many flash cycles have been through by your steps on the existing device.
Also, as i mentioned early, Fusion does have a low level I2C/smbus tool, you can repeat those manual command on the fusion i2c tool to isolate any hardware or software issue from your programer. Please refer the training video: training.ti.com/fusion-power-designer-low-level-i2c-smbus-debugger . you have to have a USB-TO-GPIO dongle to do this.

Regards
Yihe

According to your questions:
>Do you run all these steps in a batch file?
As i mentioned before we do not use batch file

>i would recommend to one command per time to allow a enough delay?
i'm doing that

>Do you check the i2c waveform to see whether there are any noise?
Yes, i do

>what are your programming speed, 100KHz or 400KHz?
100kHz

>do you try a brand new UCD9090 IC?
Yes, i have new UCD9090 and UCD9246


Fusion can not generate script file in offline mode (as i know). Would you like to send me any script file to check my steps for UCD9246? As i mentioned before i lost UCD9090 (it is in ROM _MODE) and we are waiting new UCD9090 and USB-TO-GPIO.
Has UCD9246 protected-bit mechanism? I can not find any info about that regarding UCD9246.
After NACK (last data byte) i get STATUS_BYTE = 0x43. STATUS_CML = 0x40. There are no clear explanations what does it mean i can not find as well

Thank you

yes, script file must be from a live device. i had tested your steps on the EVM manually with Fusion GUI I2C Tool, i had no problem to pass where you failed.

UCD9246 5.6.0.11220 Address 113 SMBus Data Flash Script.csv

The attached is the UCD9246 data flash script file. but i would suggest you wait until the USB-TO-GPIO dongle is arrvied since it need jump to ROM mode to perfrom the flash operation, this is different with UCD9090.

Regards

Yihe

Thank you for the script.
The script consists of two parts: to program data-flash and to program program-flash.
My questions are:
- what is the Program Flash Integrity Word? Is it checksum for program _OR_ data flash _OR_ program+verify?
- can I program data flash without program flash?
- as I understand, the command ROM COMMAND erases Program Flash Integrity Word and I must create a new one Integrity Word using the command BlockWrite,0x0B,0xEF,0x080001000000007FFC8F, correct?
- should I use the PEC in the all commands?