• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 472 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.

TPS65986: FLwd 0xFF return code

Eric S
Expert 5590 points

Part Number: TPS65986

I see that 0xFF return code should be considered an error in Write command.  It appears that once 1 FLwd command fails, all subsequent FLwd commands will fail.  Is this expected?  What needs to be done to retry FLwd commands once 0xFF return code is encountered, and is there any way to get more details from the TPS65986 in terms of why FLwd failed and/or where it failed?  (for writes with several Bytes of data, since FLwd can be 1 to 64 Bytes).

Thank you.

  • 0
    TI__Genius 16230 points
    Eric,

    I'm assuming 'FLad' was executed before the first write attempt.

    FLwd returns '-1' if the flash is busy/in-use, or the write attempt crosses a page boundary (.i.e. if (write-address + length) > ((write-address & 0xffffff00) + 0x100). At what address (of the sFLASH) are you attempting to write the 64 bytes?

    -/Praneet
  • 0 in reply to Praneet Kumar
    TI__Expert 5590 points
    FLad was executed, and starting address is always page-aligned. I don't see how the sFLASH could be busy, since they have to wait for return code before executing the next FLwd command anyway. They are seeing this when updating Region0/Region1 FW code, and doing several consecutive 64-Byte writes. The first 4 writes are always okay, about 30% of the time the 5th write fails. It's intermittent, which is perplexing.
    They are using 400kHz I2C clock, do most customers use this speed? Have we ever seen issues with 400kHz, particularly with consecutive 64-byte block writes? Interestingly, the first 4 blocks would fill a page, then the 5th would be the start of a new page... is there any possibility of a problem or delay with address auto-increment when crossing that page boundary?

    Also, when they do get a 0xFF return code, all subsequent FLwd attempts appear to also fail. Is there a recovery/retry method when 0xFF return code is seen?
  • 0 in reply to Eric S
    TI__Genius 16230 points
    Eric,

    We sometimes see this failure (0xFF) on first FLwd if its executed immediately after FLem, but the subsequent FLwd succeeds. We use I2C in fast-mode when validating the flash-update sequence, but never saw the intermittent issue that you listed above.

    I'll try recreating the issue on my setup, but I'm afraid I can get started w/ this activity only by early next week - Please let me know if it's a concern w.r.t your customer's test schedule. I might as well need your help to recreate the issue w/ a test/debug binary that I'd be sharing, and capture the state-history logs.

    -/Praneet
  • 0 in reply to Praneet Kumar
    TI__Expert 5590 points
    Praneet, I would like to continue to investigate this, and see if you can replicate the issue on your setup. Another question that may have an interesting correlation... When you sometimes see this failure on first FLwd immediately following FLem, does that failure example get resolved if you reduce I2C clock to 100kHz? Their issue is resolved at 100kHz, but this makes updates/writes too lengthy. They have thoroughly investigated any potential signal integrity issues, and did not find anything out of spec.
  • 0 in reply to Eric S
    TI__Genius 16230 points
    Eric, I'll get back to this issue, and share my feedback by end of this week.

    -/Praneet
  • 0 in reply to Praneet Kumar
    TI__Genius 16230 points
    Eric,

    As requested on email, I'll need your help to test the engineering patch on customer's platform - I'll close this post and continue to work w/ you over emails. The end results/findings can be posted on this thread.

    -/Praneet