How to minimize flash usage

[LHabe.1]

Hello all, my company has decided to use the STM32L03 series for a simple ISO ​14443-3 tag reader, and we underestimated how much memory the full rfal takes up. Can anyone help me find an easier way to cut down the provided polling demo into 16k flash or less? I can scrap all other tag types except the T2T /nfc-a, and I only need read functionality. I am slowly working through and trimming the fat, but if there's a smarter way to limit program memory I'd be very thankful.

[Brian TIDAL]

Hi Luke,

Can you share more information about your setup:

• Do you use the ST25R3916 or the ST25R3911B reader?
• What is your compiler?
• which STM32L0 do you use?

The RFAL code is scalable through the platform.h file. To remove useless features in your application, you just need to change the "RFAL FEATURES CONFIGURATION" in the platform.h. For example, if your application only needs to support NFC-A/T2T tags, the following features configuration can be used.

/*
*****************************************************
* RFAL FEATURES CONFIGURATION
*****************************************************
*/
 
#define RFAL_FEATURE_LISTEN_MODE false 
#define RFAL_FEATURE_WAKEUP_MODE false 
#define RFAL_FEATURE_LOWPOWER_MODE false 
#define RFAL_FEATURE_NFCA true 
#define RFAL_FEATURE_NFCB false 
#define RFAL_FEATURE_NFCF false 
#define RFAL_FEATURE_NFCV false 
#define RFAL_FEATURE_T1T false 
#define RFAL_FEATURE_T2T true 
#define RFAL_FEATURE_T4T false 
#define RFAL_FEATURE_ST25TB false 
#define RFAL_FEATURE_ST25xV false 
#define RFAL_FEATURE_DYNAMIC_ANALOG_CONFIG false 
#define RFAL_FEATURE_DPO false 
#define RFAL_FEATURE_ISO_DEP false 
#define RFAL_FEATURE_ISO_DEP_POLL false 
#define RFAL_FEATURE_ISO_DEP_LISTEN false 
#define RFAL_FEATURE_NFC_DEP false

Then, you can remove the USE_LOGGER define (printf on the serial console) and remove the UART.

Also, make sure to use the proper level of optimization in the compiler options (Optimize for size). See https://www.keil.com/appnotes/files/apnt202.pdf if using Keil µVision.

demo_polling.c file can also be modified to get rid of demoP2P, demoAPDU, demoNfcv, demoNfcf and demoCE and reduce the size of demo_polling.o.

You should then be close to the 16k flask size limit.

Once those suggestions are applied, feel free to share the map file of your application if you are still exceeding the 16k.

Rgds

BT

[LHabe.1]

Thank you for the reply. We are using the ST25R3911B driven by the STM32L031G6U7 (32k), and compiling through the standard CubeIDE gcc compiler. I have tried ripping out all the non required architecture out manually, and was able to get down to 16k, but wasn't getting tag interrupts (after the initialization ones) so I probably removed something important.

​

I'll try a new build and only setup the platform as you suggest, and yes I still need to modify polling heavily.

​

I​ll send my mapping once I get that set up. Thanks

[Brian TIDAL]

Hi Luke,

regarding the interrupt issue:

• make sure the ST25R311B IRQ pin is properly connected to a STM32L031 GPIO
• make sure this GPIO is configured as GPIO_EXTIx External Interrupt mode with rising edge trigger detection, no pull up no pull down
• make sure the EXTI Line x interrupt is enabled
• make sure that st25r3911Isr(); is called in EXTIx_y_IRQHandler in stm32l0xx_it.c

See stm32l0xx_it.c in STM32CubeExpansion_NFC5_V2.0.0\Projects\STM32L053R8-Nucleo\Applications\PollingTagDetect\Src from X-CUBE-NFC5 package for an example of interrupt configuration on STM32L053.

Rgds

BT

[LHabe.1]

IRQ is set up correctly, i was getting the original interrupts that get sent out during initialization, just not when in discovery mode (can't sense tags). Could be a hardware problem but i doubt it. I can activate the IRQ by applying a voltage directly.

[Brian TIDAL]

Hi,

ST25R3911B sends interrupts during initialization. For example when oscillator frequency is stable, I_osc is raised (see st25r3911OscOn()).

Can you share more details about your HW setup: do you use a custom board or a X-NUCLEO-NFC05A1 plugged onto a NUCLEO-L031K6?

Rgds

BT

[LHabe.1]

It's a custom board, but the schematic and layout of the RFID portion are almost identical to the X-NUCLEO-NFC05A1 expander (just without the capacitive sensor). It's worth noting that the initialization and rf calibration all pass, and i'm able to communicate with the R3911 fine. The current draw does seem low though if it is truly searching for passive tags. I would assume 100mA or so and it is in discovery mode at 16mA. I did order dev kits of the hardware to verify it's FW and not HW, but they will take a while.

[LHabe.1]

Thank you for your continued support Brian. I had my compiler on Optimize Most (-O3) instead of for size (-Os). With that I was able to drop down to 27.7kB which is enough for testing the RFID at least. I'm sure I can scrounge around for the other 5k i'll need to add my other code back in.

Thanks!