UCD90320: UCD90320:Remote upgrade

Hi,

Yes, I was referring to the configuration file in .txt format. We are currently upgrading the configuration remotely using PMBus scripts. At the end of the upgrade process, we issue the 0xDB command to perform a soft reset. After the device resets, we check the version register to confirm whether the new configuration has been successfully applied.

This upgrade process works reliably most of the time. However, as mentioned earlier, there are occasional instances where the device becomes corrupted after running the upgrade script. We are trying to understand the root cause of this issue and would appreciate any insights or suggestions you might have.

Hi,

It doesn’t appear to be a signal integrity issue, as all other transactions are completing successfully. However, we would appreciate your insights in case there are any specific conditions we might be overlooking.

We have few more doubts.Given below is the .txt file exported using fusion designer.

1) 

After completing all write operations, the device needs to be reset. As per the .txt file, a delay of 500 seconds is mentioned for validating the data flash checksum, followed by an additional 1500 seconds for the UCD program to start up.

Could you please confirm if we are required to wait for the entire duration specified? If we reduce these delays, would it have any impact on the upgrade process or device stability?

2)

Is it necessary to perform data flash verification steps after the device reset? If we choose to remove all verification steps, could this potentially lead to any issues or risks in terms of device functionality ?

3)

If data flash verification steps are required, we would need to reset the device again at the end of those steps. This would result in a total of two resets within the entire script. Could you please confirm if this is the expected behavior?

In that case, would it be acceptable to remove the reset command after the BlockWrite operation and instead issue a soft reset command only at the end of the script? Kindly confirm if this approach is valid and would not impact the upgrade process.

4) UCD90320: Remote upgrade of UCD via PMBUS script 

As per the query, we understand that the STORE_DEFAULT_ALL (0x11) command needs to be sent to make the configuration change permanent. Currently, this command is not being sent. Could this omission be causing the device to become corrupt?

Given that the UCD90320 has a dual-bank configuration, our expectation is that even if the upgrade process fails, the device should revert to the previous version rather than becoming corrupt. Could you please confirm if this assumption is valid, or if there are additional steps we should consider?

Hi,

1)

In the .txt file,  BlockWrite operation is performed before the data at the address is verified. If we are removing the verification steps, would it also be acceptable to remove the corresponding BlockWrite operations?

2)

When writing to the data flash, we would like to understand whether the data is being written to the primary or secondary memory. Could you please clarify how this can be determined?

Hi,

Kindly explain how the firmware determines the appropriate bank for writing during a UCD upgrade via PMBus. Ideally, when attempting to write to the data flash, even in cases where the write operation fails, the device should revert to the configuration stored in the alternate bank. Can you confirm if this is correct?

While testing, we have observed that in some cases, the upgrade process completes successfully, and it can be verified by reading the version register(0x9b). While in case of a disruption (manual powercycle) during upgrade process, it correctly falls back to the previous configuration. 

However, we have encountered instances of device corruption following a data flash write attempt. This issue does not occur consistently- What is the reason for this behavior?

1)How does the firmware determine which bank to write to during the upgrade process?

2)Is there a reliable method to identify the target bank being written to when executing PMBus scripts?

3)Are there any recommended best practices to ensure fallback to the alternate bank in case of write failure or interruption?

Hi

1. There is a internal counter associated with each bank, when the device boots up, it's to read the data from both banks, if both banks have valid the data, the bank with larger counter is used, the other bank is erased to take new data. if there is only one bank has data, the other bank is used for new data. if none has valid data, the bank 0 is used

2. No, all these are handled inside the device 

3. is there any i2c transaction error or 3V3 is stable during the transaction? we haven't heard any cases of corruptions.

Regards

Yihe 

Hi,

During testing, no I2C transaction errors were observed, and all BlockWrite operations executed successfully. Even under scenarios involving data corruption, the BlockWrite  commands completed without error.

Corruption scenario :

All BlockWrite operations were performed successfully.

At the end of the script, a soft reset command (0xDB) was issued, which returned a successful write status.

However, following the soft reset, the device entered a corrupted state despite the positive status response.

We are currently investigating this issue. We want the device to fall back to the previous version instead of getting corrupted.

When an error is intentionally introduced by altering the checksum value in the .txt file 

1)All BlockWrite operations fail as expected.

2)The previous configuration is also erased.

We would prefer that, in the event of any error during the update process, the device retains the previously valid configuration rather than erasing it or entering a corrupted state. Could you please help us understand why this fallback mechanism is not functioning as expected ?

Hi

we tested with bad  CRC and the UCD wasn’t corrupted 

please try TI fusion GUi with bad CRC file

regards

yihe