Skip to main content
R
RMuiz.1
Explorer
June 28, 2023
Solved

Help finalizing custom Rust driver (st25r3911b)

  • June 28, 2023
  • 1 reply
  • 3585 views

Hi!

A while back I started writing Rust driver for st25r3911b chip. Currently, it works and can read 14443A chip. The issue is that compared to official software (Discovery GUI) the read distance is about half. So if official software reads at 8-9cm then with rust driver it would just 5-6 cm.

I feel like I have messed up some register configurations. My knowledge of RF is very limited. Could someone point me in the right direction of what I should look into?
https://github.com/xpresshd/st25r3911b/blob/master/src/lib.rs#L168

Thanks!

 

    This topic has been closed for replies.
    Best answer by Brian TIDAL

    Hi,

     

    @RMuiz.1 wrote:

    What confuses me is why Intr jumps back high when I start reading interrupt registers


    See  § "Interrupt interface" in the ST25R3911B datasheet: [...]IRQ pin transitions to low after the interrupt bit(s) that caused its transition to high has (have) been read.

    It is likely that a second interrupt is signalled while reading the second interrutp register (likely I_rxe interrupt).

    Make sure to configure the Salae SPI decoder with CPOL=0 and CPHA=1 to properly decode the SPI frames. The SPI CS handling seems to be erroneous (except if another devices are connected to the SPI bus):

    BrianTIDAL_0-1688741138271.png

    The SPI clock seems to be quite low (300 kHz). Our demos use a SPI clock = 3Mbps.

    Rgds

    BT

    1 reply

    U
    Ulysses HERNIOSUS
    Technical Moderator
    June 28, 2023

    Hi,

    could be that this is an effect of not setting the antenna calibration and target registers the same way as in the original FW. Which trim value is being achieved, or does it return an error?

    Regards, Ulysses

    R
    RMuiz.1Author
    Explorer
    June 29, 2023

    I did a few changes with the main firmware that doesn't impact driver logic and now the read distance is fine again. I'm very confused, but it seems to work. Maybe some race condition...

    What is the correct way to check the error here? Currently, my calibrate logic looks like this (It should be the same as the official soft) https://github.com/xpresshd/st25r3911b/blob/jonas/src/lib.rs#L177

    One thing that still bothers me is that driver crashes ~3 times per minute with IOError (Most often), FarmingError or InterruptTimeout. Even if there are no tags around.
    It happens somewhere here https://github.com/xpresshd/st25r3911b/blob/jonas/src/lib.rs#L339
    One thing I suspect is - `wait_for_interrupt` will sleep minimum 1ms and could be a lot longer if RTOS prioritizes other tasks. Could it be that there is a time limit in which I must process interrupt or it will move to another state?

    Update:
    I have noticed that after some reqa/wupa calls they stop getting back card data until the chip errors and is restarted. Could it be that I forgot to handle some error case? What could be the reason that reqa/wupa transmit is still called in a broken state, but no error is returned?

     

    U
    Ulysses HERNIOSUS
    Technical Moderator
    June 29, 2023

    Hi,

    please investigate the conditions in which your code returns IOError. The chip does not have such an error. Also InterruptTimeout should be more on your driver side. The FramingErrors sounds as being signaled by the ST25R3911B but you need to describe a bit more under which exact conditions. The error means incorrect framing over the RF. Such typically only happens close to the maximum operating range.

    I think it would be helpful if you look at he SPI layer (maybe using logic-analyzer with SPI+INT pin) to be able to see what is happening on the chip and what is happening within your driver.

    An NFC reader typically defines the pace there are typically no situations when it might be too late when only handling anticollision. Handling the FIFO water level (>96bytes) is of course timing critical.

    Best Regards, Ulysses

     

    Terms & ConditionsAccessibility statement