UCD9246: i2c/PMBus programming

dmitry ivanov said:

Part Number: UCD9246

Dear Yihe,

We understood more and more how the device works.
Unfortunately, we need to do that not reading a documentation, but wasting your and our time in the dialog.
In our case we can't really follow the script you sent to us.
The problem is that we don't have the information from the 1k sector program flash which we need to erase (the customer gives us the file with data flash only).
So as we understand, we need to read the 1k program flash before erasing.
Summary our questions are:
- should i read the 1k program flash before erasing? If i need that, please, send the particular commands (script example) how to do that (there is no information anywhere).

[TI] The 1K flash is fixed and it is already inside the script file. you do not have to read again, you just need follow that file.
- should i program all read locations back OR we should mask (write 0xFF) the Program Flash Integrity Word? If yes, what is the Program Flash Integrity Word location?
- should i use the command Verify Checksum ROM (Integrity Word) according to the script? Really i can't verify this value, because, firstly, i don't have the Program Flash content, secondly, i don't know the algorithm of checksum calculation.

[TI]if you look at the end of script, it call 0xEF to calcuate the checksum and 0xEE to read the checksum. the script has done everything for you. The checksum is located 0x7FFC

- i noticed that script uses absolute address but not offset as UCD9090 does. Does it mean i should use absolute address then i will read data flash?

[TI] follow what the scrips tell you to do. UCD9090 does not required ROM mode to program but UCD9246 does. so there are differences.
- script uses command 0xfd (device_id) among other commands. Does it mean that command can vary its meaning depending of the mode?

[TI]Yes, you are right. 0xFD has different meaning which is up to device's mode(PROGRAM MODE and ROM MODE).

- is there a mechanism (script) to recover device from ROM_MODE in order i can recover a device apart from Fusion tool? if yes, can you send it to me as well?

[TI] currently, we do not have such tool other than fusion GUI.

I will be very appreciated if you answer on all my questions.
And I will be out of office all next week and will continue to the work after that.

Thank you

1. When device is under ROM mode, PEC byte is mandotary, it is only optional when device is under normal mode.

2. Does your device have the correct device ID: UCD9246-64|5.6.0.11220|090922 as described in the script file? If not, your can not use the script file i shared.

From the script file, you would write 0x66DBEBB2EEEBBBB833B5EE00002C55D6C7 to address 0x17FF0, where 2C55D6 is the checksum. on the step g, the returned checksum shall be 2C55D6. if it is not, the device will stay at the ROM mode and you need to flash a factory data to solve this.

3. Below is the file, you can use the Fusion Firmware and configuraiton download tool to un-brick the device.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/UCD9246_2D00_64_5F00_5.6.0.11220.x0

Regards

Yihe

Yihe

You wrote we must have device with ID: UCD9246-64|5.6.0.11220|090922 otherwise we cannot use your script. 

It means that we can program ONLY devices with this ID. But the reasonable question is what we should do with other IDs, they could not be programmed? (f.e. i have ID: UCD9246-64|5.7.0.11359|091029)
Is there universal approach to program the device?
We see to ways:
- read the program-flash and write it back, but we don't have information how the reading works. Does the device have such opportunity to read flash back?
- always write particular firmware in all devices. But I believe it's not a good way, because the device can have a newer one.


What about  the  Fusion-tool, how does it work to cover all versions of frameworks?

Regards

Dear Yihe,

Nice that you thought that we are so smart understanding that this script is only for one ID. We are not so smart without any information from you.
Nevertheless, we need to support ALL ID versions on the customer end.
We see that TI tool can create the script file for different IDs. So you have a way to do that.
It seems that we need this technology.
If we need to sign any additional NDA to get this technology, let me know the person with whom we can resolve this question.
If we don't need to resolve some organizational questions, please clarify how we can create script file ourself.

Dear  Yihe,

As we have said you that our current customer now is Flextronix (a very big manufacturing company).
They provides us with file contains only the EEPROM data.
I am absolutely sure that they don't know what the script is and how they can generate it.
Moreover they produce a lot of equipment and may be the situation when there are devices with different IDs in one manufacturing batch.
In this situation (according to your rules) when they meet a device with a new ID (we can't support it, because don't have according script),
they have to stop manufacturing, send us a board (we can't generate a script without a particular device with a new ID and connecting it to TI tool), waiting for the board delivery to our lab (it may be a few weeks, and they are waiting at this time)  and etc.
Do you mean that we need to follow to this rule?
If yes, in our experience, it's the really most original way to support customers, we have never met anything similar.
We will send you suggestions to Flextronix and will send you their feedback.