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

TPS65987D: TPS65987 not communicating with USB-C power adapter

Del Peck
Prodigy 90 points
Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987, TPS65988

We have designed a board based on the TPS65987 EVM. It will be configured to be a UFP in this design and powered by the USB-C connection.

The ADCIN1 pin is configured for "Configuration Mode 3" which is hopefully UFP / 5V ~ 20V.

If the TPS65987 FLASH is not programmed and we plug the board into a USB-C power adapter, the system resets approximately every second.

Is this normal behavior? It acts like the TPS65987 is not talking to the USB-C power adapter.

We are using the FT4232H to program the SPI FLASH and talk to the TPS65987 using I2C (same as EVM board). We can talk to the TPS65987 over I2C, but we are unable to program the FLASH.

The FLASH appears to program when using the TI configuration utility, but does not verify at the end and appears to still be blank. We have watched the FLASH signals during programming and they appear to be normal (CS, CLK, SI and SO).

Does the FT4232's EEPROM need to be programmed?

Suggestions on how to trouble-shoot this?

Thanks for your help!

Del

  • 0
    TI__Expert 8680 points

    Hi Del,

    I have assigned this to the concerned engineer, he will get back to you soon. 

    Thanks
    Prajith 

  • 0 in reply to Prajith Cheerakkoda
    Prodigy 90 points

    Thanks Prajith!

    We found that if the EVM board has a blank FLASH chip, the EVM board resets the same as our design (approx every 750ms). We are able to program a blank FLASH chip on the EVM board.

    When we try to program the FLASH chip on our design, the Configuration Utility starts to erase the FLASH and then "hangs" indefinitely (see pic). The progress bar stays at 0%.

    Have you seen this behavior?

    --Del

  • 0 in reply to Del Peck
    TI__Intellectual 2370 points

    Hi Del,

    The picture can't be displayed. Can you upload it again by "Insert file" as below?

  • 0 in reply to Del Peck
    Prodigy 90 points

    Here is the a pic of the Utility.

  • 0 in reply to Del Peck
    Prodigy 90 points

    We found the problem. There was a bad solder connection on the FLASH chip (probably the SCK line).

    Thanks for your help.

    --Del

  • 0 in reply to Del Peck
    Prodigy 90 points

    A couple more things...

    It would be nice if the Programming Utility didn't hard-code some of the programming loops. It would have been helpful in this case if one of the FLASH pins wasn't making a good connection the software would time-out and give an error indication of some sort rather than just "hang".

    I have a question about the ADCIN1 pin. We had it configured so that it should have configured the TPS65987 as a UFP 5V~20V in the event the FLASH didn't configure the chip. That did not happen. If the FLASH was not programmed the TPS65987 continually reset every 750ms waiting for the FLASH. Would you explain how the ADCIN1 pin should work in a little more detail?

    It looks like the FLASH chip you are using on the EVM is going end-of-life (MX25L8006EM1I-12G). Do you have a suitable replacement for this part?

    Thanks for your help!

    --Del

  • 0 in reply to Del Peck
    TI__Intellectual 2370 points

    Hi Del,

    For more details of how the ADCIN1 pin works, you could find the boot process in App notes as below:

    TPS65987 and TPS65988 SPI Flash Firmware Update Over I2C

    1. When the device is powered on, initial device configuration will be loaded from ROM on the device. (boot code)

    2. When the initial device configuration is complete, the boot code samples the BUWPOWERZ pin to determine the start-up behaviour of the device:

        if the SRAM has a valid patch bundle, the patch bundle is applied.

                 --------->> if the content on SRAM is not valid, the boot code checks if an external flash is present. If the flash present and has a valid patch bundle                                 on it, the patch bundle is applied.

                                          --------->> if the external flash is not present or the content on it is not valid, the boot code will check for the presence of a host. If the                                                        host is present, the boot code waits indefinitely for the host to provide patch or proceeds with the default configuration                                                                decided by ADCIN1.

                                                                   --------->>if no host is present or a patch bundle is not available, then it is assumed no patch bundle is to be loaded.                                                                                  At this point, the device uses the code existing in the current ROM version.

    Hope this helps you, thanks.

  • 0 in reply to Bing Hwang
    Prodigy 90 points

    Thanks - that helps.

    You can close this case.

    --Del