• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 33 subscribers
  • Views 454 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: UsbHostPresent bits reading [00], and POR issue possibly due to PD Protocol Error

Eric S
Expert 5640 points

Part Number: TPS65986

I have 2 questions I hope you can help answer:

  1. Is there any known reasons that the UsbHostPresent bits may not get set to something other than [00], when configured as an UFP and VBUS is definitely present?   Using these bits by the O/S to know when charger is present, but not getting reliable results.
  2. We have potential for bus contention on SPI between TPS65986 and other device talking to SPI Flash.  After initialization, TPS65986 is not supposed to access Flash anymore, but we're finding that some conditions (believed to be PD Protocol Errors) are causing POR event, and of course it then needs to access Flash to re-initialize. 
    1. Is this expected for possible Protocol Errors to cause POR?  (or other events not related to disruption of power to the device)
    2. To avoid contention, currently using the TPS65986 Chip-select to disable SPI buffer between other Host and SPI Flash.  This works to isolate that Host from the bus, but worried it could cause a first read attempt failure when TPS65986 tries to boot.  If first read fails, will it try again, or go to alternate boot-mode (which we don't support)?

  • 0
    TI__Genius 10370 points

    Hi Eric,

    Look below for my comments/feedback in red: 

    1) Is there any known reasons that the UsbHostPresent bits may not get set to something other than [00], when configured as an UFP and VBUS is definitely present?   Using these bits by the O/S to know when charger is present, but not getting reliable results.

    My understanding of your question is that if VBUS is present and NOT the source, then UsbHostPresent bits will show either 01, 10, or 11. If you're template is configured as a UFP, but tone of he PowerPaths is set as a source, then the UsbHostPresent bits will show 00 when it's sourcing to VBUS (look below for table). 

    Feel free to take a look at the Host InterfaceTRM here: http://www.ti.com/lit/ug/slvuan1a/slvuan1a.pdf

    2) We have potential for bus contention on SPI between TPS65986 and other device talking to SPI Flash.  After initialization, TPS65986 is not supposed to access Flash anymore, but we're finding that some conditions (believed to be PD Protocol Errors) are causing POR event, and of course it then needs to access Flash to re-initialize.

    a) Is this expected for possible Protocol Errors to cause POR?  (or other events not related to disruption of power to the device)

    The PD controller could go into HardReset, and there are multiple events that could cause this (please refer to the TRM above and the USB PD2.0/3.0 specs for hard reset details). When a HardReset occurs,  theTPS65986 re-boots.  Every time a re-boot occurs, the SPI lines are active and the PD controller will talk to the FLASH chip. 

    b)To avoid contention, currently using the TPS65986 Chip-select to disable SPI buffer between other Host and SPI Flash.  This works to isolate that Host from the bus, but worried it could cause a first read attempt failure when TPS65986 tries to boot.  If first read fails, will it try again, or go to alternate boot-mode (which we don't support)?

    I don't recommend to use a chip select disable to the SPI buffer. When a hard reset occurs, the device will re-boot which will cause the device to talk to the FLASH via SPI. This is normal operation. If the first read fails, the device will get stuck in BOOT mode. 

     

    I hope this helps and If this answers your question, PLEASE select  This resolved my issue