• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 3 answers
  • Subscribers 30 subscribers
  • Views 507 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.

Original question:

TMP117: Unique ID for NIST traceability - format from the 6 bytes in EEPROM

TMP117: TMP117 NIST byte order and EEPROM4 address

Matthias Szusdziara
Prodigy 30 points
Part Number: TMP117
Other Parts Discussed in Thread: TMP116,

Hi all,

for one, i ended up with the same question as in TMP117: Unique ID for NIST traceability - format from the 6 bytes in EEPROM.

Sadly, this was resolved via email, so it would be great to have the response posted here.

The other issue that is bugging me is with EEPROM4:

Even in its revision from April 2021 (SNOSD82C), EEPROM4 is referred to on pages 18 and 30, with page 30 also explicitly mentioning four EEPROM locations.

However, neither the register map nor anything else in the document indicates the address of EEPROM4.

I figured that the TMP116 in fact had 4 EEPROM locations, occupying addresses 0x05 to 0x08.

However, for the TMP117 the register map indicates 0x05, 0x06 and 0x08 for EEPROM1, EEPROM2 and EEPROM3 respectively, while 0x07 is occupied by the Temp_Offset register.

From the addressing scheme, my guess now is that one cell got sacrificed for the Temp_Offset and TMP117 in fact only has three EEPROM cells instead of four with the mentioning of EEPROM4 in the datasheet being a leftover from TMP116. However i can't know for sure and if i am wrong i would like to know the address of EEPROM4.

Can someone please help clarify the issue?

Thanks in advance.

kind regards,

  • 0
    TI__Mastermind 43785 points

    Hi Matthias,

    There's no public documentation on the decoding of the ID. We must manually look up the production data associated with the ID. Since this is a manual process, we are only doing it for our internal investigation and quality control. We are not providing any additional information to customers based on their IDs at this time. 

    You are correct that TMP116 and TMP117 both have 4 EEPROM locations, but one of them was repurposed for offset in TMP117.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 30 points

    Hi Ren,

    There's no public documentation on the decoding of the ID.

    Does this also extend to byte/word order?

    Because in the scenario at hand the data is not going to be used for NIST tracing but more or less for use in a serial number instead. Hence byte order is all i am asking here.

    We must manually look up the production data associated with the ID. Since this is a manual process, we are only doing it for our internal investigation and quality control. We are not providing any additional information to customers based on their IDs at this time. 

    Thank You for pointing that out.

    It would be great to see the EEPROM location issue fixed in the datasheet in a future revision. (Maybe you can open a ticket somewhere so this does not get lost?)

    IMO, it would also be very helpful to have a short note like

    We are not providing any additional information to customers based on their IDs at this time.

    added to the NIST setion, just for people to know that they can stop searching  for it (and maybe contact TI directly if required).

  • 0 in reply to Matthias Szusdziara
    TI__Mastermind 43785 points

    Hi Matthias,

    In a scenario where TI decoded your ID, you would have to tell us the contents of the 3 registers. Therefore, you can store the bytes however you like, as long as you can retrieve the information. I2C, as well as our own datasheet, specifies leading bit as the most significant bit in every frame. Our datasheet also shows that our 16 bit registers are read/written with the most significant 8 bits first. See Figure 7-10. Does this answer your question?

    Unfortunately, I know what you mean by ticket. Let's leave it at that. I'm not able to provide a timeline for datasheet changes.

    thanks,

    ren

  • 0 in reply to Ren Schackmann
    Prodigy 30 points

    Hi Ren,

    thanks for Your response.

    As far as my question is concerned: It was not exactly the answer i was looking for, but from Your response i sense that this answer just does not exist. So with that in mind: Yes, this answers my question.

    I'm not able to provide a timeline for datasheet changes.

    I am well aware of that. As long as it gets covered in the next revision, i am happy...

    Thank You for Your support.

    Kind regards,

    Matthias