Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nfc_t4t_lib

Hi,

My problem is that reader sends PPS command (both DRI & DSI set to 0) for which there is no response/confirmation from library, and I don't know how to implement this response because in raw mode library passes through only I-blocks to application layer. Library lack of response to PPS prevents me from entering ISO14443-4 I-block exchange. Is there any way to overcome this, or own driver needs to be build on the basis of nrfc_nfct ?

Regards,

Marcin  

Parents Reply Children
  • Hi, Thanks for the prompt reply, meanwhile I wrote my own driver and it performs quite well. I just noticed one strange phenomena (maybe not very important) - communication with the reader looks like below: 

    0 | 1056 | Rdr | 26 | | REQA
    2244 | 4612 | Tag | 44 00 | |
    134576 | 137040 | Rdr | 93 20 | | ANTICOLL
    138228 | 144052 | Tag | 88 1a 1b 1c 95 | |
    275568 | 286096 | Rdr | 93 70 88 1a 1b 1c 95 c0 45 | ok | SELECT_UID
    287284 | 290804 | Tag | 04 da 17 | |
    460832 | 463296 | Rdr | 95 20 | | ANTICOLL-2
    464484 | 470308 | Tag | 1d 1e 1f 2a 36 | |
    603760 | 614288 | Rdr | 95 70 1d 1e 1f 2a 36 22 61 | ok | ANTICOLL-2

    and so on...

    but I noticed that when I try to send one byte (04) + (da 17) CRC calculated in nrf52840, then RX_FRAMEEND event causes that I read 95 70 ... so it looks like the second byte comes from the previous reader's frame)

    When I try to send (04 da 17) - this is without CRC calculation in nrf52840 then everything is OK.

    In both cases I call  nrfx_nfct_rx(...) in TX_FRAMEEND event where easyDMA is initialized for Rx.

    On the other hand, I didn't notice any problems when Tx/Rx buffers are separate (or in case of longer - non 1 byte+crc frames).

    Regards,

    /Marcin

  • Sounds like a race condition, e.g. NFC Easydma fetch data asynchrounuos to the CPU interrupt do update/read the data. Using separate buffers sounds like a good idea.

Related