ST25R3916 Adjust Regulators not completing without a tag in the field

[LltWc]

As we've been integrating the ST25R3916 into our final hardware, there's been an issue with the Adjust Regulators command. On external supply power, the command works without any problems. On some (not all) of our battery-powered units, as tested in the field, the Adjust Regulators command never returns, so NFC is unable to initialize. The weird part is that when a tag is held inside the field during initialization, the command completes without any issues and NFC initializes. I assume this is because the tag increases impedance while it pulls power, but this should not be necessary and our system is able to handle the current. The two traces below show initialization with a tag in the field (first), and failure without a tag in the field (second). At no point does the 2.8V rail dip, so I don't see this as an issue with the power supply.

VDD_2.8 (green)
VDD_D (red)
VDD_AM (blue)
VDD_RF (yellow)

I tried with every value of RFO driver resistance, and none worked. Setting the regulated voltage manually did, but that's not a solution that we can use going forward. Is there something I'm missing here to ensure this command completes successfully? The application is for NFC-A only, so the VDD_AM jumping around makes me wonder if there's amplitude modulation happening that shouldn't be, and messing up the initialization somehow.

[Brian TIDAL]

Hi,

which device do you use: ST25R3916 or ST25R3916B?

Do you use the RFAL middleware or you own code implementation? The RFAL has a 6ms timeout that prevents firmware from being stuck during Adjust Regulators. 

If using your own implementation, have you followed the §4.4.10 from the ST25R3916 datasheet: "Before sending the adjust regulator command it is required to toggle the bit reg_s by setting it first to 1 and then reset it to 0"? See st25r3916AdjustRegulators code inside the RFAL.

Also, the Adjust Regulators direct command is only accepted in "en" operating mode (see table 13). Can you confirm the en bit has been set to 1 in the Operation control register and the I_osc has been received before sending this direct command? (well, I guess this is the case but I prefer to double check)

Rgds

BT

[LltWc]

We're using the ST25R3916, not the -B version, and our own firmware, not the RFAL.

I do have it toggling reg_s, we didn't previously but I added that while trying fixes.

The en bit is set, the oscillator start process completes successfully before attempting to adjust regulators. The initialization sequence is listed below:

1. Command: Set Default
2. Test Register: disable overheat protection
3. IRQ Mask Registers: mask all IRQs
4. IRQ Registers: read all IRQs to clear them out
5. Operation Control Register: check EN bit
6. IRQ Registers: enable OSC IRQ
7. Operation Control Registers: set EN bit to 1
8. Wait for OSC IRQ (always succeeds)
9. IRQ Mask Registers: disable OSC IRQ
10. Regulator Control Register: set source to VDD
11. Command: Measure Power Supply
12. AD Converter Out Register: read result
13. IO Configuration 2: set 3.3V supply
14. Regulator Control Register: set reg_s to 1
15. Regulator Control Register: set reg_s to 0
16. Command: Adjust Regulators
17. Wait 10 ms for IRQ
18. Repeat Adjust Regulators command five more times with each Antenna TX Driver value

I've also tried it with a 100ms wait for IRQ just in case, and it still fails.

[Ulysses HERNIOSUS]

Hi LltWc,

I don't find in your sequence the unmasking of I_dct - I presume you omitted only in your description because otherwise you would always fail.

Ulysses

[LltWc]

After a whole bunch of debugging, two fixes have led to reliable initialization on a non-metal surface. The first was a timing error in my code that resulted in the DCT IRQ not triggering the ISR correctly. The second was enabling tx and rx before sending the Adjust Regulators command. My only guess is that this causes less of a power spike in this way, even though that's exactly what the Adjust Regulators command does on its own. 

Additionally, when initialized on a metal surface, two unexpected behaviors are exhibited.

1. Adjust Regulators succeeds, sends an IRQ, and DCT is not set when the IRQ registers are read.
2. Field On succeeds and sends an APON rather than a CAT. Previously, I masked APON because I wanted to wait for the guard time, but CAT is never sent in this case.

The second is easily handled; the first is not. You can see in the screenshot below that I try Adjust Regulators three times, and the first sends an IRQ, but the registers return 0, so that's a failure. I'll likely have to check Regulator Display between commands and therefore increase the duration of initialization.

[Ulysses HERNIOSUS]

Hi LltWc,

 

Maybe your detuning is such that you experience big swings on turning on the field. Worth to look at the waveforms of the field on and the supply lines.

ad 1) I would be really curious to see this effect with a logic analyzer (SPI+IRQ) to rule out an issue on the SPI bus. Any chance for that? Otherwise it makes me suspicious that Regulator display register indicates exactly the middle value 8(4.4V/2.7V), maybe it means that the system is so heavily detuned that the regulator adjustment is not succeeding. Could you report the various reported regulator values while you approach the metal plate (e.g. values for 4cm, 3cm, 2cm, 1cm, 0.5cm and 0cm).

ad 2) What is your setting of nfc_gt? Depending on its value the  I_cat could come up to 39ms later than I_apon.

BR, Ulysses

 

[LltWc]

I discussed with the engineer who tuned the resistors and he confirmed that a metal surface would definitely cause the field to be detuned, but that's just a consequence of how NFC works. Why would this affect Adjust Regulators, though? Doesn't that just enable rx/tx and then set regulated voltage based on that? The inconsistent IRQ behavior doesn't seem like it should be caused by detuning; is it possible that the chip is completing the command by setting the regulated voltage, but then not setting the I_dct value due to some internal complication with unexpected power draw?

 

1) Not in the near term, if I have time I'll take a look at the I2C bus but I don't have any issues with ongoing commands so I wouldn't expect that to be a problem. The Regulator display register is sometimes set to 2.6V; the supply voltage is 2.8V (and stays constant during Adjust Regulators) so I figure 2.7 and 2.6 are both appropriate. One note is that the datasheet says the command should be setting regulated voltage to 250 mV below Vdd_tx, and Vdd_tx is 2.8V. It is set to 2.7V in ideal open-air conditions.

To check the regulator values, do you mean that I should be running Adjust Regulator at each of those distances or is there another way to check?

 

2) nfc_gt is left at 0x33, the default 5ms required guard time. What's unexpected is not that I_apon is before I_cat - it's that during normal behavior (not on metal surface) I have I_apon masked and do see an I_cat IRQ. On a metal surface, with I_apon masked and I_cat enabled, no IRQ comes in at all. Am I correct in assuming that I_apon should always be triggered nfc_gt time before l_cat? So in my case with nfc_gt set to 5ms, after a Field On, I_apon comes in very quickly, and I_cat should come in 5ms later.

[LltWc]

 

I wasn't able to test distances for Adjust Regulator, but for anyone who might come across this problem in the future, there were two things that fixed it together.

First was a race condition; there were some cases where the IRQ semaphore was already given (and shouldn't have been), so Adjust Regulators completing couldn't notify that it was complete.

Second was setting Tx/Rx enable before the Adjust Regulators command. I don't know why this helped, my assumption is that it blunts the power draw somehow, but we didn't see any voltage supply issues. I think detuning having knock-on effects is likely, but I didn't have time for any more experimenting after I had it in a state that worked consistently. Plus we're not going to typically be booting our devices sitting on metal.

The state of the firmware now is that we do three Adjust Regulators retries, and check the actual register value after each one in case the command completed but couldn't notify via IRQ properly, and then if we fail all three (hasn't happened yet!), the regulated voltage is just set to the observed 2700 mV that the command would have.