Part Number: UCD90160A
We have a product in the field and are trying to implement a robust field update process for the UCD90160A that controls all power rails for the device (meaning that failure of the update will brick the device.) We currently use a "Data Flash Script" export from Fusion for manufacturing programming of the device, and have application code for our device nominally written and tested that parses the same data flash script and updates the UCD. The application code determines the current version by reading the portion of data flash that contains the MFR_REVISION register (we read 16 bytes from 0x018820; the length and MFR_REVISION register are the first 13 bytes of this from what we can tell.) This all nominally works, except for one edge case: In some (rare) circumstances, it's conceivable that an I2C bus fault or device software issue would prevent the update from completing successfully, and the fallback if all retries fail is to soft-reset the device's processor, which can potentially resolve the issue. This leaves the UCD running on its current configuration, but potentially with an inconsistent or partial configuration stored in data flash. However, since our firmware update process is only checking the flash at 0x18820, and that is written fairly early in the data flash script, there is a chance that the problem wouldn'e be caught and the device would be bricked.
As an initial attempt to fix this, I manually modified a data flash script to move one flash write (4 bytes in the MFR_REVISION space at 0x018820) to the end of the script, after all the other writes and verification reads. This seems to work, but only if the edit is very specific and targeted. Other attempts to edit the data flash script are met with errors or the UCD failing to load firmware, and it feels like some of the documentation is inconsistent, so I'd like to clarify a few things:
- Is it acceptable to write to the data flash non-sequentially like I'm trying to do? IE, write the entire flash but skip one 4-byte chunk in the middle, then read back to verify, then write the final 4-byte chunk in the middle.
- The UCD programming guide (slua815b) part 3.3 indicates that for the UCD90160A, the valid address range for data flash is 0x18800 - 0x18DFF. However, the exported data flash script includes addresses beyond 0x18DFF, up to 18EFC in one file and 18FFC in another; attempts to manually remove the writes above the supposed valid range from the script result in errors. Changing as little as one or two bytes in the MFR_REVISION space seems to result in many changes in this area of the script. What is the actual valid address range for the configuration data / how much of this is necessary?
- The Fusion tool (version 7.10.1 from October 2023; appears to be the latest) when viewing the data flash page indicates that the data flash checksum is from 0x18E24 - 0x18E27, but the value here is always 0xFFFFFFFF or 0x00000000 (and this is outside of the supposed valid range of configration data mentioned above). From the data flash scripts, it appears that the CRC area might actually be around 0x18DE8, or somewhere else in that higher space. Where is the actual data flash CRC located, if it's in a constant location? (Note, I understand that it is statically calculated and does not reflect the current state of the data flash; however, it may make more sense for us to use this as our version hash for firmware comparison purposes than the MFR_REVISION register, especially if it is written late / at the end of the programming process.)
The TL;DR here is that we are trying to field-update the UCD90160A with a data flash script, and our update code needs to detect and handle cases where the UCD data flash is partially inconsistent or invalid due to a prior interrupted update. Our current method of reading MFR_REVISION from data flash at 0x018820 is inadequate because an update that is interrupted after that point will appear to be successful but actually brick the device. I'm trying to evaluate modifications to the flash script sequence and/or our update process to increase reliability of the update.
