TRF7964A: Device does not work with in specified operating temperature

Hello Richard,

That behavior is far from expected, so I'd like to understand a bit more.

1) Is this is a new design/spin and the problem is only observed in manufacturing now?

2) What regulator control setting are you using when setting it for manual operation?

3) For devices which are having these high amounts of failures to read, have you done any assessment about where in the read process it is failing, if any errors are reported, any tests done with the hardware in terms of power lines being at the right voltages and verifying the RF field output etc?

Regarding the settings, the default setting is for automatic regulator control, but in general we find that in automatic mode, the device will sometimes try and pull more power than the power supply would allow and cause issues that way. That said, usually I wouldn't expect 5V to have this issue. The issue is more prevalent with 3V setting as you may source 3V but the automatic regulator control may try and treat it as a power supply larger then 3V and that can cause issues.

Let me know what you can regarding my questions so we can try and figure out what is really going on here.

Hello Ralph, I mistakenly posted my question twice, please feel free to delete my last one.

1) not the problem is observed and confirmed in field returns as well and has been a problem since launch

2) Existing, or production

Not setting chip status control, defaults to 5V

Not setting regulator and I/O control, defaults to auto

Wait 15 mS after chip set call.

What I have done to improve the performance 

Set chip status control to 5V

Set regulator and I/O control to manual: Vdd RF to 5V, other Vdd to 3.4V

Wait 20 mS after chip set call.

3) verified the the RF field was good and at full power during the read process and all voltages are correct at the time of reading

I would like to know what exactly Default, Auto and Manual are doing and is there external circuits need for manual regulation, it's not clear the data sheet.

Hello Richard,

For starters, default and automatic are the same. The default is to set automatic mode.

The automatic mode is supposed to use the levels that are the most stable based on the input, but we have found that the performance varies more than we would like and that manual mode provides the best way to control the performance. However, an issue like yours is not what is expected with automatic mode, we haven't seen system failures from using it. What has caused problem is manually setting the VDD_RF/VDD_X values to be too high (usually when in 3V mode) so the device wouldn't be able to drive the voltage at the level indicated by the setting.

So setting it to the maximum setting is working, but automatic is not? Have you tried other settings? I'd be interested to see if certain settings cause the failure.

When you say wait 15 vs 20 mSec, is that how long until you apply other settings, or when you read the tag?

Also, when starting the device off, do you do a Soft Reset sequence like outlined in Section 6.11 of the datasheet, 'TRF7970A Initialization'?

The wait time is before we read a tag, and we did try 17mS wait time with default "not" setting the register and automatic which improved the tag reading error rate. I found the manual 20mS seem to do best. Improved one unit from 700 errors to 3 our of 3600 attempts.which for RF I would consider an acceptable,

I'm the hardware engineer, I'll pass your question on to software. However, I would presume no because we are using the instructions from TRF7964A which don't mention anything about a soft reset.

What settings would you want us to try? I've been trying to come up with a working solution for both manufacturing and field returns.

I'm still not clear on what automatic and manual modes do? :'Automatic is supposed to use levels that are most stable based on the input' input to what? and what is manual mode doing and what are the levels it is using and what for

Hello Richard,

I would recommend the settings outlined in section 6.11 of the data. I mistyped the part number in my last post, it would be 'TRF7964A Initialization' for your device D/S. Both the 70A and 64A have this section though. The Regulator Control should be optional, but it's up to what you feel works best but I think with the right setup, the automatic mode would work too.

The difference between 15 and 20 ms and that using the maximum setting makes me think that maybe the RF interface isn't being powered enough in the 15 ms. I know for certain smart transponders, we recommend 20 milliseconds RF field on time before reading them. I have a strong (and educated) suspicion that the transponder on the other end of your system would fit into that category. :)

I have to adjust my comments on automatic mode slightly. What we had wanted the device to do with that feature would be that based on the input voltage at VIN set optimal voltage levels for VDD_RF and at 3.3V, VDD_X and VDD_A, but with the TRF7964A/TRF7970A that isn't quite what is happening. I think for the prior generation devices, they work better for this.

However what it is actually doing is: By default, the regulator setting algorithm sets the regulator outputs to a "Delta Voltage" of 400 mV below VIN, but not higher than 5 V for VDD_RF and 3.4 V for VDD_A and VDD_A.

So what this means is that you are losing some potential voltage that could increase the output power of your RF field.

For manual mode, you are telling the device what settings should be used, and the device will try and set them. But if you tell the device to use VDD_X/VDD_A = 3.3V and give the device VIN = 3V, then it cannot meet the setting and could have issues with operation. So you have to understand your power setup before making those settings.

