Different detection pulse peaks by LPCD with RC663

[NNyland]

Hi, we've been working with the RC663 in a LowPower project, and after producing 200 pieces of our antenna PCB, which has the RC663 mounted on it, we noticed the following:

When in LPCD mode, most of the RC663 consumes around 1750uA per detection pulse, what is totally OK, as the average consumption stays closely to 50uA.

But, few boards, the detection pulses goes as high as 5000uA. A little bit of variation (peaks at 2300uA) can still be accepted, as the average consumption stays under 70uA, but those 5000uA peaks makes the average consumption too high.

These 5000uA pulses are also often larger and do not have a fixed frequency of occurrence, repeating sporadically more often over time.

To exclude any PCB assembly/solder issues, we exchanged the RC633 from a "bad" PCB, and mounted it into a "good" PCB. By doing that, we noticed that the error was still present, which leads us to believe that it is something related to RC663 and not the PCB itself.

Dumping the registers from address 0x00 - 0x47, just before sending the command to enter into LPCD mode, we could not see any relevant difference on the values, as only the TxCounterValHi, TXCounterValLo and LFO_trimm were different between a "good" and a "bad" RC663.

What could be the reason to have different LPCD detection pulses with different power consumption and duration time?

Many thanks in advance,
Nathan

[Tomas_Parizek]

Hello @NNyland , 

Where do you measure the current? Is it TVDD current? 

When the "Bad peak" occurs, can you observe a "longer" RF Field duration? Or are the RF peaks the same? 

Thanks for your comments in advance ! 

BR

Tomas 

[NNyland]

Hello @Tomas_Parizek ,

The measurements from my first post were taken from the whole system (ST MCU + RC663), at low refresh rate.

The ones from my reply to EduardoZamora were also with the whole system, but with increased refresh rate.

All those previous results and screenshots from my old posts were using the original connections (see Attachment Original_SCH_Power), where a singla 3V3 power source was connected to both VDD and TVDD. 

When measuring only the RC663 consumption on both VDD and TVDD, as on the Original_SCH_Power, but without the extra circuit which contains the ST MCU and etc, the extra random length 5mA steps before the peaks can be seen.

To test only TVDD, I've modified the circuit as shown on the attachment (see Mod_SCH_Power), and measured only the TVDD.  

For my surprise, those extra 5mA steps before the peaks cannot be seen anymore on the measurement, but what I noticed were some random time interval between few pulses (see Attachment Only_TVDD), which may indicate that:
- 5mA step is still there, but doesn't come from the TVDD
- and/or maybe the RC663 is taking too long to start?!?! 

The AN11783 shows a combined StartupA + StartupB time of around 425uS, but in one of the cases I cold measure (see Attachment BadPeakClose), the 5mA step was active for around 30ms.

Regarding your question about the RF field duration, I'm afraid I don't have the right equipment to measure that. My colleague checked the antenna matching, and the results were totally OK, but he was not sure how to perform such test. From power consumption side, all the peaks looks the same (as on my previous Attachment BadRandomPeaks).


So far, seems that the extra power consumption comes from the VDD pin, but why it happens randomly (and seems to get worster/often by the time) is not clear.

Best Regards,
Nathan

[Tomas_Parizek]

Hello @NNyland , 

Thanks for providing the data! 

Based on your measurements, it looks like the "longer" pulse is caused by VDD (the main power supply of RC663). 

Also, it looks like the RF field is not even generated (I see missing current peaks in the TVDD waveform) when this abnormality happens.

It looks like the IC tries to start up and perform the LPCD RF ping, but the start-up takes significantly more time, and the RF is not generated. Then the IC continues into the LPCD standby mode, and then with the next LPCD Ping, that is OK. 

Now the question is why. 

Some hypthotesis: 

-> XTAL oscillator does not start properly in some cases 

• Theoretically, the XTAL should always be active. I need to double-check. 

-> False wake-up from LPCD 

-> Some TXLDO event (overcurrent etc...) 

• This should not be the case, as the LPCD current is around 25mA in your case. 

You said that the issue follows the IC, right? Meaning after swapping the IC from "good" and "bad" devices. You see that the issue follows the IC, right? 

What variant of the RC663 package are you using? If HVQFN32, we should try to solder the IC on the CLRC663 EVK and try it with the NFC Cockpit. Just to exclude that there is some HW dependency. Do you have this option? 

If the issue still persists, you should open a quality complaint through the distributor who sold you the IC´s. 

BR

Tomas 

[NNyland]

Hi @Tomas_Parizek 

I believe that those missing peaks are related to a really long startup time, where it just took more than the wake-up interruption somehow.

Regarding your hypthotesis:

-> False wake-up: In this case, the RC663 must stay wake until the LPCD is set again, correct? If yes, then I believe we would be able to see on the first measurements, where we measured VDD and TVDD together, a higher current after the peak, indicating that the device is waiting for LPCD commands, like in idle. 

->  We do have a XTAL connected to pins XTAL1 and XTAL2 (27.12MHz, w/ 7pF), but since the problem "goes with the chip", happening even when the IC is soldered in another good board, it can really have to do with activate/deactivate from XTAL at RC663 to save power. If there is any command/register write that stops or re-configure the XTAL internally, let me know, and I can check if it is included in our RFID setup routine, but it follows the example from NXP.

