Flash usage of examples (bare metal vs FreeRTOS based)

[TylerD]

I'm working with nRF52832 and playing around with some peripheral examples from SDK 16.0.

The FreeRTOS based heart rate sensor example (ble_app_hrs_freertos) seems to work nice out of the box and I've done some small modifications to it, no problem so far.  However, the flash footprint of the sample app looks a bit odd to me.

The size of my FreeRTOS based app (excluding the softdevice, just the app itself) is around 110kB. I've added only some very basic functionality to the HRS example, very minimal stuff.

Does this sound reasonable? For comparison, I built the ble_app_blinky sample app that does not use any RTOS. Size of that app is only 22kB which sounds small enough to me.

I'm using the s132 soft device, if that makes any difference.

I would expect the FreeRTOS flash footprint to be only few tens of kilobytes. Any ideas where to look? I can of course start digging into the *.map output file to see exactly what the binary is built of, but any pointers are appreciated at this point.

[TylerD]

Any comments? It's been a week and I doubt that I'm the only one experimenting with the FreeRTOS based example for nRF52. Is it normal for the simple HRS app to be > 100kB in size??

I'm relatively new to Nordic parts so don't know exactly what to expect...

[Susheel Nuguru]

sorry for the late reply. Seems like you are including NRF_LOG_ENABLED in your sdk_config.h file. That would increase a log of foot print. This also makes the BACKEDEND (seems uart in your case) included which includes uart libraries and drivers

[Susheel Nuguru]

I would highly recommend you to understand the sdk_config.h file. This knowledge is quite useful for you in the future, so it will be a good investment in time. After that disable all those things that are not needed in your project. When you start to think about the best performance/lowest power/smallest foot print, then you need to have control on these variables and select them accordingly. 

TylerD said:

1) What settings should I be looking at to optimize the flash consumed by FreeRTOS

 The flash size directly is impacted by what features are included in your project. By default we add all the drivers and libraries into your project and hope/expect that you select their inclusion wisely by enabling or disabling them in sdk_config.h file. 

Please start to disable the things in sdk_config that you think are definitely not needed in your production version. I am sure you will get  better results. It is quite hard from our perspective to suggest what to disable and what to keep enabled. Since these are given as template example for making this functionality work and leaving the footprint engineering to the experts like you by selecting them from sdk_config.h

[TylerD]

OK, I understand I need to dig through the sdk_config.h and remove unnecessary stuff. The challenge is that the config file is HUGE and I was looking for some pointers where to start.

The FreeRTOS footprint is a totally separate issue. It has nothing to do with sdk_config.h. Quoted from FreeRTOS FAQ: https://www.freertos.org/FAQMem.html#ROMUse ->

"The RTOS kernel itself required about 5 to 10 KBytes of ROM space"

Assuming the RTOS takes ~10kB, the HRS sample app with logging disabled would then be around 60kB. Therefore I guess I need to concentrate on trying to optimize the BLE app and remove unused features one by one.

[Susheel Nuguru]

TylerD said:

The FreeRTOS footprint is a totally separate issue. It has nothing to do with sdk_config.h. Quoted from FreeRTOS

The FreeRTOS port that you get in our SDK is a bit different than a normal FreeRTOS port you use on the baremetal. 

The FreeRTOS port we give, is different in a way that it is designed to work as an application and not as an privilaged kernel. This is because the FreeRTOS port need to work along side the softdevice and in our BLE stack, softdevice resources and execution has the highest priority over others.

In terms of footprint, all the FreeRTOS files are compiled into the application. So when you see the footprint big, it is not necessarily being contributed by just freertos files but due to other inclusion of libraries and drivers that are enabled from sdk_config.h but not used  Enablign peripherals will cause them to be linked into the hex file

[TylerD]

Is there any more information somewhere (infocenter? appnotes?) on how the FreeRTOS and softdevice are married to work with each other? I would like to learn in more detail how it works.

[Susheel Nuguru]

Unfortunately, the documentation is very thin in this context.

But all the changes are focussed in 5.3.0_59ac345\external\freertos\portable\CMSIS\nrf52 files.

The changes in priorities, use of PSP instead of MSP. rtc tick handler to update FreeRTOS ticks for the time softdevice kept CPU to itself are some of the changes you can see in these files.