• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 467 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: TPS65987D I2C2 Address

Jeff Welder1
Prodigy 240 points
Part Number: TPS65987D


Hello,

In doing some development work on the TPS65987D, I'm running into two i2c issues. One regarding addressing, and the other with patching using i2c. 

Addressing-

For some reason when trying to communicate on the I2C2 pins the chip stopped responding to address 0x38 and I now have to use address 0x20.

Address 0x20 should be the address for I2C1 which is not connected to our micro.

See annotated table from TPS65987D Datasheet:
image.png
I found an e2e forum post that accurately describes what I am seeing with some added information I haven't been able to verify, however, they did not seem to come to a conclusion. I have not attempted to change any registers at this point.
I think I can carry on using address 0x20 for interfacing to I2C2, but I would like to ask if there is any clarification for when I2C2 would respond to 0x20 and NAK 0x38 when I would expect the chip to always be at address 0x38. I'm wondering if I need to support both addresses (0x20 & 0x38) based on which address responds with an ACK in my application code?

Patching over I2C-
As a secondary question. When I send a PTCr command, and poll for execution, I never see the device come back in PTCH mode, it always goes back to APP. (Note this is using address 0x20 as 0x38 will not ACK)
Process:
  1. Check mode register for APP
  2. Write Interrupt Mask for Ready for Patch bit
  3. Write DataX (0x09) for PTCr  AppConfigReset, DevicePatchReset, DevicePatchResetKey = 0xBE, and AppConfigResetKey = 0xEF
  4. Send PTCr 4CC to CMD1 (0x08) 
  5. Poll CMD1 (0x08) for PTCr which turns into 0x00 / Success
  6. Read MODE register (At this point, it still responds with "APP" instead of expected PTCH)

Please let me know if the process here is wrong, I have not come across good documentation for SPI-less flash update. I think it is straight forward once I can get the Patch mode working, but I can't get the device into the correct mode.


Thanks for the help,
Jeff 
  • 0
    TI__Genius 12700 points

    Hi Jeff,

    As for the addressing issue, which ADCIN2 setting are you using? Are you using the same port that you were originally using for the other address? Also, I wasn't able to see the image that you attached, could you try to reattach it or use it in a different format? 

    For the patching issue, I think you are missing some steps in the process. You can reference the SPI Less Host Programming Over I2C Application Note as it describes the full SPI-less patching process in detail and there is also a list of commands that you need to use as well as an execution flow.

    Thank you,

    Hari

  • 0 in reply to Hari Patel1
    Prodigy 240 points

    Hi Hari,

    ADCIN2 is grounded. The port is solely attached to I2C2 and our micro. Here is the image I attempted to attach previously:


    I have been attempting to use the SPI-Less Host Programming guide but, the documentation is not very complete. I have thoroughly reviewed the document before posting my question. The section of interest is as follows:

    Note: If the host intends to load a different patch bundle (either apllication configuration and/or
device patch) after the device has already transitioned to the 'Application' mode (either by
loading the default configuration or after a previous patch download sequence), the above
patch download sequence shall be preceeded by a 'PTCr' (Patch Reset) and succeeded by a
'Gaid' (Warm Restart) 4CC command

    Could you point me in the right direction for what steps I am missing in trying to move from 'APP' to 'PTCH' mode with my steps outlined above?

    Regards,
    Jeff


     

  • 0 in reply to Jeff Welder1
    TI__Genius 12700 points

    Hi Jeff,

    The setting may be set to where I2C1 and I2C2 are the same, I would recommend checking the TBT Controller I2C Port field in register 0x27 to see which I2C it's set to. You can also check to make sure you're using the latest GUI version 6.1.1.

    For the patching process, what is your BUSPOWERZ configuration set to? The host should wait until it receives the "READY_FOR_PATCH" notification from the PD device. Also, are you sending the soft reset "Gaid" command after "PTCr"? Once you have verified this and get the notification, you can start the patch loading process in the order shown below: 

    There is also example code shown in section 3.1.3 of the document.

    Thank you,

    Hari