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,

We do not have any specific way to monitor the shared SRAM usage, so that would have to be handled experimentally (perhasp writing a pattern to the region and stress test the device to see how much is used).

Regardign the failure, how did you adjust the size? Using CONFIG_RPMSG_NRF53_SRAM_SIZE?

[LltWc]

That's the approach I've been taking too - I wrote a pattern to the whole region and have been monitoring it with Ozone. 

I adjusted the size in three places:

• The .dts defines reserved-memory -> sram0_shared. The tooltip says that it's ignored, but this was necessary for the final .map file to reflect my intention.
  • 
• pm_static.yml
  • 
• And third, yes, CONFIG_RPMSG_NRF53_SRAM_SIZE
  • 

[LltWc]

I also went through the BLE RPMsg setup, and on its face, all of the right variables are set; it knows its shared memory starts at 0x20078000.

[Einar Thorsrud]

Hi,

I see. I am checking internally, but we have only used and supported the default 64 kB share RAM buffer, though other sizes should be possible (see this and this old thread for reference). Could it be that you need to adjust the dts for the net core app (hci_rpmsg) also, similar to what is done here?

[LltWc]

I had found those threads before, thanks, and they didn't quite describe what I want to do, which is change both the size and the starting address.

I thought I had found the solution by modifying both the pm_static.yml and the child image's pm.yml to both have the same rpmsg_nrf53_sram definition, dropping it to 32 kB and moving the start from 0x20070000 to 0x20078000. But there must have been a fluke or something I missed; I observed that it was working as expected using Ozone with the region filled with a pattern, but then when I moved back to a 64 kB region, I got the same BLE/netcore errors. Strangely, I saw the same thing when I flashed the previously working image to a new device.

Now I'm doing a soft reset, and working on reducing the size of the rpmsg_nrf53_sram but keeping it at the same address. This worked dropping it to 63 kB, but then at 32 kB I saw the same BLE/netcore errors.

Regarding the hci_rpmsg .dts, as we don't currently have a child_image .dts:

1) Does that change actually affect the memory map? Every time I touch a .dts, it warns me that the partition manager is the only thing that matters, and the .dts is ignored.

2) Is the ipc0 node what the netcore is using as its basis for BLE-related RPMsg? If so, that would make sense for the errors I saw, which seemed to reflect that not every place in the netcore got the new configurations I was trying to do. It looks like I could just remove the ipc1 parts.

3) If I drop in a modified version of that .dts, will the current netcore Devicetree configurations that aren't modified stay the same? Scratch that, just realized its an overlay so by definition it shouldn't.

Thanks for your help.

[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.