• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 62 subscribers
  • Views 209 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UCD90120A: Data Flash Configuration Checksum Issues

Jordan Smallwood
Prodigy 250 points
Part Number: UCD90120A

Hello,

I am having an issue with reproducing Data Flash Configuration CRC. We have a process that involves the following:

Build XML project file in OFFLINE version of TI Fusion

Import XML file into device

Export Data Flash

Record Data Flash Configuration CRC from Address 0x18D8C

When we repeat this process with another setup the Data Flash Config CRC is different than what we expect. For example, we have two setups: one is on a circuit card assembly and the other is on the 64-pin UCD evaluation module. Say we generate an offline project file and then download that to the device on the evaluation module. Then we export the data flash hex file on the UCD90120A contained in the evaluation module and we get a Dflash CRC = 0x0000ABEA. 

Next we take that same offline xml file and download to the device on a CCA. Then we export the data flash and record the Dflash CRC as 0x0000A81D. 

I am unsure what is causing the discrepancy if the same input file is used in both cases. They are the same part number and I believe they have the same firmware as well (4.3.2.0). Thoughts?

Thanks,

Jordan S.

  • 0
    Prodigy 250 points

    Here is the difference between the two data flash hex files, the one on the left is the export from the evaluation module and the one on the right is the export from the CCA.

  • 0 in reply to Jordan Smallwood
    TI__Guru 57980 points

    Hello Jordan

    This question had been addressed in the email back to Sep when you first contacted Joe and Jim.

    As explained in the email, using xml file to program the device will cause the different checksum through this does not impact the real function. The reason is that some reserved bits/bytes may have different initial value when xml file is used so that the final data flash will be different. But they both have the same settings regardless the checksum.

    As said in the email, using data flash format file to program will ensure that the checksum is the same.

    Also the whole flash contains both user configuration and log. the log will be different device by device since it is updated on the fly. you have to exclude this when performing the comparison as described at section 3.3 of

    https://www.ti.com/lit/an/slua815b/slua815b.pdf  

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 250 points

    Hi Yihe,

    What we are really trying to do is recreate an image and show that the dflash checksum is the same when exporting the flash file. As this is the only way that we can show two programming files are the same. I have a feeling that when we write the XML file to different devices that there may be certain values that are not updated causing a different checksum. Which led me to think that if the flash is erased and then we load the offline xml file and export data flash then the checksum should be the same on any device regardless of what may have been on them in the past. However, in my erasing of data flash through the TI MFR GUI something went terribly wrong and I believe I may have bricked the flash. After my attempt to erase the flash I now cannot communicate with the device. When I check for device ID in the UCD90XXX GUI I get the following error:

    Is there any way of reverting this device back to an "as received" state? It seems like some of the firmware may have been corrupted when the data flash erase attempt was made.

    Thanks,

    Jordan S.

  • 0 in reply to Jordan Smallwood
    TI__Guru 57980 points

    Hi Jordan

    As said, you may not be able to get a same data flash hex file when importing the xml file into various device.. importing data flash hex file ensures that all device have the same flash data as original file. what you described of erasing + import may worth a try.

    Do you want to confirm that the data flash file and project xml file are the same?

    Based on the snapshot, I think the device is good. could you reset the UCD90120A and recheck the device_id via UCD90xxx Device GUI?

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 250 points

    Hi Yihe,

    [Yihe] As said, you may not be able to get a same data flash hex file when importing the xml file into various device.. importing data flash hex file ensures that all device have the same flash data as original file. what you described of erasing + import may worth a try.

    We don't plan on getting the exact same copy of the data flash hex file when importing into various device. This is a one time production type activity that we rebuild the programmable image to verify the configuration is the same. The benefit of using the data flash hex file is that we can just go look at the configuration CRC. We would see various CRC's on different devices depending on whatever was stored in flash before we imported the offline xml file. When I erase the flash and then program the xml file I see the same CRC on various devices with multiple copies of the xml file. I think this is the solution for this task.

    For regular programming, we will be programming a golden data flash hex file. This activity is just for image building and authentication.

    [Yihe] Do you want to confirm that the data flash file and project xml file are the same?

    Not necessarily. We want to build two copies of the xml and verify they are equal by exporting the data flash hex file and comparing the data flash configuration checksum.

    I will attempt to reset the device through the UCD90xxx Device GUI today and let you know how that goes. As always, we appreciate your help!

    Thanks,

    Jordan S.

  • 0 in reply to Jordan Smallwood
    TI__Guru 57980 points

    Hello Jordan

    Thank you for the explanation. Please let's know how it works.

    Regards

    Yihe

  • 0 in reply to yihe
    Prodigy 250 points

    Hi Yihe,

    Turns out we had a low supply voltage and the pullups on clock and data were too weak. After selecting the 600 Ohm pullups I was able to communicate with the device again.

    Thanks for your help.

    Jordan S.

  • 0 in reply to Jordan Smallwood
    TI__Guru 57980 points

    Hi Jordan

    It is good to know that the issue was solved. I will close this ticket.

    Regards

    Yihe