How to allocate shared SRAM on the nrf5340

[Kevin Doss]

I would like to use a portion of the shared SRAM (address range 0x20070000-0x2007FFFF) to transfer some raw data between the network and application cores. My system is also using the rpmsg service to transfer messages between cores (less time critical than the raw data that I wish to exchange). Is there some way to either allocate memory from this region or discover what address range(s) the rpmsg service is using so I don't have memory conflicts with the rpmsg service?

[Simon]

Take a look at this DevZone case and the resources provided: Communication between AppCore and NetCore.

If that didn't help answering your questions, please let me know and I will take a deeper look at it.

Best regards,

Simon

[Kevin Doss]

This case provides resources for understanding how to use the various messaging services that abstract the IPC interface. I'm already using the rpmsg service for message passing between cores. This works great for exchanging messages that aren't extremely time critical. My application has data that is very time critical and I'm looking for ways to reduce the latency of passing this data across IPC to the bare minimum. What I'd like to do is simply allocate a small data structure in the Shared SRAM space and an IPC channel. On the receiving end I will enable a receive interrupt on the IPC channel and process the data directly in the interrupt handler.

The gist of my question is how can I allocate a small amount of memory (<100 bytes) in Shared SRAM and be sure that the memory is not being used by the rpmsg service?

[Simon]

Is there some way to either allocate memory from this region or discover what address range(s) the rpmsg service is using so I don't have memory conflicts with the rpmsg service?

Sorry for the late response. During July, a huge part of the support team are taking vacation and you can expect a slower repsonse.

I think you should be able to allocate memory using a pm_static.yml file. I built the peripheral_uart sample with the nRF5340 DK, then ran ninja partition_manager_report from the build folder and got the following response:

  flash_primary (0x100000 - 1024kB): 
+------------------------------------------+
| 0x0: app (0xfe000 - 1016kB)              |
| 0xfe000: settings_storage (0x2000 - 8kB) |
+------------------------------------------+

  otp (0x2fc - 764B): 
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  sram_primary (0x80000 - 512kB): 
+-----------------------------------------------+
| 0x20000000: sram_primary (0x70000 - 448kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB): 
+----------------------------------------+
+---0x1000000: app (0x40000 - 256kB)-----+
+----------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+------------------------------+

  sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: sram_primary (0x70000 - 448kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB):
+----------------------------------------+
+---0x1000000: app (0x40000 - 256kB)-----+
| 0x1000000: hci_rpmsg (0x40000 - 256kB) |
+----------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

As you can see, the rpmsg occupies 0x10000 bytes at address 0x20070000

Best regards,

Simon

[Kevin Doss]

For others who may be interested in doing something similar....

I was able to allocate a segment of shared SRAM in the 0x20070000 - 0x2007FFFF region that was separate from rpmsg service by modifying the existing devicetree:

   reserved-memory {

      #address-cells = < 0x1 >;

      #size-cells = < 0x1 >;

      ranges;

      sram0_shared: memory@20070000 {

         reg = < 0x20070000 0x10000 >;

      };

   };

with this overlay:

  reserved-memory {
    /delete-node/ memory@20070000;
    sram0_shared: memory@20070000 {
      reg = <0x20070000 0xF000>;
    };
    sram_my_data: memory@2007F000 {
      reg = <0x2007F000 0x1000>;
    };
  };

  aliases {

    srammydata = &sram_my_data;

  };

I can then initialize a pointer to a data structure at that location like this:

my_data_t  *pMyData;

pMyData = (my_data_t*)DT_REG_ADDR(DT_ALIAS(srammydata));

Hope this is helpful,

Kevin

[Simon]

Thanks for sharing the solution Kevin!