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

[dwagner4]

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.

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:

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).

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

Thank you.

[Ulysses HERNIOSUS]

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

[dwagner4]

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

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:

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

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.

[Ulysses HERNIOSUS]

Hi,

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

Ulysses

[dwagner4]

Please correct me if I'm seeing this the wrong way.  The format of the READ_CONFIGURATION command (0xC0) is:

So, in the example from NXP AN11203 (RF command I am trying to send)

The 0x00 corresponds to the number of blocks+1 that will be read, and 0xA0 is actually a block address (I believe) which corresponds to the session register (in configuration memory) STATUS_REG:

And the bits I am interested in (bits 3 and 4) are in byte 1, STATUS1_REG:

So, in my test function, blockNum=0xA0 (the block address of STATUS_REG) and 0x00 is the number of blocks+1 to be read.  I tried reversing the order, but same return error code.

If it makes any difference, this is what the response to the command 0xC0 is supposed to look like:

I am not sure if this differs from what the response from a typical READ SINGLE BLOCK command would be, and if maybe this is my issue.

Thank you, again.

[Ulysses HERNIOSUS]

Hi,

now I understand better. The AN seems to have a typo: Using "Command Code | Block Address"  instead of "Block Address | Block Number". So I think my proposal of sending {0xA0, 0x00} is the right one. But I don't believe this is the reason for not answering at all.

With this information it all looks about right what you are doing.

To debug further I would (maybe you already did some of it):

1. Instead of READ CONFIGURATION send a READ SINGLE BLOCK command using the very same code you are using now.
2. Same with a READ MULTIPLE BLOCKS
3. Same with GET NXP SYSTEM INFORMATION and carefully check the response (features) to see you are indeed talking to the expected tag.

BR, Ulysses

[dwagner4 · Accepted solution]

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:

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.

[Ulysses HERNIOSUS]

Hi,

in our not yet released code base the manufacturer code is also checked.
This will enter the next release of RFAL.

Sorry for the inconvenience!

BR, Ulysses