I will check if we do have any evaluation kit here to do the test, but that may take a while if I have to order it, as part of the department is in vacations.

I will keep the topic up-to-date, as soon as I have more news from the tests.

Thanks for the support so far!
Best Regards,
Nathan

[Tomas_Parizek]

Hi @NNyland , 

What I can offer is that you can send me one of the "abnormal" RC663 samples, and I can test it with our EVK. 

If we confirm the issue with the IC, you would need to contact a distributor who sold you the ICs, and they will open a quality complaint. Then our quality team can check the IC (XRAY, Conductive tests....) 

PS: 

I will share my address via a private message. 

BR

Tomas 

[EduardoZamora]

Hello @NNyland

Hope you are doing well.

Could you please provide a few more details on your setup? What is the Host MCU you are using?

What is the procedure you have followed to configure and calibrate the LPCD? It is recommended perform the configuration and testing by using NFC Cockpit, as described in CLRC663 evaluation board quick start guide, Section 3.2.3.

How are you measuring the current consumption? You should expect a current consumption of up to 200mA during the short t(RF_On). Please, refer to AN11783 CLRC663 plus Low Power Card Detection for more information. Low power design is explained in Section 3.4.

Additionally, our recommended NFC Reader Library offers a demo to test CLRC663 LPCD, which contains test cases for CLRC663 HAL LPCD under different conditions. I will recommend you using this demo as base for your application.

Regards,
Eduardo.

[NNyland]

Hello @EduardoZamora 

I'm using the RC663 together with a ST MCU, via SPI, which goes to deep sleep mode and only wakes when RC663 set the IRQ pin.
Attached you can find the antenna schematic in use.

I'm not using the NFC Reader Library, as it won't fit with the rest of the code into the device's memory, but the function to enable the LPCD mode follows all the steps from AN11145, including reading and writting all registers shown on the doc, and calculating QMin, QMax, IMin values according to the formulas.

For the measurements, I'm using a STLINKV3-PWR device.
I've increased the sampling frequency to 10KHz, and I could see that, indeed, the peaks go up to 18500 - 21500uA for a really short time. But by increasing the sampling rate, I could also notice two totally different peak patterns (See Attachments), when comparing a RFID board which has an average consumption of 38uA against another one with 150uA (consumption varies, as the large pulses occurs sporadically), sharing the same code and schematic.

Do you know what could cause that difference between both "good" and "bad" peaks? And why those "bad" pulse are not constant, but happens in between some "good" pulses randomly?

By dumping both boards registers, I get (the ones different, I've entered the register name):
REG -> Good | Bad
00 -> 00 | 00
01 -> 40 | 40
02 -> A0 | A0
03 -> 05 | 05
06 -> 20 | 20
07 -> 10 | 10
08 -> 10 | 10
09 -> E0 | E0
0A -> 00 | 00
0B -> 00 | 00
0C -> 00 | 00
0D -> 00 | 00
0E -> 00 | 00
0F -> 00 | 00
10 -> 00 | 00
11 -> 80 | 80
12 -> 00 | 00 
13 -> 00 | 00 
14 -> 00 | 00
15 -> 00 | 00
16 -> 80 | 80
17 -> 80 | 11 T1CounterValHi
18 -> 01 | 08 T1CounterValLo
19 -> 00 | 00
1A -> 00 | 00
1B -> 80 | 80
1C -> 18 | 14 T2CounterValHi
1D -> 02 | 8A T2CounterValLo
1E -> 00 | 00
1F -> 0D | 0D
20 -> F2 | F2
21 -> 00 | 00
22 -> 00 | 00
23 -> 9F | 9F
24 -> 00 | 00
25 -> F2 | F2
26 -> 00 | 00
27 -> 8F | E4 T4CounterValLo
28 -> 89 | 89
29 -> 15 | 15
2A -> 11 | 11
2B -> 06 | 06
2C -> 18 | 18
2D -> 18 | 18
2E -> 08 | 08
2F -> 27 | 27
30 -> 00 | 00
31 -> C0 | C0
32 -> 12 | 12
33 -> CF | CF
34 -> 00 | 00
35 -> 04 | 04
36 -> 90 | 90
37 -> FF | FF
38 -> 52 | 52
39 -> 03 | 03
3A -> 00 | 00
3B -> 7A | 7A
3C -> 63 | 5F LFO_trimm
3D -> 04 | 04
3E -> 20 | 20
3F -> 2F | 2F
40 -> F3 | F3
41 -> 8C | 8C
42 -> 0D | 0D
43 -> 71 | 71
44 -> 00 | 00
45 -> 00 | 00
46 -> 2E | 2E
47 -> 00 | 00
7F -> 1A | 1A

Also, just to remember that there are around 190 RFID boards which work fine, having only the "good" peaks, but around 10 do have that large "step" before the peak. And by exchanging the RC663 from a "bad" one into a "good" one, the problem persists.

Any chance that the input pins got damaged during assembly proccess?

Best regards,
Nathan