How to build own middleware code for ST25R3916B/3920B instead of using RFAL

[LeoWu]

Hi ST

Now I am using ST25R3916B evaluation board, it works well with the project code you provided.

My final target is using 3920B on automotive for demostrating NFC card detection as well as digital car access to customer.

But we will finally change to other platform's MCU, not use ST's hsot MCU.

Due to our MCU has limited Fash / RAM size, we are considering to build our own middleware code to drive NFC frond end. but it looks like it's hard to understand the protocol through I2C waveform, and no any protocol document is avaiable on your website.

Is migating RFAL the only way I can do for realizing NFC function with 3916B / 3920B? 

Thanks

Leo

[Brian TIDAL]

Hi Leo,

The use of RFAL is recommended. This library is designed for portability and scalability, and it can run on non-ST microcontrollers.

All porting-related content is located in rfal_platform.h. For information about interfaces to user-specific platform hardware drivers, see RFAL User Manual UM2890.

Regarding memory footprint, flash memory size can be reduced by disabling features that are not used in the application. For example, set RFAL_FEATURE_ST25TB to false in rfal_platform.h.

rfal.chm file in the documentation folder provides the typical size of each module.

Feel free to share the list of technologies and protocols being used in your application (likely NFCA and NFCF technologies and ISODEP protocol). This information allows us to help you refine the configuration of the RFAL_FEATURE_xxx.

Rgds

BT

[LeoWu]

Hi Brian

Thanks for your reply

are both 3916B and 3920B using same RFAL library?

based on the code size estmation from your RFAL guide, Flash will need at least 32k+16.6k, RAM will need 6kB

does it means 64k flash + 8 k ram MCU is enouigh for handling RFAL library?

if customer want to development CCC application, do you have a total solution?

Thanks,

Leo

[Brian TIDAL]

Hi Leo,

ST25R3916, ST25R3916B, ST25R3917, ST25R3917B, ST25R3918, ST25R3920, and ST25R3920B use the same RFAL library (see Introduction section in UM2890).

Regarding the memory footprint, ensure that you consider the microcontroller hardware abstraction layer (HAL) libraries, such as the SPI or I²C drivers, and the flash memory and RAM size of the application on top of the RFAL. 8 KB RAM might be too small.

For CCC applications, I would suggest using the ST25R500 automotive device. It also uses the RFAL library that provides the same API for the application. 

Regarding the total solution, do you mean a turnkey solution or a reference design?

Rgds

BT

[Andrew Neil]

---

@LeoWu wrote:

it looks like it's hard to understand the protocol through I2C waveform, and no any protocol document is avaiable on your website.

---

There's a list of commands in the datasheet:

https://www.st.com/resource/en/datasheet/st25r3916b.pdf#page=60

via: https://www.st.com/en/nfc/st25r3916b.html#documentation

[Brian TIDAL]

Hi Andrew,

The RFAL library provides an abstraction layer that eliminates the need to manage register-level commands described in the datasheet. Therefore, the use of the RFAL library is recommended: the same API can be reused on different products of the ST25R family without having to change the application code.

Rgds

BT

[Andrew Neil]

Indeed.

But if @LeoWu wants to write something from scratch, the datasheet would always be the place to start...

[Brian TIDAL]

Hi Andrew,

I doubt that rewriting the code from scratch significantly reduces the code size. Moreover, the RFAL communication stack is tested against ISO test suites and NFC test suites, and provides interoperability with those standards. Using the RFAL significantly reduces the development costs for the customer. However, everyone is free to redevelop the code from scratch.

Rgds

BT