Reduce nRF7002dk image size

[esisk]

Hello, I'm in the development stage of a product and currently evaluating the nRF5340 as our main processor and nRF7002 as a companion IC for WiFi. Our application can be used in a wide variety of connectivity environments, so we require a WiFi interface, Ethernet interface, a cellular/GPS modem, and BLE. Also, we want to make MQTTS/HTTPS connections to our cloud provider. I've gotten a lot of these individual components to work individually by building our app to run on a nRF7002dk; however, I'm running into issues with the size of the image being too big when I try to include all of the necessary config variables in my build. Is what I'm attempting to do infeasible? My current build is overflowing RAM by 71,272 bytes and Flash is overflowed by 10,160 bytes. I can share my board overlays and configuration files. To be clear, I'm using NCS version 2.8.0, and building an application with nrf/7002dk/nrf5340/cpuapp/ns board as the target.

4336.prj.conf sysbuild.conf 3731.nrf7002dk_nrf5340_cpuapp_ns.conf nrf7002dk_nrf5340_cpuapp_ns.overlay

[BrianW]

From my current experience, this is a hard thing to get to work. As you say, all the individual samples will work, but trying to combine the functionalities into a real application is another kettle of fish... My device has networking (wifi/wpa/IPv4/httpS/mqtt to the cloud with JSON parsing), BLE GATT server, BLE ibeacon scanning and emission, serial comm, NFC emulation, audio (I2S and PDM), USB (VCOM and FAT file system), GPIO & I2C for sensors and battery management, ePaper display with touch....  The benefit of the Nordic/zephyr environment is that a lot of useful library/subsystem/driver code is provided, the disadvantage is the complexity to get everything to co-exist (Zephyr is particularly hard I find...)

An external flash chip to allow DTU (OTA or via USB) is a must (for the secondary image slot), also to store the 128kb required for the wifi nrf70 patches (in theory, haven't got this to work yet). Then, your bootloader (mcuboot) takes up 64kb in real life (because you need the serial DTU/USB option just in case an OTA error bricks it....), leaving you with around 970kB for the app... this seems large, but the whole wifi+WPA supp+TCP+TLS crypto block will use an large percentage of that! 

For the RAM, I have managed to get an operational config, but only by time consuming tuning of the heap sizes, prj.conf parameters etc... and the interdependancies between these are very much NOT clearly documented in either Zephyr or the Nordic docs.  I don't think its possible to add RAM to the nrf5340 as far as I know, which makes the 440kB you actually have to play with be a major difficulty.

I can't tell you that definitively it is possible, as right now I cannot get the mbedtls part to actually fit in the space and also work for https connections!

[Elfving]

Hello Brian,

I am sorry to hear that. I find that getting things to co-exist is also something that Zephyr does well, the issue is when the components are as memory hungry as the Wi-Fi ones are. Or that for instance Matter and LE Audio is. 

Is upgrading to 54 an option for you? The amount of features you need might warrant that. 

Regards,

Elfving

[BrianW]

Elfving said:

getting things to co-exist is also something that Zephyr does well

Hmmm.... I find that it is very hard to find reliable documentation on exactly what the co-existance issue might be in Zephyr, and the KConfig system is (IMHO) very poorly documented - its just generated from the header files which often a limit the 'explanation' to 'CONFIG_X_Y_W : this configures the value of Z for Y in library X'. Not useful to understand why you want to do  this, and it impacts!

Elfving said:

the issue is when the components are as memory hungry as the Wi-Fi ones are.

Clearly this is a case in point : it was NOT in any way clear to me that in order to get the wifi/networking to work in a real application would require so much of the nrf5340's flash and RAM resources! (or that certain parts of the functionality like WPA-SUPP were still very unstable and not ready for a real product!)

My experience with Nordic previously was very positive (nrf51/52 BLE products), but since trying to get this product off the ground using Zephyr and the nrf7002, I feel a lot less likely to recommend this product line.

Elfving said:

Is upgrading to 54 an option for you?

I assume you mean the nrf54 series? This was not yet in full availability when we started the hardware component selection process 8 months ago... I might well have looked into it if I had known about the memory requirements the wifi/netowkring would bring.

My product is currently in pre-production and due to ship to clients in feburary....  restarting the hardware design is not an option.

[Elfving]

I am sorry to hear that, both about you finding the docs unreliable, having a bad impression of the other nRF series, and the situation you are in.

Regarding navigating the documentation I agree that this can be difficult. Though you can here see some overview over the different memory requirements of some of the features (eg. here and here too). SoftAP is unfortunately particularly high. I often find that the AI on the bottom right often does a better job than I regarding finding these pages, and is definitely worth using if you haven't already. 

BrianW said:

'CONFIG_X_Y_W : this configures the value of Z for Y in library X'. Not useful to understand why you want to do  this, and it impacts!

Zephyr can be confusing and over-complex at times. Hopefully the documentation, the AI and the DevAcademy help a bit with this. There is allways the option of still using nRF 5 SDK, though we do recommend using NCS instead. And nRF5SDK doesn't work with the more complex solutions like nRF7 etc.

Regards,

Elfving

[BrianW]

Elfving said:

different memory requirements of some of the features

Thanks for these links. in fact its this one that is most relevant to my product case:

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/wifi/station_mode/mem_requirements_sta.html

And it dfoes indeed show that for a wifi application in STA mode with WPA2 using MQTT, the most basic ROM size is 702kB (out of the 960kB available when using mcuboot)! (not to mention the 320kB of RAM from the 440kB available!)

Now, this is the sample which makes no effort to limit the memory usage, and by disabling bits I don't need I can trim it - but this is where the difficulty with the doc comes in. An example:

CONFIG_MBEDTLS_ECP_C=n

should avoid using the EC crypto code which I don't need : but somehow the base nrf-security config always overwrites this to y and enables all that stuff! Any ideas on how to disable this?

I also note it needs 73kB for the wifi patches (in fact 128kb if you want to do DFU on them), and these can be placed in an external XIP flash. Do you have a known good config (prj.conf and partition setup/init) example for this?

[Elfving]

BrianW said:

should avoid using the EC crypto code which I don't need : but somehow the base nrf-security config always overwrites this to y and enables all that stuff! Any ideas on how to disable this?

Hmm, this seems to be selected by a few other configs that it is worth checking if you have enabled. It might be that this config is needed, and it might rather pay of disable some other features that are selected by it.  Do you get any sort of error message or anything regarding it not being disabled?

BrianW said:

I also note it needs 73kB for the wifi patches (in fact 128kb if you want to do DFU on them), and these can be placed in an external XIP flash. Do you have a known good config (prj.conf and partition setup/init) example for this?

This page goes a bit into that. 

Regards,

Elfving