Problem getting I2C ACK from MFRC630 when IC is cold

[tom2]

Hi,

We are using the MFRC630 (MFRC63003) for RFID/NFC communication controlled by STM32L162VC MCU and are facing a problem with I2C communication. Some of the MFRC630 IC's do not respond after sending the I2C address, there is no ACK signal.

However when we warm up de MRFC630 on the boards with this issue they do start to respond.

The question i have is if anyone has seen this kind of behavior and what could be the cause.

More information:

At this moment we have about 10% failure rate from a batch of 100 boards with this IC (100 boards, 70 tested of which 7 are having this issue). From an earlier production batch of 100 we did initially not see this issue but at a cooler temperature some of them also show the same issue. The temperature at which this happens is different per IC. The failing 7 from 70 are failing at room temperature (about 21 degree Celcius). Some need a few degree more to start working (25 to 30), others more. Some of the working boards stop working at a bit lower temperature (about 15 degree) some only when much colder.

Our design works at 3.3V (MCU, MFRC630 (Vdd and Pvdd), I2C bus). MFRC630 Tvdd is 4V.

The I2C bus has 3 devices, the MCU (master), the MFRC630 and another device (LCD)

I2C pull-ups are 4k7

I2C frequency is 400kHz

Test case to find the cause of the problem:

Test case: a board with MFRC630 chip that fails at around 21 degree but works at around 25..30 degree Celcius. MFRC 630 chip markings: MFRC63003, 10 01, ZSD 924.

Test: board powered but MFRC630 in hard power-down mode (PDOWN pin high). Start the test by pulling the PDOWN pin low, wait 5ms (later increased to 400ms), then send I2C address 0x28 and wait for ACK. This is repeated until the IC responds with ACK after which further initialization takes place and NFC communication starts working. If the chip does not respond with ACK then repeat the test. In this case warming up IC always brings it into working condition. When the chip cools down the problem is back.

What i tried to find the cause:

-lower I2C pull-up to 3k3, 1k6 and 1k.

-Lower I2C frequency to 100kHz, then 50kHz and even 10kHz.

-Remove the 3th device (LCD) from the bus.

-Increase the operating voltage to 3.55V (Tvdd still at 4V).

All of this did not change the behavior of initial response after sending the I2C slave address.

Below are some scope images showing the issue (ACK not send) and the same images when ACK is sent when the IC is warmed up. Scope channel 1 (yellow, CLK) and 2 (Cyan, SDA) show the I2C signals near the MCU. Channel 3 shows the SDA line at the MFRC630 to see if it differs from the signal at the MCU.

No ACK after sending the address. (Channel 1 = CLK (Yellow) at MCU, 2 = SDA (cyan) at MCU, 3 = SDA at MFRC630)

No ACK after sending the address. same image showing only SDA at MFRC630.

ACK received after sending the address (and following read data). (Channel 1 = CLK (Yellow) at MCU, 2 = SDA (cyan) at MCU, 3 = SDA at MFRC630)

(Zoom in on above picture showing 8 bits + ACK/NACK) ACK received. (Channel 1 = CLK (Yellow) at MCU, 2 = SDA (cyan) at MCU, 3 = SDA at MFRC630)

Same sample only showing the SDA line on the MFRC.

I do have similar images which show the CLK line at the MFRC 630, and also images showing (P)Vdd if needed.

Any ideas what can cause this behavior?

Kind regards,

Tom

[tom2]

We have found the cause of the problem and were able to solve it.

It turned out that the capacitance value of the Load Capacitors from the crystal circuit in our design were too low. This led to oscillation problems causing the MFRC630 to stop functioning. Raising the capacitance solved the issue completely.

[egemen_altikard]

Hello Tom !

It's going to be a little weird but I glad to hear that problem. I have had same issue for three days and i couldn't solve it. But now, I have the resolve.

Thanks for your all sharing.

