Skip to main content
D
dwagner4
Visitor II
February 4, 2024
Solved

X-CUBE-NFC6 Polling demo modification and sending commands to NTP5332 NFCV tag

  • February 4, 2024
  • 1 reply
  • 3120 views

Hello,

I am a university student working for the first time with anything NFC.  I have an X-NUCLEO-NFC08A1 board on a NUCLEO-L476RG, and the X-CUBE-NFC6 demo applications work fine for me.

I am just getting into the RFAL, and had a question about some custom commands that are implemented on the NTP5332 from NXP (the OM2NTP5332 dev board, to be precise).

The datasheet for the NTP5332 uses the custom commands WRITE_CONFIGURATION (code 0xC1) and READ_CONFIGURATION (code 0xC0) to set up the device's GPIO pins and other things, instead of the mandatory T5T commands READ SINGLE BLOCK and WRITE SINGLE BLOCK. (or their MULTIPLE block counterparts).  The datasheet section for READ CONFIGURATION is below.

dwagner4_0-1707090257720.png

I am following along with NXP's application note AN11203 which goes over setting GPIOs as inputs/outputs and reading their status from the RF perspective.  I had success writing to and reading from user EEPROM using the RFAL functions rfalNfcvPollerReadSingleBlock() and rfalNfcvPollerReadWriteBlock(), but things seem to go amiss when using those commands for reading/writing to the CONFIG blocks of the NTP5332.  The application note describes some commands to configure GPIO0 as an input and to read the status:

dwagner4_1-1707090592780.png

My main question is: what is the best way to go about using the functions in the Polling demo and RFAL to implement these custom commands?  I'm really quite new at this, and have been trying to use a function based on rfalNfcvPollerReadSingleBlock()that really only tries to pass the command 0xC0, the parameter 2, and the flag 4 to rfalNfcvPollerTransceiveReq, but no luck (I am getting a timeout error code).

dwagner4_2-1707090895442.png

 

 

Just wanted to see if there was a better/simpler way to go about testing this out that I am missing.

 

Thank you.

    This topic has been closed for replies.
    Best answer by dwagner4

    I think I have found my issue.

    In the function rfalNfcvPollerTransceiveReq() inside rfal_nfcv.c there is a block that checks if cmd is one of ST's Fast Commands:

    dwagner4_0-1707338749712.png

    Unfortunately, RFAL_NFCV_CMD_FAST_READ_SINGLE_BLOCK = 0xC0 (which is the command I am trying to send), and there is no checking of the Manufacturer parameter to make sure that this cmd isn't a different custom command.

    As you can see, I have commented out the offending portion, and everything works as expected with NXP's custom NFCV commands.  Perhaps there should be a check for the manufacturer parameter here (as I thought that is their purpose)?

    Thank you for your help, regardless.

    1 reply

    U
    Ulysses HERNIOSUS
    Technical Moderator
    February 5, 2024

    Hi dwagner,

    looks almost right what you are doing. I think you are missing sending the secondary 0xA0 command code. So I think you need to defined a uint8_t tx_buf[2] = { 0xA0, blockNum} which you need to send. 

    Above snippets ask to send no UID, so please use a NULL for this parameter.

    BR, Ulysses

     

    D
    dwagner4Author
    Visitor II
    February 5, 2024

    Thank you for your reply.  I have updated my function to this:

    dwagner4_0-1707176534941.png

    So, just for testing, the parameters flags and uid aren't used, and instead I hard code the values passed to rfalNfcvPollerTranceiveReq(). It is being used in the X-CUBE-NFC6 example application demo_polling, inside the demoNfcV() function like this:

    dwagner4_1-1707176633007.png

    And it is not quite working for me.  The output to the console is this:

    dwagner4_2-1707176693408.png

    and when I debug, I can see that err = 4, which is RFAL_ERR_TIMEOUT.  Do you have any thoughts as to where I might look next?  It seems that inside of rfalNfcvTranceiveReq() the message is being built properly, but I'm a little out of my depth.  Thank you.

    U
    Ulysses HERNIOSUS
    Technical Moderator
    February 6, 2024

    Hi,

    any reason why you reversed the txBuff and why you changed the 0xA0 to 0x00?

     

    Ulysses

    Terms & ConditionsAccessibility statement