Skip to main content
ACogl
ACogl
Associate II
May 2, 2019
Solved

ST25TB tag not recognized by X-NUCLEO-NFC05A1 but recognized by ST25R3911B-DISCO.

  • May 2, 2019
  • 9 replies
  • 2123 views

Hi,

I was evaluating ST25R3911B with 2 evaluation boards: ​X-NUCLEO-NFC05A1 mounted over NUCLEO F401RE and ST25R3911B-DISCO.

Regarding X-NUCLEO-NFC05A1 I have uploaded the bin file found in X-CUBE-NFC5 and I have started the terminal as explained in the application note. When I use my ST25TB tags, some of them are recognized and the terminal prints out the UID number, other are not recognized.X-CUBE-NFC5.

Regarding the ST25R3911B-DISCO I have uploaded the bin file found in ST website, I launch ST25r3911B Disscovery GUI, I select the polling function, and the program recognize all the ST25TB tags that I use.

I do not think it is a matter of antenna, because all the tags are recognized.

After debugging the project for IAR found in X-CUBE-NFC5, I have discovered that with the tags not read function rfalSt25tbPollerInitiate returns ERR_FRAMING.

So the question is why do the ST25R3911B-DISCO recognizes all the tags while the X-NUCLEO-NFC05A1 does not?

Best regards

This topic has been closed for replies.
Best answer by Ulysses HERNIOSUS

Hi Alessandro,

I am able now to replicate the issue by moving from L4 to F4. It seems to be related to the SPI, the driver on F4 may be a bit different. We are still investigating details but it seems I have for now already a workaround by adding a line in your spi.c as below:

uint8_t SpiTxRx(const uint8_t *txData, uint8_t *rxData, uint8_t length)
{ 
 if(pSpi == 0)
 return ERR_INVALID_HANDLE;
 
 uint8_t tx[256];
 uint8_t rx[256];
 if(txData != NULL){
 ST_MEMSET(tx, 0 ,sizeof(tx)); /* ADDED CODE, make sure tx buf is cleared. */
 ST_MEMCPY(tx, txData, length);
 }
 return HAL_SPI_TransmitReceive(pSpi, tx, (rxData != NULL) ? rxData : rx, length, SPI_TIMEOUT);
}

Regards, Ulysses

9 replies

Ulysses HERNIOSUS
Ulysses HERNIOSUS
ST Technical Moderator
May 2, 2019

Hi,

Please provide a few more details on your procedure:

  1. Which software versions of XCUBE-NFC5 and ST25R3911B-DISCO GUI/FW were you using?
  2. Do I understand correctly that with NFC5 you can recognize the every single presented tag but not when multiple tags are presented at the same time? If not then please describe what you mean by ".. all tags are recognized" vs. "...ST25R3911B-DISCO recognizes all the tags while the X-NUCLEO-NFC05A1 does not"

Some hints from my side:

  • Antenna can matter if you present multiple tags then some of them may not get enough energy anymore. The Disco antenna is here superior as it has the bigger antenna and more output power.
  • XCUBE-NFC5 is built to only recognize one tag: rfalSt25tbPollerCollisionResolution(1, &st25tbDev, &devCnt): The 1 limits the number of tags to be found.
  • rfalSt25tbPollerInitiate returning ERR_FRAMING is normal/expected when multiple tags are presented at the same time as their answers will collide and garble each others modulation. If error is reported then the software will go on and issue Pcall16 to resolve the collisions.

Regards, Ulysses

ACogl
ACoglAuthor
Associate II
May 2, 2019

Hi Ulysses,

  1. I'm using XCUBE-NFC5_V1 3.0, and the lastest firmware on ST25R3911B, updated through ST25r3911B Discovery GUI.
  2. I just want to read one ST25TB tag at time. I have 2 identical ST25TB tag, more precisely ST25TB512-AT. They are both recognized by  ST25R3911B-DISCO and I can retrieve their UID, while with X-NUCLEO-NFC05A1 only one of them is recognized.

I have added Platform log in demo.c file, demoPollST25TB and the problem seems to be that the returned error is ERR_FRAMING.

When I put the not recognized tag on X-NUCLEO-NFC05A1, the terminal print stops, because the program seems to be blocked in the DO-WHILE function of rfalSt25tbPollerCollisionResolution, because detected==true, but ret is ERR_FRAMING.

Best regards

Alessandro

Ulysses HERNIOSUS
Ulysses HERNIOSUS
ST Technical Moderator
May 2, 2019

Hi Alessandro,

I only have ST25TB512-AC tags at hand and with these ~15 tags I was not able to reproduce the behavior.

Reading your description it means also rfalSt25tbPollerPcall()/rfalSt25tbPollerSlotMarker() return ERR_FRAMING.

  • Do all of them or only some of them return ERR_FRAMING? Typically there should be one rfalSt25tbPollerPcall() followed by 15x rfalSt25tbPollerSlotMarker()
  • In which distance does this happen? Does it also happen in other distances? Let's say 0, 1 and 2 cm z-distance

