Monitoring usage of shared RPMsg SRAM

[LltWc]

nRF Connect SDK Toolchain v2.4.2, Windows 10

Hi,

We're running low on RAM on the nRF5340 application core, and I'm looking into ways to recover RAM both from our application and from the Zephyr configuration.

My team suspects that the rpmsg_nrf53_sram partition is not fully used within our BLE application; however, I currently have no way to check or verify this apart from stress-testing the application. I spent some time diving into the RPMsg implementation code and came to the understanding that the implementation of writing to the shared memory is so far abstracted that it isn't feasible to monitor the actual memory addresses written to in order to determine how much of the shared SRAM is being used. I've been spot-checking the memory addresses in Ozone, but that's not a scalable solution.

Is there a way to programmatically check how much of the rpmsg_nrf53_sram is used during the application, ideally in a similar manner to Thread Analyzer?

edit: I'm fairly confident I have the shared SRAM start/size changed everywhere in our code that matters, but now I see IPC failures. My first assumption is that there's something (hardcoded?) expecting 0x20070000 to be the start of the shared SRAM, so it fails to set up IPC. Is there a Kconfig or similar I'm missing to ensure both cores + the SDK code know where to go? I do have the Kconfig for shared SRAM size set.

[Einar Thorsrud]

Hi,

You are right, the dts definitions are ignored when using the partition manager. I am checking internally on this, but ut may take some time as we have not directly supported changing the shared RAM size.

[LltWc]

For anyone who finds this in a search result; here's my nearly final results:

The error shared in the original post was actually from a failure in our build/flash pipeline; only the app core was being flashed, resulting in mismatches and rapid BLE stack failure.

I believe the only place that must be edited to change shared RAM usage is pm_static.conf (rpmsg_nrf53_sram and sram_primary). I also edited reserved-memory -> sram0_shared in the .dts and set CONFIG_RPMSG_NRF53_SRAM_SIZE in the prj.conf. I don't know if those were strictly required but I wanted them in the code anyway for the sake of self-documentation.

I stress tested our BLE usage to check if 32 kB rather than 64 kB would be sufficient; at the very highest rates of data transmission, there may have been a very slight decrease in data throughput, but so small as to not be meaningful compared to the benefit of 32 kB extra RAM.

I'm currently running a longer test for a use case that should max out how much data can be sent between two devices only. I haven't analyzed the data yet but no failures were indicated so I'm not worried about it.

Hopefully this can help someone else dealing with this especially annoying lack of documentation.