X-NUCLEO-NFC08A1 tag not detecting in i2c

[BS]

Hello,

I am using X-NUCLEO-NFC08A1(ST25R3916B) with Dialog DA14706 MCU , ported the X-CUBE-NFC6 library and first tested for SPI , and it has worked fine(getting Tag UID) . Then i have done some modifications in hardware (Pull-up resistors 1.6K , Made i2c_en high, solder bridges) as well as in Software (defined the macro RFAL_USE_I2C). Still can't get tag UID. 

By the way ,both Timer tests , antenna RF field (13.56MHz) and chip id (0x31) , all are checked, found correct.

Thanks for your help

[Brian TIDAL]

Hi,

 

can you enable the ST25R_SELFTEST compilation switch and make sure st25r3916Initialize() function returns no error?

Can you connect a logic analyzer on I2C (SCL, SDA) and IRQ_3916 and send the trace (raw file)?

Rgds

BT

[BS]

Hi,

 

I enabled the ST25R_SELFTEST & ST25R_SELFTEST_TIMER and debug the code , st25r3916Initialize() returns RFAL_ERR_NONE.

I captured the Logic analyzer data , i have attached the file, PFA.

[Brian TIDAL]

Hi,

it seems Salae Logic Analyzer has been used. Can you share the raw binary file?

Thanks

Rgds

BT

[BS]

Hi Brian, 

I am sharing you the folder by the sharepoint link,

https://glidemtech-my.sharepoint.com/:u:/p/bhupendrar/ESbBreAu8dBBnsVW8l6zFdABevCog6HlIbqPoy2ezjvj9Q?e=rF71Ra

Thanks

[Ulysses HERNIOSUS]

Hi BS, 

Hi BS,

thanks, Saleae trace is welcome. In a future step it would also be useful if you share not only the initialization but also the complete failed attempts to read a UID.

In any case I analyzed based on your Excel and I found an unexpected behavior as repeated Start is performed where it shouldn't:

Please fix these repated starts and maybe it starts working. What I am seeing as well that your I2C driver has huge delays - this will for sure also lead to one problem or the other.

BR, Ulysses

[BS]

Hi  Mr. Ulysses Herniosus,

Solved the issue of repeated start in i2c, but UID not found.

I captured the data by logic analyzer with failed attempts also. In the example code i have disabled the PLATFORM_USER_BUTTON_PIN, so this LA data is for the continuous execution of MX_X_CUBE_NFC6_Process function, and the tag is placed on the NFC antenna.

LINK

 

Thanks,

[Ulysses HERNIOSUS]

Hi BS,

as feared before: With such slow I2C more issues will be ahead:

You are seeing here: 

1. C6 command: Send NFC-A REQA
2. 5A - 38 ..., the 38 denoting that data has been received (I_rxs, I_rxe, I_txe)
3. 16 - 87 : Clearing of interrupts, software does that if no interrupts have been received within I think 1ms

So the actual data is disregarded by software due to slow IRQ handling. Above I find almost  2ms between sending the 5A byes until starting to receive.

I think you need have few fronts to work: Assure that interrupts are handled before the timers expire. And overall I recommend to remove those delays in the I2C. 

Also I consider it likely that you can remove some technologies if you only want to read normal cards: AP2P and maybe also ST25TB.

BR, Ulysses

[BS]

Hi Mr. Ulysses Herniosus,

Problem resolved, Thank you so much, I am deeply indebted to you for your invaluable assistance. Actually, i am using RTOS, so i had created a distinct task to read registers post interrupt. And my mistake was, this task priority is set same as normal running task.

The reason I overlooked the priority parameter is because I obtained the UID from SPI using the same code and timer tests were also passed.

After all the issue has been resolved.

Thanks Again.