• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 16 subscribers
  • Views 270 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

TRF7960: Read Single Block issue

TRF7960: Last Byte of FIFO has wrong value

Martin Korn
Prodigy 90 points
Part Number: TRF7960

Hi,

we produce devices with TRF7960 for several years now and recently we discovered the same issue with the last byte of the FIFO as described here:

https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/648403/trf7960-read-single-block-issue/2411306#2411306

So we have several devices here, that show this behavior within 10 minutes of permanently reading the same block of a tag. But most of the devices work as expected and don't show the error over several hours. All devices have the same PCB, same software, tested with the same tag. 

SPI traces of the error are available, if needed.

Is there a bad batch of chips known for the TRF7960 ? is there a workaround for this issue ?

best regards,

Martin

   

  • 0
    TI__Genius 13095 points

    Hello Martin,

    I'm not aware of any bad batch of TRF7960. Also there is no known workaround for such an issue.

    Please provide the SPI traces of the error and I will check it.

    Best regards,

    Andreas.

  • 0 in reply to Andreas Mueller
    Prodigy 90 points

    Here is a screenshot of the SPI Trace with the wrong value in the last byte of the FIFO:

    and here the same with the correct data:

    Here is also the complete trace (bad value marked with marker A and good value marked with marker B, file can be opened with Pulseview)

    bad_read_single_block.zip

    It seems, that the wrong Byte is part of the CRC, which is normally not in the FIFO. Could it be, that there was one byte of the user data is lost and replaced with a CRC Byte ?

    best regards,

    Martin

  • 0
    TI__Genius 13095 points

    Hello Martin,

    thanks for the SPI traces.

    It will take a while until I can evaluate it, as I also have other urgent tasks to do.

    In the meantime you could check all the mentioned aspects in the old E2E thread, you referenced. You could compare the SPI traces with yours and try to analyze for any mentioned improvements.

    Have you done any changes (maybe even unintended) to the boards or related components?

    Best regards,

    Andreas.

  • 0 in reply to Andreas Mueller
    Prodigy 90 points

    Hello Andreas,

    As the faulty devices were out of production, I'm quite sure, there were no changes in components.

    Here is also a SPI Trace of the init phase of the TRF7960:

    4405.trf7960_init.zip

    I hope the analysis of the traces give same new hints.

    best regards,

    Martin

  • 0
    TI__Genius 13095 points

    Hello Martin,

    I analyzed the initialization SPI trace although it was a challenge to get the corresponding viewer installed. Anyway, I found some missing Idle command (0x80) + 1ms delay after the Software Initialization (command 0x83). This sequence (0x83, 0x80, at least 1ms delay) is recommended to give some time for full initialization. Also it might be helpful to initialize the NFC Target Detection Level register (0x18) with the value of 0x00. If possible could you please try to implement these changes in the initialization sequence?

    Best regards,

    Andreas.

  • 0 in reply to Andreas Mueller
    Prodigy 90 points

    Hello Andreas,

    I implemented the suggested changes in the init phase, but it did not make any difference: the device still gives bad values after a while. Here is a trace of the new init:

    trf790_init_2.zip

    best regards,

    Martin