Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

RE: Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

runsiv — Wed, 28 Aug 2024 13:16:56 GMT

That seems like a reasonable approch to me. I would not be surprised if we see more optimization on the nrf700x drivers in the future, however this is not something I would take into consideration while developing. I will check where the nrf700x patch is in the memory view and give a update

Regards

Runar

RE: Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

Saxman58 — Tue, 27 Aug 2024 18:24:09 GMT

Thanks Runar,

I had seen the Memory Report when I first tried nRF Connect a few months ago, but had completely forgotten about it. It has been hidden under the Connected Devices panel on my VS Code setup, but no longer. That is very useful!

Thank you also for the west commands to generate the reports. That will also be very useful, for example to diff two different builds and see exactly what changed, or to do a text search. The reports are very detailed, right down to the function level!

Storing the nRF7002 patch on external flash is a good idea. I found the notes on that: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf70/nrf70_fw_patch_update.html, and this DevZone post: Flash nRF7002 ROM patch via external SPI flash
Our external flash will be with a SPI bus. We need to use the QSPI for the nRF7002 for the Wi-Fi throughput we need. That patch note won't work on the nRF7002-DK board because it has the same arrangement we have (QSPI to 7002, SPI to external Flash), so it can't use XIP to access the patch. We'd have to do some extra work to program the flash and load the patch into the RAM heap during boot. But that would work.

But I'm going to try to avoid that by watching the memory usage carefully to keep the size under control.

It is not obvious where the nRF700x patch shows up in the memory map, but I'm guessing that might be the 117,336 byte chunk marked as (hidden).

RE: Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

runsiv — Mon, 26 Aug 2024 15:51:44 GMT

I will expand this post when I get back in to work tomorrow. In general my experience is that the zephyr shell can be nice however you have to be careful to include what you need. The CLI is great while testing and learning but I would not include it in a production application.

However I would just mention that you can use the memory report feature to view ROM, RAM and Partition usage in VScode.

If you prefer a more CLI then you can use the commands

west build -t ram_report
west build -t rom_report

https://docs.zephyrproject.org/latest/develop/optimizations/tools.html

Update: Memory view is the way to go in NCS. I checked if there was anything else that I had forgotten to mention but memory view is the way if you don't want to look at the map file itself.

Its also possible to store the nrf700x patch on external flash if it is needed. We can also try to help you with optimization of the application if needed.

Regards

Runar

RE: Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

Saxman58 — Mon, 26 Aug 2024 15:05:25 GMT

Thanks Runar,

I have run the Wi-Fi Bluetooth coexistence example, but I hadn't see the Wi-Fi stack documentation. That is very useful.

To be honest, I have quite a bit of Wi-Fi functionality in the beginnings of our own app, and the Flash usage is still fairly low at 55%. (RAM is higher for buffers for performance). I'd have to spend some time figuring out what is taking up so much memory on the Dev Academy app, but it looks like the command line interface takes a lot more resources than you'd expect. That was one of the first things I stripped out when creating the base of our own app.

I developed several products with the nRF5 SDK and always had high visibility into where the memory was being used. With Zephyr and the network stack memory usage can jump quite quickly with different features, and it seems harder to figure out which modules used it. Segger Embedded Studio, for example, would list how many bytes were used for code and data, by module. Is there any equivalent to that with the nRF Connect SDK? I found the zephyr.stat file, but that only list the sizes for very high level sections like "text". Can you point me towards some generated file, or maybe a west command that would provide the level of detail that the SES provides like below?

Glen

RE: Wi-Fi Fundamentals Lesson 5, Exercise 3 will not compile with debug options - FLASH overflows

runsiv — Mon, 26 Aug 2024 11:50:04 GMT

The samples on Devacademy might not necessary be optimized for flash and RAM usage. If you are developing your own application I would recommend having a look at the Wi-Fi stack documentation and select the Kconfigs you need depending the application. As you mentioned BLE I would also suggest to have a look at our Wi-Fi: Bluetooth LE coexistence sample.

The only thing I would note is that the documentation in the link recommends CONFIG_HEAP_MEM_POOL_SIZE=230000. I would rather try to set it lower at the start.

Regards

Runar