Can I ask your capacitance values that using for crystal? I used 18pf capacitors for 27.12 MHz crystal.

[tom2]

Hi Esat,

I'm glad my post helped to solve your problem.

Of course i can share the capacitance values that i use however these might not be optimal for your design. The capacitance value depends on the load capacitance value of the crystal and any stray capacitance that differs with each PCB design. See also https://community.nxp.com/thread/388856

The simplified formula from that post is:

External load capacitor value:
CX1 = 2(CL - Cstray)

where:
CL = the crystal load capacitance
Cstray = the stray capacitance in the oscillator circuit, which will normally be in the 2pF to 5pF range.

The 27.12MHz crystal that we use has a Load capacitance (CL) of 10pF.

Stray capacitance i estimated at 2.5pF

In our design this leads to: CX1 = 2(10 - 2.5) = 15pF. So i used 15pF for each of the two external load capacitors.

Check your crystal datasheet to find our what your crystal Load capacitance is.

I hope this helps.

Regards,

Tom

[egemen_altikard]

Hi Tom,

I got that what you mean and changed capacitor values in line with this informations. It solved my problem.

But now i have another problem about I2C communication. I am using 603 package 10k pull-up resistor on SDA and SCL lines but sometimes these resistors or MCU's SDA-SCL pins are broken and we need to change resistors or mcu again and again . I still can not get it but working on it. If you have an idea about that issue, please contact me. 

Thanks for your help and i am grateful to have discussed this topic with you.

Have a nice day.

Regards,

Esat

[tom2]

Hi Esat,

Glad i could help to solve your problem regarding the capacitors.

For the other problem you are having it might be better to start a new Topic so it is easier for others to find as it seems it is not related to the issue in this post. If the I2C pull-up resistors get damaged and you need to replace them then it sounds like a serious issue, it may be that too much current is flowing trough them, maybe a too high voltage is being used on the pull-ups or something is wrong with the power supply part of your design (or external power supply)? This could then also cause the MCU I2C pins to fail. For a better understanding a schematic would help but then do start the new topic.

Regards,

Tom

[vicentegomez]

Good news

thanks for sharing 

[vicentegomez]

I am thinking that the problem could be some solder problem, can you check if the IC is properly solder, this is a QFN device so is a little bit difficult to check if all the pin are properly solder, you can perform a test on one board, you can perform a "touch up"  on the device and check if the problem is fixed.

I hope this will help you.

Regards

Vicente Gomez

[tom2]

Thank you for your reaction!

We also thought the soldering was the problem at first and looked at that already. Visually the soldering looks good. At least we can see enough solder paste was applied which is visible on all PCB pads on the outer edge of the IC on the boards having this problem. But as you say it is difficult to see if the actual QFN device pads under the IC are also soldered well.

We already did replace the IC on one of the boards with a new one. After this the board worked at room temperature but when cooling the chip the problem was back again. We then thought this replacement chip is just one that only shows the issue at a lower temperature and concluded the soldering is not the problem. I have to say the issue only showed when cooling a lot which would not happen under normal circumstances so in practice this board is now "fixed"

Touching up the soldering on one board is something we can test additionally, if this works then indeed we have to conclude the soldering is bad.

Another test we can do is to take the "bad" IC (the one that we replaced) and put that on a board without the issue. If the problem is gone after that then that also leads to the conclusion it must be the soldering.

Once we have tried and know more i'll post an update.

[tom2]

We have placed the "bad" IC having this issue on another board which was tested and did not suffer from this issue. The result is that the problem is now also present in that board. It now seems that:

-It is not a soldering problem.

-Placing a new IC on board with the issue solves the problem

-Placing an IC from a board with the issue on another board without the issue introduces the issue on that board.

-The problem seems to linked with the IC rather then the board.

[vicentegomez]

Yes, for this case please contact your local distributor, where you bought the part.

Regards

[tom2]

Yes, we are in contact with them about this issue too. They are now contacting NXP after our latest findings.