NFC mobile app using M24LR64E-R

[UKuru.1]

Greetings,

I've been using M24LR64E-R and CR95HF card on Windows for some time. Using the demo card, I'm able to achieve consistent interrupts but on my Android app the tag seems to miss the interrupts while the writing is happening.

No particular difference in the algorithm I'm following. The only considerable difference is; CR95HF.dll has a function called CR95HFDll_select where Android doesn't offer a protocol selection as such.

How can I achieve the selection that CR95HFDll_select adds on Android? Or is there something I'm missing from the datasheets that'd help me adjust my Android app better so that I can generate consistent interrupts after writing blocks?

Best regards.

[Brian TIDAL]

Hi,

In order to provide the proper interrupt, the RF WIP/BUSY pin needs to be configured. See §4.3.1 in the M24LR64E-R datasheet.

Note: On CR95HF, CR95HFDll_select is used to select and configure one of the NFC communication technologies (NFCA, NFCB, NFCF or NFCV). On Android side, an NFC controller is used and the selection and configuration of the various NFC communication technologies is done by the Android driver. So, CR95HFDll_select is not related to M24LR64E-R interrupt configuration.

Rgds

BT

[UKuru.1]

Hey,

Thank you for replying. Your note on the dll file was quite helpful. Unfortunately I'm still unable to observe the interrupts I mentioned.

Here is a sample of the interrupts I am trying to achieve. Using CR95HF I'm writing blocks of data and the tag raises interrupts.

 

Here is a sample from my Android app. Just like with CR95HF, I'm able to write blocks of data, read the blocks to see the whole data, but unable to raise interrupts whilst writing blocks using my phones NFC component.

 

I have checked 4.3.1 RF WIP/BUSY (bit 3) and have read the current configuration byte of my tag. ReadCfg command retuns the value 0x0B which corresponds to 00001011b. I have been able to modify the value to 0x03 and back between/during each block and the whole writing process, but am still not able to observe forementioned interrupts.

Any help or thoughts on the matter are highly appreciated.

Best regards.

[Brian TIDAL]

Hi,

RF WIP/BUSY (bit 3) is part of the non-volatile Configuration byte. Therefore, it only needed to write it once. If you configure it to RF busy mode, do you see the interrupt during the various commands?

I've tested on my side with an Android phone using the ST25NFCTap app and a M24LR discovery board and I can see the interrupt on each write commands when in RF WIP mode and interrupts on various commands when in RF busy mode. Can you try on your side to use the ST25NFCTap app to send Write commands?

Also, what is the value of your pull up resistor between Vcc and RF WIP/BUSY pins?

Rgds

BT

[UKuru.1]

Hello,

The tests I've performed with RF WIP mode and RF BUSY mode were to no avail. So I've tried configuring other bits of the configuration byte and bit 0 of the control register byte. Have been testing scenarios on three different apps including ST25NFCTap and seeing interrupts 10% of the time.

Upon using a different android mobile device I've finally achieved consistent interrupts. But both mobile devices' NFC components feed the energy harvesting by around 3.2V so I have no idea how changing the mobile device was beneficial. Any ideas?

Notes: I was testing on a Samsung device with Android 5.0 os and switching to a Xiaomi device with Android11 os solved my issue. And it appears that I'm not using a pull up resistor, a software decides when Vcc is set to high I think. It may be the main issue that an older device couldn't raise any interrupts. Would appreciate thoughts on that aswell.

Thank you for your guidance and wish you the best Brian.

[JL. Lebon]

Hello,

A pull-up resistor between the RF_WIP/BUSY and VCC is mandatory for the interrupt to work correctly. The RF_WIP/BUSY is an open drain output, meaning that it can only drive the signal to ground when active and requires a pull-up resistor to VCC to be high when not active.

It also looks like from the value of your configuration byte that the energy harvesting is enabled at boot. You may try to disable it (setting bit 2 of the configuration byte to 1) and try again with your old android phone. Actually, one difference between the old phone and the newer one could be the RF power delivered. The phone is delivering power to the tag through RF field and this power is used by the tag for it's operation and is also used to feed current to the energy harvesting output. If the power delivered by the phone is not enough and the EH is drawing too much current, this can cause power issues. The CR95HF is usually more powerful than smartphones, and older smartphones may be less powerful than newer ones. So, as a test, I suggest that you disable EH and try again with the old smartphone to check if the problem persists.

Best regards.