2020-05-28 06:42 AM
Hello,
I am currently working on a project with the CR95HF chip. The chip has to be controlled over UART (by a STM32L4S7ZITx) and I would like a library which provides basic functions, such as being able to read a presented tag's UID and be able to read from and write to the presented tag.
Does the X-CUBE-NFC3 library provide this functionality?
If so, how exactly do I integrate it into my existing STM32CubeIDE project? I am aware it cannot be added through STM32CubeMx so of the whole download provided at https://www.st.com/en/embedded-software/x-cube-nfc3.html#overview what part needs integrated into my project to get the functionality described above and how do I do this?
Thanks!
Amy
Solved! Go to Solution.
2020-06-01 02:53 AM
Hi,
/* USER CODE BEGIN 4 */
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)
{
if (huart->Instance == USART1)
{
st25r95UartTxCpltCallback();
}
}
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
if (huart->Instance == USART1)
{
st25r95UartRxCpltCallback();
}
}
void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart)
{
if (huart->Instance == USART1)
{
st25r95UartErrorCallback();
}
}
/* USER CODE END 4 */
Rgds
BT
2020-06-02 12:50 AM
Thank you so much! I've now managed to get the demo working using UART on the demo board.
I have tried to implement it on my custom board and the initialisation succeeds but when it is polling for tags it runs into a problem. Within rfalNfcWorker state RFAL_NFC_STATE_POLL_TECHDETECT the function rfalNfcPollTechDetetection does not return a tag type even when a tag is presented.
Having stepped through the code the issue appears to be the rfalTransceiveBlockingRx function several layers down. The equivalent transmit function (rfalTransceiveBlockingTx) executes successfully so my question is what could be causing the rfalTransceiveBlockingRx function to fail?
On my custom board the only lines connecting the STM to the CR95HF are UART Rx and Tx so is another line required for the library to operate?
Thanks again so much for all your help.
Amy
2020-06-02 02:42 AM
Hi,
I guess the CR95HF returns 0x87 0x00 to the SendReceive command and then rfalTransceiveBlockingRx returns ERR_TIMEOUT? In such a case, I would suspect an antenna issue... Using a scope to probe the signal and see whether the tag is responding (or not) may help.
Have you followed recommendation from AN5248?
Rgds
BT
2020-06-15 07:58 AM
Hello,
The antenna issue is now resolved, thank you!
Could you please tell me if the X-CUBE-NFC3 library is MISRA C 2012 compliant?
Thank you!
Amy
2020-06-15 08:23 AM
Hi
our coding rules include MISRA rules (with some documented exceptions, see MISRA comment into the C sources). The MISRA Checker has been ran on the RFAL and NDEF libraries but not on the ST25R95 driver as this device is not an automotive grade device.
If you need to use an automotive grade NFC reader device for your application, you should consider either:
Note: from software point of view, you can easily move from ST25R95 to ST25R3914 or to ST25R3920 as the RFAL API is the same accross the ST25R NFC reader family.
Rgds
BT
2020-06-16 12:55 AM
Hello,
Ok, thank you. So for the whole library to be MISRA compliant the ST25R95 driver would need to be re-written to comply with MISRA?
Also, looking at how to read from and write to RFID tags using the X-CUBE-NFC3 library there appears to be functions specifically for this for nfc type V (e.g. rfalNfcvPollerExtendedReadMultipleBlocks, rfalNfcvPollerExtendedWriteMultipleBlocks) but none for nfc type A. Is there an easy way to read from and write to nfc type A tags using the X-CUBE-NFC3 library?
Thanks again!
Amy
2020-06-16 02:00 AM
Hi Amy,
Compliancy with MISRA is a complex topic. MISRA defines guidelines classified as Mandatory, Required (i.e. subject to déviation) or Advisory (good practices but one can deviates as well). So MISRA compliancy has a meaning only with a report listing the various deviations. A typical example is [MISRA 2012 Rule 15.5, advisory]: A function should have a single point of exit at the end. It is a very discutable rule that can lead to a less readable code, less maintenable code, etc. So it is quite common to deviate from this rule. Regarding the ST25R95 driver, reaching MISRA compliancy is rather a matter of documenting deviation to rules rather than re-writting the code.
Just for my understanding, why do you need to be MISRA compliant whereas the ST25R95 is not automotive grade?
Regarding your second point (NFC-A), NFC Forum defines 3 different types of tags using NFC-A synchronization mechanism:
The RFAL provides API for Type 1 (respectively Type 2 and Type 4) in rfal_t1.c (respectively rfal_t2.c and rfal_t4.c). You can find some examples of those API in the NDEF library (by the way, the NDEF lib provides an easy way to read/write in tags thanks to ndefPollerReadBytes/ndefPollerWriteBytes API).
Rgds
BT
2020-06-17 12:29 AM
Hello,
The project we are currently working on has specified that the software be written to MISRA C 2012 standard, so that's why I was wondering about the library as I have integrated it as part of the project now.
Thank you for your advice to use the ndef library for reading/writing to tags. I have tried the ndef_example_read.c example and ndefPollerContextInitialization succeeds but ndefPollerNdefDetect returns with ERR_REQUEST. What causes the function to return with this error?
Also, is the structure given in this example: ndefPollerContextInitialization followed by ndefPollerNdefDetect followed by ndefPollerReadRawMessage the usual format for reading a message from a tag?
Thank you in advance!
Amy
2020-06-17 12:55 AM
Hi Amy,
Can you share more details about your application:
ndefPollerNdefDetect() does the NDEF detection procedure and is intended to work with an NDEF formatted tag, i.e. a tag having a Capability Container. If the tag used on your side is not NDEF formatted, ndefPollerNdefDetect() fails.
ndefPollerReadRawMessage() does the NDEF read procedure i.e. reads an NDEF message from a NDEF formatted tag.
If your application needs only to read/write data from/to a tag, you don't need ndefPollerNdefDetect nor ndefPollerReadRawMessage.
Rgds
Bruno
2020-06-17 02:27 AM
Hi Bruno,
The application requires the ability to read and write basic information to a tag when presented. Currently the only cards I have for development are MIFARE Classic 4K cards and the card which comes as part of the M24LR-discovery kit. I am aware that the M24LR-discovery kit card uses ISO15693 protocol and the MIFARE cards use ISO14443A (they seem to use the T2 library files).
The cards to be used in the final design have not been determined, the original hope was to use the MIFARE cards but am I correct in assuming that MIFARE cards will not work with the CR95HF and X-CUBE-NFC3 library?
I have now changed the original ndef_example_read.c code so that it calls ndefPollerContextInitialization and then uses ndefPollerReadBytes to read from the card. This now works (with the ISO15693 card), so I think the problem was the card not being formatted for NDEF as you said. I have also got a write example working now too. Is it these functions (ndefPollerReadBytes and ndefPollerWriteBytes) that you would recommend using for basic reading/writing of information to a tag?
Thank you so much again for all your help!
Amy