So in general you get better performance from manual mode as long as you have a stable power supply. A caveat there would be that for battery-powered applications, you'd need to account for the change in VIN over battery life and determine the best setting based on that.

Looping back to your situation, increasing the VDD_RF voltage by 400mV or increasing the on time by a few seconds both would give the transponder more time to charge up and would indicate the issue here is having enough time for it to be ready for RF communication.

Here is our initialization sequence 

1. Raise EN  (GPIOA_PSOR = GPIO_PIN_25)
2. SPI Direct command 0x03
3. Wait 15 mS
4. SPI Direct command 0x00
5. Wait 15 mS
6. Write config registers per below
7. Read back config registers
8. If RF transmitter is off, turn it on  (CHIP_STATUS_CONTROL |= 0x20)
9. Wait 17 mS  (20 now)
10. Reset FIFO command (0x0F) is done in the interrupt handler on transmit done, and after bytes received.
11. Modulator and sysclk control and NFC target detection level are set during config registers.

Hello Ralph, that is very helpful explanation, like the old school TI Data books ;-) very helpful. I'll take a closer look and we are using a lithium-ion battery so I'll take a look at what our power supply is doing at low voltage. .

Hello Ralph, We use the TRF7964 on two difference devices and different configurations the 5Vin with the configuration stated Default, which we have problems with and a 3.3Vin version with Auto setting with 17mS delay and the production line has had no occurrences of this problem and we use the same tags. In fact I took a device that displayed this symptom i.e. a 5Vin cut and jump it to use 3Vin set the software up with auto & 17mS delay and that also solved the problem 100%. 

Hello Richard,

Honestly this is getting more and more strange as we go down the rabbit hole.

Fundamentally if an increase in delay time improves performance, then it would indicate the tag needs more energy.

However, at 3V input, the output power is 70mW, compared to 200mW at 5V. So the tag would receive less energy in this situation. For it to be working without issues comparatively would seemingly defy all the reasons I can come up with for a root cause to the 5V issue.

Given the configuration sequence, I would like to see if your firmware engineer can try one small change.

The 15 ms delay between the 0x03 and 0x00 is not something we have done before and I wonder if it is causing some unusual behavior with the soft reset sequence. Can this be removed and tested? Ideally with the settings that caused failures before to understand if that delay is causing an unexpected issue.

Test results aside, in general there is no need for that first 15 ms delay, and the second delay, the one after the 0x00, can be reduced to 1 ms until the register configurations are applied. So that'd save you a nice chunk of setup time.

I will continue to mull over what other root causes could be contributing to this...

Hello Ralph, sure and will do on the experiment, I may not get to it till next Monday because I'm off on Friday and I'm not sure Software can get to it today. I agree this is unusual behavior

Richard -

When the tags fail to read, what is returned in Register 0x0C of the TRF79xx?  

Hello Ralph, I should have results for you tomorrow. Sorry for the delay, little mfg campfire that need stamping out. OH and my software guy said he had made a mistake in the start up sequence that he first shared with me.

1. Raise EN  (GPIOA_PSOR = GPIO_PIN_25)
2. Wait 15 mS
3. SPI Direct command 0x03
4. SPI Direct command 0x00
5. Wait 15 mS
6. Write config registers per below
7. Read back config registers
8. If RF transmitter is off, turn it on  (CHIP_STATUS_CONTROL |= 0x20)
9. Wait 17 mS  (20 now)
10. Reset FIFO command (0x0F) is done in the interrupt handler on transmit done, and after bytes received.
11. Modulator and sysclk control and NFC target detection level are set during config registers.

The red lines were mixed up.  The 15mS wait came before the SPI commands and the my original post 2 and 3 where swapped

This is what we are going to test, all three regulation modes, Default (not set), Auto and Manual

1. Raise EN  (GPIOA_PSOR = GPIO_PIN_25)
2. Wait 5 mS
3. SPI Direct command 0x03
4. SPI Direct command 0x00
5. Wait 1 mS
6. Write config registers per below
7. Read back config registers
8. If RF transmitter is off, turn it on  (CHIP_STATUS_CONTROL |= 0x20)
9. Wait 17 mS  (20 now)
10. Reset FIFO command (0x0F) is done in the interrupt handler on transmit done, and after bytes received.
11. Modulator and sysclk control and NFC target detection level are set during config registers.

Hello Josh, unfortunately the current test method doesn't lend it self to knowing Register 0x0C. I can tell you that we get no tag data in our terminal, example below. We have heard from TI via another department that there is a known problem with this device and it has something to do with timing?

The output we get

$invent 'inventory cmd
00: E00700001FDBE74E,#01,M=04,A=03
CKSM:00000BF4
CMD OK
$invent
CKSM:00000000
CMD OK
$invent
CKSM:00000000
CMD OK

