Not able to read the UID from tags

[KElli.1]

I'm using an ST MCU (STM32F765VGT6) on a custom board, wired to an X-NUCLEO-NFC06A1 communicating via I2C. I've integrated the RFAL library into an existing codebase. I've taken elements of the Disco demo code into our codebase, to exercise the RFAL. (It is based on the PollingTagDetect example, demo_polling.c, from STM32CubeExpansion_NFC6_V1.1.0)

I am able to detect a tag, but the UID is returning as blank. I'm not seeing any I2C traffic on the Saleae analyzer that looks like the ID, so I don't think it is being retrieved from the reader. The code isn't breaking anywhere that seems to write to nfcId1, but it's a little hard to track down which variable it's actually stored in. Can you point me to where in the RFAL library you'd expect the nfcId1 variable to be stored for a NFCA type 2 tag? 

For I2C are there any gotchas similar to the SPI gotachas (where you need to have a separate GPIO controlling CS)? 

Any other suggestions for tracking this down? 

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi Katie,

do you want to say that you enter:

            if( rfalNfcIsDevActivated( rfalNfcGetState() ) )
            {
                rfalNfcGetActiveDevice( &nfcDevice );
                switch( nfcDevice->type )
 
...
 
                            default:
                                platformLog("ISO14443A/NFC-A card found. UID: %s\r\n", hex2Str( nfcDevice->nfcid, nfcDevice->nfcidLen ) );

and in the switch it prints but nfcId is empty? This would sound more like an issue in your print implementation.

Inside our RFAL the nfcId1 should be copied inside rfalNfcPollActivation() from nfcId1 into nfcId.

Best Regards, Ulysses

[KElli.1]

Yes, exactly. But it is not print: when I break in code, nfcidLen = 0, and nfcid is all zeros. I assume they have not been modified since they were initialized, and that the problem is that I'm not getting to wherever they are set. I am not exactly sure where that is. I am also not seeing any I2C traffic with the UID, so it doesn't look like we retrieved it from the reader.

Thanks,

Katie

[KElli.1]

To follow up, in rfalNfcPollActivation we copy from nfcid1, but nfcid1 is also 0. So where should nfcid1 be set? Or rather, where in the library is the actual request to the reader to return the ID (a FIFO read)?

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi Katie,

in the end this is done through calls to rfalISO14443AStartTransceiveAnticollisionFrame().

Symptoms like you are explaining here may be caused by insufficient protection of the I2C calls from both main and interrupt level.

Please check those and if you find nothing then it would be beneficial if you can share logic analyzer traces (I2C + INT pin) to see what is going on.

Best Regards, Ulysses

[KElli.1]

I've attached a capture of a Saleae trace including I2C + INT. I believe I have sufficient protection, but I will double check in the I2C driver as well. Thank you very much for your time.

-Katie

[Ulysses HERNIOSUS]

Hi,

Looking at I2C I find that UID on CL1 is being received by the chip but not read from the FIFO (look at last interrupt which is I_rxs).

Looking in the trace I find something very suspicious:

The FB is the marker to start a register access in space B. However it is not completed and a Stop and Start is getting executed.

Corresponding code is inside st25r3916ReadMultipleRegisters / st25r3916WriteMultipleRegisters:

ReturnCode st25r3916ReadMultipleRegisters( uint8_t reg, uint8_t* values, uint8_t length )
{
    if( length > 0U )
    {
        st25r3916comStart();
 
        /* If is a space-B register send a direct command first */
        if( (reg & ST25R3916_SPACE_B) != 0U )
        {
            st25r3916comTxByte( ST25R3916_CMD_SPACE_B_ACCESS, false, false );
        }
 
        st25r3916comTxByte( ((reg & ~ST25R3916_SPACE_B) | ST25R3916_READ_MODE), true, false );
        st25r3916comRepeatStart();
        st25r3916comRx( values, length );
        st25r3916comStop();

Such single FB bytes should not occur and are likely an indication of issues in your i2c port.

Best Regards, Ulysses

[KElli.1]

Hi Ulysses,

Thank you for the I2C tip. I believe I have resolved that part of the issue and am properly accessing the Register B space. However, I still don't see a read of the ID. I've attached another Saleae trace.

Should I be getting to the RFAL_NFCA_CR_SEL case in rfalNfcaPollerGetSingleCollisionResolutionStatus? That seems like a place where the ID is written, but we are not getting there.

Thanks,

Katie

[Ulysses HERNIOSUS]

Hi,

I saw some glitches on INT pin and enabled the glitch filter (1us). The last interrupts happening indicate I_rxs,I_rxe @7.138sec from the chip, so part of the UID is received, then some other I2C slave is addressed (addr 0x90) followed by clean-up of the transceive but no reading of FIFO data).

I suspect long delays in your code and software going into error handling despite interrupts happending correctly (could also be related to MCU timers).

Best Regards, Ulysses

[KElli.1]

Hi Ulysses,

I removed some printing which could have caused delays along with access to the other I2C device. (and also fixed the ground problem causing those glitches)

At 3:77ms, I see it read the FIFO status register, which looks like it says only 2 bytes are available. I was expecting more (aren't we getting the UID?). Then it reads 2 bytes from the FIFO, but those 2 bytes don't correspond to what I'd expect. The tag ID is: 04:38:81:EA:F4:73:81

Are there particular error handling functions I could check for in the code?

See attached Saleae trace.

Thanks,

Katie