ST25R3918 RFID POLLING APPLICATION (NFC-V)

[NAmam.2]

Hi,

I have derived this code from the ST25NFCLib, and the software works correctly when interfacing with the NUCLEO-L476RG board.

However, when I connect the same setup to my proto board, I observe a difference during the following I2C transaction.

During the initialization process, the master sends command 0xDF (Measure Power Supply) and then waits for the IRQ signal.

In the working setup, the IRQ status registers (1Ah–1Dh) return the values:

00, 80, 00, 00

Whereas in the non-working setup, the IRQ status registers return:

00, 00, 00, 00

I am not sure why the IRQ response is different in the proto board setup.

Please note the following:

• Both the working and non-working setups use the same ST25R3918 daughter board.
• Both setups use the same interface signals: 3.3V, GND, IRQ, SCL, and SDA.
• The I2C communication speed is identical on both setups.

I am attaching the I2C transaction screenshots for reference:

• The upper transaction belongs to the non-working setup.
• The lower transaction belongs to the working setup.

Please let me know if you notice any missing initialization command or any issue in the sequence below.

//INITIALIZATION COMMANDS LIST

I2C_TRANSACTION Init_ST25R[MAX_ST25R_INIT_TRNSCTIONS]={

            {INST_SEND_CMD1,0xC1,0x00,0x00,0x00,NULL,0x00},//SET DEFAULT, puts ST25R3918 into powerup mode - command C1

            {INST_RD_REG1,0x3F,0x00,0x00,0x00,NULL,0x00},//READ REG-3F IDENTITY REG(should be 2A for ST25R3918)

            {INST_RD_REG3,0x44,0x01,0x00,0x00,NULL,0x00}, //POWER_ON seq read

            {INST_WR_REG3,0x04,0x02,0x10,0x00,NULL,0x00},//POWER_ON SEQ Write - FC,04,10

            {INST_RD_REG1,0x02,0x00,0x00,0x00,NULL,0x00},//READ REG-02

            {INST_RD_REG1,0x02,0x00,0x00,0x00,NULL,0x00},//READ REG-02

            {INST_WR_REG1,0x02,0x01,0x80,0x00,NULL,0x00},//WRITE REG-02, 80 - ENABLE OSCILLATOR & REG, THIS CAUSES ISR

            {NULL,0x16,0x01,0x80,0x00,&WaitForIrq1,0x00},//WRITE REG-16 with, 0x80 - INTR MASK REG - masking OSC interrupt

            {INST_WR_REG1,0x16,0x01,0x80,0x00,NULL,0x00},//WRITE REG-16 with, 0x80 - INTR MASK REG - masking OSC interrupt

            {INST_RD_REG1,0x31,0x00,0x00,0x00,NULL,0x00},//READ REG-31 AUX disp reg -OSC stble

            {INST_RD_REG1,0x2C,0x00,0x00,0x00,NULL,0x00},//READ REG-2c REGULATOR VOLTAGE CONTROL

            {INST_SEND_CMD1,0xDF,0x00,0x00,0x00,NULL,0x00},//Command to measure POWER SUPPLY - GENERATES IRQ - command DF

            {NULL,0x17,0x01,0x80,0x00,&WaitForIrq2,0x00},//WRITE REG-17 with, 0x80 - INTR MASK REG - masking OSC interrupt

            {INST_WR_REG1,0x17,0x01,0x80,0x00,NULL,0x00},//WRITE REG-17 with, 0x80 - INTR MASK REG - masking OSC interrupt

[Brian TIDAL]

Hi,

could you provide information about the ST26R3918 daughter board: how are supplied VDD, VDD_IO and VDD_TX? Could you check the various voltages on the correct setup and on the failing setup?

Regarding the firmware, do you use the RFAL or your own implementation?

Could you also provide the logic analyzer trace (.dvdat file)?

Rgds

BT

[NAmam.2]

Hi Brian,

Thank you for the response.

I derived the software from RFAL and recorded all the I2C transactions during the initialization and polling process. Based on that, I developed my own software implementation. The new software is working correctly on the STM32F476RG NUCLEO board.

However, after porting the same code to my actual controller on the protoboard, it does not work.

The failure appears to occur when the device does not provide the correct IRQ Status response following command 0xDF, as I described earlier.

Please note that I am using the same NFC 5 Click board (ST25R3918 demo board from MikroElektronika) in both cases.

You can find the demo board schematic in the file: nfc_5_click_v100_Schematic

I am using 3.3V for VDD.

I am also attaching the logic analyzer traces for both the working condition (NUCLEO board) and the non-working condition (my protoboard). You will see the initialization sequence at the very beginning of the traces.

Please note that I am using the TechTools Logic Analyzer (DigiView Downloads) software in case you have any trouble opening the log files.

Please let me know if you have any questions.

Best,

Naga Amam.

[Brian TIDAL]

Hi,

NFC 5 Click board is not a board designed by STMicroelectronics. Compared to X-NUCLEO-NFC06A1 (ST25R3916), the pull-up resistors are 4.7 kOhm (vs. 1.6 kOhm on X-NUCLEO-NFC06A1). I recommand to check the signal integrity with a scope and to make sure SCL and SDA signals reach valid logic high levels fast enough. Check also the SDA GPIO settings on your MCU (no internal pull).

I also recommand to use the RFAL on your MCU. The RFAL is portable and scalable by design.

Rgds

BT

[NAmam.2]

Hi Brian,

I have made sure the I2C port pins do not have any internal pull-up resistors enabled.

I have also verified that the I2C logic levels are meeting the required specifications.

As you probably noticed in the logic analyzer trace, there is a command to read the CHIP ID (0x7F), followed by the POWER-UP command (0xC1), and I receive the proper response of 0x2A. If there were an I2C logic level issue, I would not expect to receive the correct 0x2A response from the ST25R3918.

Also, for the command:

REG 02 OPERATION CONTROL = 0x80 (Enable Oscillator)

the device generates the IRQ response:

80, 00, 00, 00

This behavior is occurring the same way in both the GOOD case (NUCLEO-F476RG) and the BADBOARD case (my proto board).

Based on these observations, I do not think the issue is related to the I2C logic levels.

Please let me know your comments on this.

Best regards,
Naga Amam

[Brian TIDAL]

Hi Naga,

what I see on the NUCLEO-L476RG trace:

For sure, the I2C signals are not clean. I see also spikes on the IRQ line.

What I see on the proto board:

After the first byte sent by the ST25R3918, the MCU seems to keep SDA to 0 (ACK). This is clearly an issue on I2C.

Could you check you I2C driver regarding the ACK management after the first byte being received?

Rgds

BT

[NAmam.2 · Accepted solution]

Hi Brian,

Great news — I found the problem in my I2C driver. Your feedback helped me identify and resolve the issue.

Thank you very much for the help. It is greatly appreciated.

Best Regards,

Naga Amam.