Which exact tags do you use? Where could I get some samples of these tags?

Ulysses

ACogl
ACoglAuthor
Associate II
May 3, 2019

​Hi Ulysses,

I have done some reasearch in the factory in order to give you the right information.

We are using 2 types of tag:

  1. ST ST25TB512-AC tags
  2. ST SRI512

ST25TB512-AC are recognized by both ev-board (X-CUBE-NFC5 and ST25R3911B-DISCO ), while SRI512 are recognized only by ST25R3911B-DISCO.

Using SRI512 tags, ST25r3911B Discovery GUI identifies the column type as ST25TB.

Tags SRI512 are not recognized by X-CUBE-NFC5,  the microcontroller is locked in the DO-WHILE function of rfalSt25tbPollerCollisionResolution.

All of SRI512 tags have this problem, I have tried at different distances, from contact to 10 cm, but nothing changes.

I have always tried one SRI512 tag per time, so there shouldn't be any collision.

It seems that the demo software on ST25R3911B-DISCO is able to recognize SRI512 tags and retrieve their UID, while X-CUBE-NFC5 software is not able to retrieve UID of SRI512.

Best regards

Alessandro 

Ulysses HERNIOSUS
Ulysses HERNIOSUS
ST Technical Moderator
May 6, 2019

Hi Alessandro,

I have 7 SRI512 tags available, all of them work on X-CUBE-NFC5. Same for my SRi2K tags. From a reader perspective both SRI512 and ST25TB support the same command set. A reader cannot easily distinguish them so they both appear as "ST25TB" technology.

I am puzzled by this and cannot really say if this issue now relates to difference in Reader HW, Reader SW or Tag HW. Reading the thread I don't see a mention of the used Nucleo board which may be relevant: Which Nucleo are you using? All my experiments were using L476RG.

At this stage I can only offer you a list of things to try (with increasing effort):

  1. Try attached binary for STM32L476RG: It works here with all the ST25TB/SRI tags. This verifies there is no relevant difference in compilation.
  2. Send me your used binary for me to try on my side. If I see it fail I can do some debugging.
  3. In case your are running on L4: Connect an USB<->UART connector to ST25R3911B-DISCO and use the GUI to update it with your hex for L4 NFC5. This figures if a difference in HW makes it fail.

Regards, Ulysses

ACogl
ACoglAuthor
Associate II
May 6, 2019

​Hi Ulysses,

I am using NUCLEO-F401RE as evaluation board.

You can find attached the bin file I have uploaded on it. This bin file is taken from X-CUBE-NFC5, folder: STM32CubeExpansion_NFC5_V1 .3.0/Project/multi/Application/Polling/Binary.

With this binary file X-NUCLEO-NFC05A1 can read ST25TB but can't read SRI512 tag.

If it can help you, I can send a physical sample of the tags we are using.

Best regards

Alessandro

Ulysses HERNIOSUS
Ulysses HERNIOSUSBest answer
ST Technical Moderator
May 6, 2019

Hi Alessandro,

I am able now to replicate the issue by moving from L4 to F4. It seems to be related to the SPI, the driver on F4 may be a bit different. We are still investigating details but it seems I have for now already a workaround by adding a line in your spi.c as below:

uint8_t SpiTxRx(const uint8_t *txData, uint8_t *rxData, uint8_t length)
{ 
 if(pSpi == 0)
 return ERR_INVALID_HANDLE;
 
 uint8_t tx[256];
 uint8_t rx[256];
 if(txData != NULL){
 ST_MEMSET(tx, 0 ,sizeof(tx)); /* ADDED CODE, make sure tx buf is cleared. */
 ST_MEMCPY(tx, txData, length);
 }
 return HAL_SPI_TransmitReceive(pSpi, tx, (rxData != NULL) ? rxData : rx, length, SPI_TIMEOUT);
}

Regards, Ulysses

ACogl
ACoglAuthor
Associate II
May 6, 2019

​Hi Ulysses,

thank you, with the added line the X-NUCLEO-NFC05A1 is able to recognize both ST25TB and SRI512 tags.

It works!

Just one further question: since the application running on the microprocessor is really simple, my idea is to use an STM32F0 (it should be an STM32F072C8U) as final design. Do you think  will be necessary to add any other instruction (such as  ST_MEMSET)  in order to make it work with STM32F0?

Best regards

Alessandro

Ulysses HERNIOSUS
Ulysses HERNIOSUS
ST Technical Moderator
May 6, 2019

Hi Alessandro,

targeting F0 (Cortex-M0) I advise to make sure inside spi.c that data goes 16-bit aligned into HAL driver.

Besides please again perform the memset as above.

Regards, Ulysses

Terms & ConditionsAccessibility statement