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]

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.