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: Register/command to distinguish between TPS6591/2/6 and TPS65987/8

Part Number: TPS65987D
Other Parts Discussed in Thread: , TPS65988, TPS65981, TPS65987

Hi, I need to distinguish between the older TPS6591/2/6 and the newer TPS6987/8 PD controller families. This is required to handle incompatibilities between them like the length of several registers (e.g. IntEvent is 8 bytes long in the old controllers, and 11 bytes long in the new ones).

My first approach was reading the content of registers like  VID or DID, but that is not a valid solution because an application firmware can load new values. Therefore, I need a firmware-agnostic solution that can be used by a driver to identify either every single part number, or at least the device family (1/2/6 vs 7/8) via I2C.

Thanks and best regards,

Javier

  • Hi Javier , 

    You can use Version register (0x0F) to differentiate b/w 987/8 & 981/2/6 devices.

    Thanks ,

    Shubha

  • Hi Shubha,

    Thanks for your reply. What values should I expect to distinguish between them? I am reading 0xF7071010 from a TPS65987D with the TI Application Customization Tool, and I don't see how to convert that value to 65987 or something that would tell what device it is.  That register returns a bootloader/application code version, and I don't know how that relates to the part numbers.

    Edit: F7071010 is the firmware version of the base image from TI I used for the firmware: TPS56987_88_F707_10_10.bin. Therefore, that value cannot tell me the part number, right? Or are there unique firmware versions for the two families? Then I would need a reference for that.

  • Hi Javier,

    Shubha is currently out of office, so please expect some delays in communication.

    There should be information in the version that can distinguish some information on part type, but Shubha will need to clarify. I know the 707 portion indicates that you have a 65987DH part, but I do not know what the indication is for 981/2/6 devices.

    Thanks and Regards,

    Chris

  • Thanks for the information, I will wait for Shubha's explanation.

  • Hi Javier,

    If ABXX.YY.ZZ is the FW version, Then 981/2/6 will have AB= 0x00 while 987/988 will have AB=0xF9.

    This will help you differentiate between the two families. 

    Thanks ,

    Shubha

  • Hi Shubha,

    thanks for your answer. Do you mean AB=0xF7 instead of 0xF9? That is the value I read from my TPS65987D.

    By the way, are those values documented anywhere I can use as a reference?

  • Hi Javier , 

    Yes AB=0xF7 or 0XF9. It is dependent on the device  TPS65987DDH or TPS65987DDk.

    You can get this information from the GUI tool while generating the binary. 

    Thanks ,

    Shubha

  • Sorry for insisting on this, but are 0x00, 0xF7 and 0xF9 the only supported values so far? 0x00 for TPS65981/2/6, 0xF7 for TPS65987DDH and 0xF9 TPS65987DDk, but what about TPS65988?


    The distinction is planned for the device driver in the mainline Linux kernel, so it has to be reliable enough to support all existing variants of the TPS6598x in the sense I explained at the beginning: 8-byte interrupt registers for TPS65981/2/6, and 11-byte interrupt registers for TSP65987/8.

    Can we affirm that currently AB = 0x00 will be a TPS65981/2/6, and any other value a newer TPS6598x (TPS65987/8)? Of course I am always talking about current part numbers without trying to foresee future releases.

    Note that I don't have access to every single part number from the TPS6598x family, so I can't get every single AB with the GUI. Hence why I must insist on this and ask for the exact possible values of AB.

    Thanks,

    Javier

  • Hi Javier,

    TPS65988 will be 0xF7 (DH)or 0xF9(DK) .

    Yes you can have a logic that if AB=00 then parts are  TPS65981/2/6 and any other value is newer gen device like TPS6598x (TPS65987/8).

    Thanks ,

    Shubha