• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 306 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS65986: TPS65986 cannot load application code

Esa
Expert 3250 points

Part Number: TPS65986

Hello,

We have managed to capture a situation, where TPS65986 cannot load application code even though only single region is corrupted.  

The differences are as follows: the first 4 bytes, i.e. Region Pointer (RPTR), from the region1 (high region) are corrupted (please see image in the file below for a quick glance).

TPS65986 Region 1 pointer.pdf 

To best of our knowledge, this should not prevent TPS65986 from loading region0 (low region). Could you please explain why region0 cannot load? Boot Flags register value is 0x00F490B8, which indicates, among other things, that there is a CRC error with region0. Could you please explain how this is possible?

-------------------- 

I checked the attached binaries and I can see your highlighted difference—that RPTR1 appears incorrect in the actual.bin. I also notice that the region headers in both bin files are 0xFF. I understand there is a worry about EC operation in this issue. I think one way to explain current PD operation is that there is a CRC issue with region 0 and region 1 fails to boot due to incorrect RPTR1.

Our recommendation is to ensure a valid full flash image with correct headers and pointers is set in device flash before  EC based updates occur. Can you use the SPI programmer mentioned to perform a full update?

Regards,
Scott

------------------------

Thank you for your response! Please find our comments below.

You said: “I also notice that the region headers in both bin files are 0xFF.”

Considering the Figure 1 in [1], “Region 0 Pointer (RPTR0)” and “Region 0 Offset (AOFF0)” should be OK in both files.

The documentation [2] also says:

“Each header contains a region pointer (RPTR) that holds the address of the physical location in memory where the low-region application code resides. Each also contains an application-code offset (AOFF) that contains the physical offset inside the region where the TPS65982 application code resides”

Based on the image and the textual description, we believe region0 should be OK. Could you please elaborate: is there something else that should be included in a region header? Perhaps something between a region pointer and region offset? TI Application Customization Tool does not seem to generate anything but 0xFF between those values.

You said: “I think one way to explain current PD operation is that there is a CRC issue with region 0 and region 1 fails to boot due to incorrect RPTR1.”

As for the "there is a CRC issue with region 0", that was our observation as well, but could you please elaborate why region 0 has a CRC issue even though the contents should be OK?

As for the "region 1 fails to boot due to incorrect RPTR1", this is clear.

You said: “Our recommendation is to ensure a valid full flash image with correct headers and pointers is set in device flash before  EC based updates occur.”

At the moment, we are considering to remove region header update (write between absolute addresses 0x0000 – 0x1FFF) as it is already written before any possible field updates.

You said: “Can you use the SPI programmer mentioned to perform a full update?“

Yes. That is what we do during manufacturing.

[1] http://www.ti.com/lit/an/slva783a/slva783a.pdf, p. 3

[2] http://www.ti.com/lit/ug/slvuah7b/slvuah7b.pdf p. 11

  • 0
    TI__Expert 4455 points
    Hi Esa,

    We are seeing an issue where a device will not load firmware if the low region firmware is corrupted in a specific way.

    The issue involves the low region firmware having a correct Device ID (0xACE00001) but corrupted data elsewhere. The outcome is the device will not try to load high region firmware even though the low region is corrupted. In your actual and expected flash view, I see the low region Device ID at 0x2000 is correct.

    You could try erasing the low region completely and check if the high region will load.

    Regards,
    Scott
  • 0 in reply to Scott T
    TI__Expert 3250 points

    Hi Scott,

    As for "The issue involves the low region firmware having a correct Device ID (0xACE00001) but corrupted data elsewhere", could you please point out the corrupted memory addresses with respect to the beginning of actual.bin? If we compare, we cannot find any errors at memory addresses concerning low region.

     

    As for "The outcome is the device will not try to load high region firmware even though the low region is corrupted", if the low region firmware is corrupted, then why the Figure 3-5 Flash Read Flow in http://www.ti.com/lit/ug/slvuah7b/slvuah7b.pdf gives impression that the device would try to load high region as a result of either “Invalid Config” or “Invalid App Code” from low region?

     

    The reason we ask these specific questions is that we need to understand the actual behavior of TPS65986 with respect to the interpretations we have made based on the documentation available.

    Regards,
    Esa

  • 0 in reply to Esa
    TI__Expert 4455 points

    Hi Esa,

    I mention this issue because I remember there was concern that the low region was showing corruption in the boot flag register and I see the Device ID in the flash image for low region. I am not sure this issue is occurring in the case you describe but I see enough similarity to bring it up as a possibility.

    I agree with your second point. Normally we expect the device to read the high region except the issue I mention can cause the device not to follow that flow.

    Regards,
    Scott