• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 139 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.

TPS25762-Q1: Patch update not completing

Matt Cardwell
Prodigy 70 points
Part Number: TPS25762-Q1


Tool/software:

Hello all,

I'm trying to get the patch downloaded to the TPS25762 but it doesn't seem to complete.

The patch is being sent via I2C2.

One initial question is -- the patch data is supposed to be sent out in 256 byte chunks.  I'm assuming that is PATCH_SIZE / 256 +1 number of chunks, each starting with the address and data register.  What happens when the patch isn't 256 byte aligned (as in my case)?  Only send the remaining data or pad out t he rest of the 256 bytes?

Everything is going smoothly until the patch is told to complete.  After issuing PBMc, both the CMD2 and DATA2 registers read as zero but the MODE register remains in PTCH until the 5 second timeout expires (and then reverts to APP).  The IRQ doesn't de-assert until after the 5 second timeout. 

Here's the flow and the results:

Read INT_EVENT2 until it is non-zero  (not INT_EVENT1 since we're using I2C2)
Result:  0x0B

Read MODE until it is "PTCH"
Result: 0x04 0x50 0x54 0x43 0x48  (PTCH)

Configure patch:
Write to DATA2:  (patch size is 15744 / 0x3D80) Patch address is 0x35
0x23 (address)
0x11 (DATA2 reg)
0x06 (length)
0x80 (Patch LSB)
0x3D (Patch MSB)
0x00 (Patch upper LSB)
0x00 (Patch upper MSB)
0x35 (Patch address)
0x32 (Patch timeout - 5 seconds)

Write PBMs to CMD2
0x23 (address)
0x10 (CMD2 register)
0x04 (command length)
0x50 (P)
0x42 (B)
0x4D (M)
0x73 (s)

Read CMD2:
Wait until byte 1 is zero and that bytes 1-4 are not "!CMD"
Result: 0x04 0x00 0x00 0x00 0x00

Read DATA2:
Wait until byte 1 is zero
Result: 0x40 0x00 0x00 0x00 ...


Write out the patch in 256 byte chunks:
Loop:
    0x35 (Patch address)
    0x11 (Data register)
    0x?? (Patch data - 256 bytes long)
End loop


Wait 1ms

Write PBMc to CMD2
0x23 (Address)
0x10 (CMD2)
0x04 (command length)
0x50 (P)
0x42 (B)
0x4D (M)
0x63 (c)

Read CMD2 until byte 1 is zero and bytes 1-4 are not "!CMD"
Result: CMD2: 0x04 0x00 0x00 0x00 0x00

Read DATA2 until byte 1 is zero
Result: DATA2: 0x40 0x00 0x00 0x40 0x80 ...

(IRQ never deasserts until timeout)


Read MODE until it is in "APP"
Result: MODE: 0x04 0x50 0x54 0x43 0x48  (PTCH)

Lasts until timeout, then switches to APP.

So clearly I'm talking to the part but I'm not entirely sure why it is remaining in PTCH mode instead of going into APP.  I'm not issuing the PBMe command because IRQ is supposed to be released once the patch is downloaded and the CMD2 and DATA2 register is 0x00.  Unfortunately that isn't happening.

Any suggestions would be greatly appreciated!

-Matt

  • 0
    TI__Mastermind 46871 points

    Hello Matt,

    • Are you booting the TPS25762-Q1 in MCU mode; TVSP Index 1 or 3?
    • Have you tried writing the PBMe 4CC command, regardless of the IRQ status, after writing the patch bundle data and reading 0s from CMD2 and DATA2?
    • Have you tried transmitting the patch bundle all at once instead of in 256 byte packets? Writing the patch bundle data in burst mode, instead of in 256B packets, also works and reduces write time.

    Attached below is a Saleae capture of writing a patch bundle via PBM. Instead of checking the INT_EVENT1 register in the beginning, I start the protocol when GPIO9 is pulled low instead.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/196/TPS257x2_5F00_MCU_5F00_BOOT_5F00_PBM.sal 

    Thank you and best regards,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 70 points

    Hi Seong,

    Yes, I'm booting with TVSP index 1 (MCU mode, patch over I2C2).  The device is responding to address 0x23 so I know this is part is working.

    I have not tried writing the PBMe regardless of the IRQ status.  The MODE register keeps saying it is still in patch mode so I figured something else must be going on.  I'll give that a shot.  The written portion of the documentation says that after 110ms (or so) that the IRQ will be released.  Can I issue the PBMe immediately after the CMD2 and DATA2 registers are clear?  Or should I delay 110ms or so before doing PBMe?

    I got the impression from the SLVAFF7B document (Firmware update procedure) that you had to packetize the patch in 256 byte lengths.  You're saying that I can send all 15744 bytes with just one address/DATA2 message (followed by 15744 bytes)?  That would be great and significantly speed things up.

    We currently wait for the GPIO9 to be pulled low before querying the INT_EVENT2 register (using #2 since we're over I2C2).  If you think we can skip that step that would be great.

    After issuing the PBMe command how do I know that the device is using the patch vs. reverting to the ROM unpatched version?  Is there a way to confirm that the patch was successful and that the PBMe command doesn't just abort the patching?


    Thanks for your assistance!

    -Matt

  • +1 in reply to Matt Cardwell
    TI__Mastermind 46871 points

    Hello Matt,

    SLVAFF7B requires some scrubbing. Apologies for any misdirection.

    You can write PBMe immediately after confirming the CMD2 and DATA2 registers are clear without waiting 110ms.

    Please see the Saleae capture I shared in my last message. You will see after the PBMs command is sent and 0's are read from the CMD2 and DATA2 to confirm the command was successful, I only address the DATAx.TargetAddress, 0x35, once and write all the patch bundle data in one go (see image below). I do not write the DATA register after writing the target address, 0x35, in this step.

    In the Saleae capture, you will note that I initially write 0x04 (length byte), 0x47, 0x61, 0x69, 0x64 to the CMD register. This is a 4CC command ("Gaid") which executes a soft reset. Then I read the IRQ/GPIO9 status and begin the protocol when IRQ/GPIO9 is asserted low, which indicates the TPS257x2 is in "PTCH" mode. In conclusion, you do not need to query the INT_EVENT2 register and can skip this step.

    After issuing the PBMe command, I wait 1 second before reading the MODE register. As you already know, you want to read "APP" at this point.

    If you are programming a patch bundle generated with a new base FW version, one way to confirm if the patch write was successful is by reading FW Version from the FW VERSION register, 0x0F. At the time when I saved the Saleae capture, the latest base FW was F311.03.05 (see image below).

    I suppose another way would be to test functionality. For example, if the application configuration you are writing configures a specific SourceCap, you can use a TI-PD-ANALYZER to monitor the PD communication and confirm the TPS25762-Q1 is advertising the correct SourceCap to the connected Sink device.

    Hope this helps,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 70 points

    Hi Seong,

    Five minutes into my day and this took care of it.

    Thank you so much!

    -Matt

  • 0 in reply to Matt Cardwell
    TI__Mastermind 46871 points

    Hi Matt,

    I'm glad you got it working. Can you please please clarify the following:

    1. Are you issuing the PBMe command now?
    2. Are you still writing the patch bundle data in 256B packets?

    BR,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 70 points

    Hi Seong,

    1. Yes, I'm now sending the PBMe command.

    2. I liked the idea of sending the patch down all at once but how our I2C driver is written it didn't work out well.  So I'm doing 256 bytes at a time.  Seems to work fine and confirmed the patch is loading properly.  I turned up the speed to 1MHz for the clock which also helps with the speed.

    Thanks again for the help!

    -Matt

  • 0 in reply to Matt Cardwell
    TI__Mastermind 46871 points

    Hi Matt,

    Thank for sharing. Happy to help!

    I will be closing this thread. Please start a new one for any oyher queries.

    BR,

    Seong