TRF7970A: Last byte sent to MSP430 overwritten by CRC

Hi,

  Is the problem observed in the very first read cycle or you might have repeatedly read the UID and it was one of the later read cycles that you saw the corruption? In another word, how long does it take you to see the E0 overwritten by the CRC? When you start a read cycle, did you do a SOFT INIT? 

  Can you also check if if register at 0x18 is initialized to 0?

 Please also tell me if you are referencing the TI example firmware (SLOC297)? If you run the SLOC297 firmware, do you see the same issue?

Hi Charles,

I have seen the problem occur both on the first read cycle and on repeated attempts, intermittently.  When performing the 16-slot inventory, I have also seen this issue at least once in every slot.

A SOFT INIT is issued and register 0x18 is confirmed to be initialized to 0x00.  I am referencing SLOC300, where the firmware does work without issue across multiple boards.

Hi,

Brendon Lovejoy said:

I am referencing SLOC300, where the firmware does work without issue across multiple boards.

 SLOC300 is the firmware  for theTRF7970AEVM that has been EOL'd and the firmware used on it is extremely out of date and has known bugs which were never resolved. Having said that, I'm curious as to the subtle difference between your custom firmware and SLOC300 as you mentioned SLOC300 does not exhibit the issue. 

Please use the latest RFID reader firmware (http://www.ti.com/lit/zip/sloc297) as a reference for your design for best success. 

Hi Charels,

I apologize for the long delay as we worked to get the SLOC297 firmware working on our system.  We tested and still see the same issue with SLOC297.  In that time, we performed additional testing and made several other observations.  As shown in the below figure, we determined that by adding a delay after the TX confirmation, we could temporarily resolve the issue.  However, the length of the delay had a strange effect.  Using no-ops instead of timer-based delays, we discovered that the issue maintained a stable periodicity with the number of no-ops injected.  For example, 200 no-ops shows the issue while 400 no-ops clears the issue.  Unfortunately, picking a delay where no issues occur on one tag will not work, as other tags show a similar pattern, but with the "waveform" shifted.  There is no "one-delay-fits-all".

We also experimented with other hardware, including our crystal oscillator and capacitors to no avail.  However, an interesting effect was observed when flexing the board.  Flexing the board when pushing down on top increases failures substantially, while pushing up from the bottom greatly reduces failures.  This was also seen by gently applying pressure on either sides of the TRF IC with plastic tweezers.  This leads us to believe it is a hardware issue.  We verified that soldering and board traces are good.

Does any of this data point towards any known issues?  We reviewed the errata document but could not find any obvious solutions for this problem.

Hi Brenden,

Did you always start a read cycle with a SOFT_IN? The SOFT INIT is meant to reset the state machines on the device among other things. TI's recommendation would be to begin each read cycle with a SOFT INIT to ensure all state machines in the device are refreshed and the device is kept in a known good state. 

Yes, we have tried performing SOFT INIT before each read cycle and still experience the error with the last byte. 

Hi Brendon,

  Just to clear, can you answer a few questions?

- The last byte you are talking about now is still the UID or other blocks of the tag? In your original thread description, it was the UID that was corrupted. 

- In your original description, you were able to resolve the issue using the two methods "Two methods that appear to resolve this issue are detuning the antenna/signal (by introducing metal in the field or by changing the 0x0A register) or by changing the modulation depth in the 0x09 register (100% OOK causes the issue and any ASK modulation between 7-30% appears to resolve the issue).  ". Is this still true with the latest codebase based off of SLOC297?

 - In one of your replies you mentioned "I am referencing SLOC300, where the firmware does work without issue across multiple boards." I'm very surprised that SLOC300 works but not SLOC297. 

Brendon Lovejoy said:

As shown in the below figure, we determined that by adding a delay after the TX confirmation, we could temporarily resolve the issue.  However, the length of the delay had a strange effect.

Where did you get the idea to add delays. Is it from some archived posts you reference? The reason I ask is because talking to an expert (he is no longer with our team though) he said there is no reason to add any delay although a few posts seemingly was resolving the issue by adding the delay without really knowing the reason why the delay is needed. 

Brendon Lovejoy said:

We also experimented with other hardware, including our crystal oscillator and capacitors to no avail.  However, an interesting effect was observed when flexing the board.  Flexing the board when pushing down on top increases failures substantially, while pushing up from the bottom greatly reduces failures.  This was also seen by gently applying pressure on either sides of the TRF IC with plastic tweezers.  This leads us to believe it is a hardware issue.  We verified that soldering and board traces are good.

Have you tried using the TI hardware? Can you repeat the same corruption?

Hi Charles,

My responses to your questions are below in order:

• Yes, the byte experiencing the error is the last byte of the UID send via SPI from the TRF to the MSP.  If we also read the additional 2 bytes for the CRC, then the error occurs on last byte of the CRC sent.  It is always the last byte read from the FIFO.
• Yes, detuning the antenna and using ASK modulation still resolves the problem with SLOC297 and SLOC300.
• I apologize for the confusion here.  What was meant was that the SLOC300-based code has worked successfully across multiple boards throughout development, but we have identified several select boards (running SLOC300) that show this failure.  This is why we believe is may be a hardware issue.  Given that this issue only occurs with select boards (and each board fails with select tags), it is difficult to understand how many boards would be affected.  A tag that fails on one board will pass on another, and vice-versa.
• We did consult multiple archived posts, although the reasoning for adding the delay was that it was theorized that too little time between the TX interrupt and RX interrupt may contribute to the problem.  While we understand that this is not how interrupts function, we decided to try it anyways and were equally surprised with the result.
• Since this issue only occurs on select boards paired with select tags, we do not believe that TI hardware is likely to catch the issue.  Perhaps if we swapped TRF ICs, but with a limited number of failed boards, this is a last resort.

Hi Brendon,

Brendon Lovejoy said:

Yes, the byte experiencing the error is the last byte of the UID send via SPI from the TRF to the MSP.  If we also read the additional 2 bytes for the CRC, then the error occurs on last byte of the CRC sent.  It is always the last byte read from the FIFO.

ok.

Brendon Lovejoy said:

• Yes, detuning the antenna and using ASK modulation still resolves the problem with SLOC297 and SLOC300.

I cannot understand why antenna and ASK would resolve the issue. What did you change exactly for detuning and modulation? Can you show what settings you changed compared to the original?

Brendon Lovejoy said:

I apologize for the confusion here.  What was meant was that the SLOC300-based code has worked successfully across multiple boards throughout development, but we have identified several select boards (running SLOC300) that show this failure.  This is why we believe is may be a hardware issue.  Given that this issue only occurs with select boards (and each board fails with select tags), it is difficult to understand how many boards would be affected.  A tag that fails on one board will pass on another, and vice-versa.

I suppose all the boards you mention here are of the same design, correct?

I suppose all the tags you mention here are of the same 15693 RFID tags from the same vendor, correct?

For those tags that failed, can you use the TI hardware to read them? Do you find the same issue? What is the result?

Brendon Lovejoy said:

We did consult multiple archived posts, although the reasoning for adding the delay was that it was theorized that too little time between the TX interrupt and RX interrupt may contribute to the problem.  While we understand that this is not how interrupts function, we decided to try it anyways and were equally surprised with the result.

As mentioned, our expert does not think a delay is warranted but rather a SOFT_INIT is required for each cycle. I understand that you have had SOFT_INIT in each cycle but to have no effect which suggests that this may not be a software issue. After the TX complete, it would take quite some time to receive the 7-byte UID as the transmission happens at only 106kbps which is considerably slower than the SPI baud rate.  

Brendon Lovejoy said:

Since this issue only occurs on select boards paired with select tags, we do not believe that TI hardware is likely to catch the issue.  Perhaps if we swapped TRF ICs, but with a limited number of failed boards, this is a last resort.

If TI hardware cannot replicate the issue then it is unlikely a software issue but should more focus on the hardware design. As you mentioned, by pushing, bending or flexing the board can positively or negatively bias the results. A ABA swap test is a good idea. If you can swap a known good TRF7970A chip from one of the good boards to a failure board and it you can repeat the failure then it is the board that you need to investigate. 

Hi Charles,

For modulation, register 0x09's value was changed from 0x21 to 0x20 (for 10% ASK, for example).  Other ASK modulations worked as well, but only OOK 100% saw the issue.

All the boards are of the same design.  The issue has occurred on a variety of different style 15693 tags from the ICODE series, including SLIX, SLIX2 and DNA.

An important development: We performed the ABA swap and verified that the issue followed the TRF IC.  We collected a functioning board that operates correctly (board A, TRF A) with a tag that usually fails on our error-prone board (board B, TRF B).  The TRF IC was removed from both boards and swapped.  Board A with TRF B showed the issue, while Board B with TRF A worked without error.  This shows that our board design is functional and not contributing to the issue, and that the TRF IC contains some internal defect.

Unfortunately, it remains very difficult to identify this issue, where error-prone boards must be tested with hundreds of tags in order to find a failure.  Concern remains that some of our "good" boards tested with hundreds of tags may need to be tested with hundreds more to potentially bring out the issue.  Some screening method would have to be developed to prevent such defective ICs from entering the field.

Hi Brendon,

 Thank you for providing additional information. I'm currently on vacation and I will look into your problem when I come back on Thursday. Please expect delay in my response. 

Hi Brendon,

Brendon Lovejoy said:

For modulation, register 0x09's value was changed from 0x21 to 0x20 (for 10% ASK, for example).  Other ASK modulations worked as well, but only OOK 100% saw the issue.

After the ABA swap test, is it still true that all ASK modulation depth will work except OOK at 100%?

After the ABA swap test, is it still true that some bending, pushing or flexing the board will rectify the issue?

Brendon Lovejoy said:

An important development: We performed the ABA swap and verified that the issue followed the TRF IC.  We collected a functioning board that operates correctly (board A, TRF A) with a tag that usually fails on our error-prone board (board B, TRF B).  The TRF IC was removed from both boards and swapped.  Board A with TRF B showed the issue, while Board B with TRF A worked without error.  This shows that our board design is functional and not contributing to the issue, and that the TRF IC contains some internal defec

Thanks for the ABA result. Is Board A with TRF B as error prone as Board A with TRF A or less error prone or more error prone?

Brendon Lovejoy said:

Unfortunately, it remains very difficult to identify this issue, where error-prone boards must be tested with hundreds of tags in order to find a failure.  Concern remains that some of our "good" boards tested with hundreds of tags may need to be tested with hundreds more to potentially bring out the issue.  Some screening method would have to be developed to prevent such defective ICs from entering the field.

In general, ASK modulation offers benefits of being more immune to interference compared to OOK modulation. I'm not surprised that you are able to resolve the issue when using ASK than OOK in the presence of noise after hundreds of tests.  

One question I still have is that after a failure is observed (e.g. corrupted last byte) , can the next read recover the failure? In another word, will the next read or the subsequent reads correctly read the tag?

Hi Brendon,

  Do you have any update?

Hi Charles,

I apologize for the delay, I did not receive a notification for your reply.

Yes, after the ABA swap, ASK modulation depths less than 100% and physically flexing the IC still rectify the issue.

After the ABA swap, Board A with TRF B was less error prone than Board A with TRF A.  However, flexing the board once again increased the failure rate, so perhaps slight adjustments in soldering position and stress applied to the IC when solder heats/cools affect how prevalent the issue appears.

The next read does not recover the failure.  We may experience multiple reads in a row containing the incorrect UID.

Hi Brendon,

  I apologize for the late reply.

Brendon Lovejoy said:

ASK modulation depths less than 100% and physically flexing the IC still rectify the issue.

Good to know that except OOK at 100%, other ASK modulation depths are working and flexing the IC also rectify the issue. However, I don't know how to explain as to why the problem you are seeing. 

Brendon Lovejoy said:

After the ABA swap, Board A with TRF B was less error prone than Board A with TRF A

I think this is expected as you earlier said that Board A with TRF A has no errors at all. What I should have asked you is how is Board A with TRF B compared to Board B with TRF B. Below is what you noted last time. Is it more error prone or less prone or the same?

We performed the ABA swap and verified that the issue followed the TRF IC.  We collected a functioning board that operates correctly (board A, TRF A) with a tag that usually fails on our error-prone board (board B, TRF B).

Hi Charles,

After the ABA swap, Board A with TRF B was slightly less error prone than Board B with TRF B.  As mentioned, flexing the board can increase the failure rate, but there were less failures when the board was left to run without being touched.