Josh, I'm asking software dev team if they can easily dump that register to our screen output

Hello Ralph, Here are the results with the following settings

1. Raise EN  (GPIOA_PSOR = GPIO_PIN_25)
2. Wait 5 mS
3. SPI Direct command 0x03
4. SPI Direct command 0x00
5. Wait 1 mS
6. Write config registers per below
7. Read back config registers
8. If RF transmitter is off, turn it on  (CHIP_STATUS_CONTROL |= 0x20)
9. Wait 20 now
10. Reset FIFO command (0x0F) is done in the interrupt handler on transmit done, and after bytes received.

Manual Mode

3600 correct reads out of 3600 @ 10C @ 1 read per second

Auto Mode

1 correct read out of 3600 @ 10C @ 1 read per second. the first read, all others failed

Default Mode 

1 correct read out of 3600 @ 10C @ 1 read per second.  the first read, all others failed

Hello Josh, 0x0C = 02, 42, or 44 comm errors or it reads the patch

The setup we are using is the one I posted this morning Default mode but if we set is to manual it reads 100% of the time correctly at all temperature we test too. 

1. Raise EN  (GPIOA_PSOR = GPIO_PIN_25)
2. Wait 5 mS
3. SPI Direct command 0x03
4. SPI Direct command 0x00
5. Wait 1 mS
6. Write config registers per below
7. Read back config registers
8. If RF transmitter is off, turn it on  (CHIP_STATUS_CONTROL |= 0x20)
9. Wait 17 mS  (20 now)
10. Reset FIFO command (0x0F) is done in the interrupt handler on transmit done, and after bytes received.
11. Modulator and sysclk control and NFC target detection level are set during config registers.

another interesting note is if we remove the tag and try to read it we get 02 in 0x0c which is a collision error?

Hello Richard,

Speaking of raising EN, on initial configuration is the timing diagram on Figure 6-3 being followed regarding minimum times? (If EN2 is not MCU controlled it can be disregarded).

Auto mode and Default Mode are the same so that isn't surprising that the results match for them.

Does the 0x02 only occur once when the tag is removed or is it repeated and shows up well after the tag is removed? A single 0x02 on removal wouldn't surprise me much because the device would only see a partial answer.

When errors like those are received, what steps are taken to try and recover and retry? In general we recommend soft resetting with 0x83 0x80, reconfigure, and then re-try the request. Is that what is being done?

Would it be possible to sweep across the various Regulator Control settings? I would expect at least one or more of them to cause failures even in Manual mode. What setting causes that may give us some indication here.

Richard Ries said:

We have heard from TI via another department that there is a known problem with this device and it has something to do with timing?

Without more context here I don't know for sure what this person was referring to, but in general timing can be sensitive with the device. Most of that stems from the nature of being an open-ended transceiver which gives a lot of flexibility and therefore aspects like guard times, response times, timeouts etc. for RF communication need to be handled. 

Hello Richard,

Any updates on this?

FYI I am going to be out of office starting Friday until into January, so if we don't make much progress this week just keep that in mind.

Hello Richard,

Great to hear that you believe to have found a workable solution to the issue. I like those setting adjustments, sometimes it just takes small tweaks like that. I wish every system behaved the same so I could have just given you a magic set of parameters that always works! And fully understand it will take some time to gather the complete results.

I'll go ahead and mark your latest post as the solution for now but if the test results differ than expected feel free to reject it and we can continue to brainstorm on what other knobs we can turn.

Hello Ralph,

Here are the result of the testing, it looks like this device only operates per the data sheet when running at 3V, any 5V operation is got some sort of problem. The Manual 4.7V with 20mS delay fixes some but makes others worse. 

I'm think TI may need to put a screening process in place and test these at 5V Default with 15mS delay before they send them to us.

Inv Cnt is the number of times we asked the device to fetch the tag info and Tag Cnt is the number of times we received the tag information correctly while misreads is the difference.

Hello Richard,

Just updating the thread in case anyone stumbles upon it with similar problems.

The support for this is being pulled offline due to sharing of sensitive information as the debug continues but current can say:

1) The test methods for the device do not include trying to read tags with x delays, so what needs to be done is track down the root cause for the issue (voltage, current, etc. - something that can be tested and screened) if we were to implement any sort of test screen.

2) I am not yet convinced that even with more strenuous testing, that this will be a device level issue as we have supported a large number of customers using 5V. A tolerance failure due to stricter testing for me would be cases like 100-200 misreads... but there are bases with basically 0 successful reads and if that was a device level issue then others would be seeing that as well.

I intend to update the thread once we identify the root cause, but until then the support will be driven offline so information doesn't need to be carefully filtered moving forward.