2019-05-02 03:03 AM
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
Solved! Go to Solution.
2019-05-06 02:22 AM
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
2019-05-02 04:29 AM
Hi,
Please provide a few more details on your procedure:
Some hints from my side:
Regards, Ulysses
2019-05-02 05:56 AM
Hi Ulysses,
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
2019-05-02 06:43 AM
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.
Which exact tags do you use? Where could I get some samples of these tags?
Ulysses
2019-05-03 05:09 AM
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:
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
2019-05-05 11:30 PM
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):
Regards, Ulysses
2019-05-06 12:35 AM
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
2019-05-06 02:22 AM
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
2019-05-06 05:32 AM
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
2019-05-06 08:14 AM
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