The initialized st25r3911 cannot detect the existence of the nfcv card

[LevenTao]

I have ported the driver of st25r3911 to nrf52832. At present, it seems that the initialization is normal. The value of the register read after initialization is the same as the value I used using the stm32 development board, but I just can't detect a close nfcv card. I don't know why, 

I checked the code, and it seemed that the nfcv card could not be detected in this place, and then returned the timeout flag

What I can confirm is the following points. The first is that the st25r3911 development board I use is normal, because I can read the data of the nfcv card by using the supporting stm32 development board; the second is that the connection between the st25 development board and the nrf development board is normal, because it can be initialized normally; the third is that when I use stm32 or nrf to drive the st25 development board to initialize, the registers inside the st25 chip read are the same.I can also provide the waveform chart after nrf initialization, using pulseview to view it, But it seems that uploading this file is not allowed in the attachment~~~~

thank you

[Brian TIDAL]

Hi,

make sure the ST25R3911B interrupt pin is properly handled on MCU side and that st25r3911Isr() is properly called by the interrupt handler.

Also, I would suggest to enable ST25R_SELFTEST and ST25R_SELFTEST_TIMER compilation switches and make sure st25r3911Initialize returns RFAL_ERR_NONE.

Rgds

BT

[LevenTao]

hi,

I can confirm that interrupt processing should be normal because I can get the waveform from the logic analyzer

Also, I didn't find any information in the code about  ST25R_SELFTEST or ST25R_SELFTEST_TIMER

[Brian TIDAL]

Hi,

ST25R_SELFTEST and ST25R_SELFTEST_TIMER enable some communication and timer checks during initialization in st25r3911Initialize.

The logic analyzer trace shows that RFAL original driver code (e.g. st25r3911CheckForReceivedInterrupts or st25r3911ReadMultipleRegisters) has been modified. When an interrupt is received, the 3 interrupt registers (main/0x17, timers/0x18 and errors/0x19) are read through 3 elementary SPI read commands (Select 57h 00h Deselect / Select 58h 00h Deselect /Select 59h 00h Deselect) whereas it should be a single SPI command to read the 3 registers consecutively (Select 58h 00h 00h 00h Deselect). 

Can you share information on your SPI driver and RFAL modifications? I would suggest to revert all modifications inside the RFAL and to make sure that the SPI Chip Select management provides support for frames transmission (such as sending 58h 00h 00h 00h as Select 58h 00h 00h 00h Deselect).

Rgds

BT

[LevenTao]

HI,

I basically ported it according to the code of the st25r3911 nucleo-nfc5_1.3.0_Type V read_write block project. The specific key points involved should be the following files

main.c

int main(void)
{
//    bsp_board_init(BSP_INIT_LEDS);
    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    gpio_init();
    uart_init();
    rtc_init();
    hal_spi_init();  //SPI初始化
    nrf_delay_ms(100);
    NRF_LOG_INFO("...start\r\n");
    printf("...start\r\n");
    rfalAnalogConfigInitialize();
    if (rfalInitialize() != ERR_NONE)
    {
        platformLog("RFAL initialization failed..\r\n");
    }
    else
    {
        platformLog("RFAL initialization succeeded..\r\n");
    }
    
    for (int i = 0; i < 64; i++)
    {
        st25r3911ReadRegister(ST25R3911_REG_IO_CONF1 + i, &register_data[i]);
//        nrf_delay_ms(1);
    }
    
    for (int i = 0; i < 64; i++)
    {
        platformLog("[0x%02x] : 0x%02x \r\n",i,register_data[i]);
        nrf_delay_ms(1);
    }
    while (true)
    {
        rfalWorker();
        workCycle();
    }
}

void st25r3911ReadMultipleRegisters(uint8_t reg, uint8_t *val, uint8_t length)
{
    uint8_t buf[2];
    for(int i = 0; i < length;i++)
    {
        platformProtectST25R391xComm();
        platformSpiSelect();
        buf[0] = ((reg+i) | ST25R3911_READ_MODE);
        buf[1] = 0;

        platformSpiTxRx(buf, buf, 2);
        if (val != NULL)
        {
            val[i] = buf[1];
        }
        platformSpiDeselect();
        platformUnprotectST25R391xComm();
    }
    return;
}

These are most of the modified code

[Brian TIDAL]

Hi,

I believe st25r3911WriteFifo and/or st25r3911ReadFifo have also been modified. I suggest to revert all modifications in RFAL files i.e. rfal_*.[ch] and st25r3911*.[ch] files should not be modified (except of course the platform.h file and the main.c file that need to be customized)

If you still have some issues, can you provide a logic analyzer log (not screen capture but the raw file from the logic analyzer).

Also confirm whether you are using an X- NUCLEO-NFC05A1 connected to your MCU or a custom board.

Thanks

Rgds

BT

[Ulysses HERNIOSUS]

Hi LevenTao,

Brian is right: Best would be a logic analyzer trace. I saw you struggling with attaching: This forum is only accepting white-listed attachments. I believe .zip is white-listed, so you can just put the file in a zip.

BR, Ulysses

[LevenTao]

hi, both

Thank you very much for your reply. First of all, the.zip file is not supported. and it seemed that the.tar file was rejected when I send the reply,as for the readfifo function, I am sure that there has been no modification. I use X-NUCLEO-NFC05A1;

thanks a lot

[Ulysses HERNIOSUS · Accepted solution]

Hi LevenTao,

inspecting the trace you shared I find:

• 1E B0 : Number of transmitted bytes: 0xb * 2 = 22 bytes to be transmitted
• 80 21 .......02 Write FIFO with 21 bytes
• C5 Transmit without CRC direct command

The coding for an EOF for NFCV is 0x04 (#define ISO15693_DAT_EOF_1_4 0x04). So the transmitted frame is one byte short - missing the EOF. This will not be understood by the card and no answer will be provided.

Please check your SPI driver, where this last byte gets lost.

I still see the interrupt status register being read one by one. This violates DS ("The
interrupt registers 0x17, 0x18 and 0x19 are to be read in one attempt."). So please revert all the changes on the interrupt system. Even if working now with single reads, it cries out for problems in future.

Regards, Ulysses

[LevenTao]

I did know that it might be a driving problem, so I read the single register of 171819 separately, because when nordic's spi library reads multiple bytes, it does not regard the first byte returned as the first byte to be read, but the second byte. Therefore, it could not be driven before, but later it was normal to at least interrupt reading after changing to a single-byte read. Regarding the first problem you mentioned, I will investigate this aspect.