How much of the nRF5340 Shared RAM segment (0x2007000 - 0x207FFFF) does the Nordic BLE Soft Controller require?

[Kevin Doss]

We are using the nRF5340 in a multi-protocol application where we use the BLE Soft Controller in one mode and a proprietary protocol in another mode. Both protocols use the Shared RAM in region 0x20070000 - 0x2007FFFF for message and data exchange between their Hosts on the Application CPU and Controllers on the Network CPU.

We currently have 56 kBytes allocated to the Soft Controller (0x20070000 - 0x2007DFFF) and 8 kBytes allocated to our proprietary protocol (0x2007E000-0x2007FFFF). We have run out of space in this allocation for the proprietary protocol and would like to increase it by maybe 4 kBytes.

The question is what is the minimum Shared RAM allocation that the BLE soft controller needs? Our most intensive usage of the BLE soft controller configures it as a peripheral and GATT server. The Kconfig overlay for this configuration is attached.

Thank you,

Kevin

overlay-ble.conf

[Edvin]

Hello,

Where did you set the allocated SoftDevice controller size, and the proprietary protocol size? I will run this by our SoftDevice team, but I would like to just understand a bit more in detail what you already did before reaching out.

Best regards,

Edvin

[Kevin Doss]

From our devicetree:

/ {

   reserved-memory {

      /delete-node/ memory@20070000;

      sram_ipc0: memory@20070000 { /* BT HCI rmsgs */

         reg = <0x20070000 0xE000>;

      };

      sram_ipc1: memory@2007E000 {

         reg = <0x2007E000 0x1000>;

      };

        sram_shula: memory@2007F000 {

            compatible = "zephyr,memory-region", "mmio-sram";

            zephyr,memory-region = "SRAMSHULA";

            reg = <0x2007F000 0x1000>;

        };

   };

   ipc {

      /delete-node/ ipc0;

      ipc0: ipc0 {

         compatible = "zephyr,ipc-openamp-static-vrings";

         memory-region = <&sram_ipc0>;

         mboxes = <&mbox 0>, <&mbox 1>;

         mbox-names = "tx", "rx";

         role = "host";

         status = "okay";

      };

      ipc1: ipc1 {

         compatible = "zephyr,ipc-openamp-static-vrings";

         memory-region = <&sram_ipc1>;

         mboxes = <&mbox 2>, <&mbox 3>;

         mbox-names = "tx", "rx";

         role = "host";

         zephyr,priority = <1 PRIO_COOP>;

         status = "okay";

      };

   };

};

[Edvin]

Thank you for the details. I have not yet found anyone who can say what a recommended minimum should be, but someone pointed out that the distance measurement sample in NCS is using even less sram for the softdevice controller:

It is using 20070000 -> 20077FFF for the SoftDevice Controller, and 0x20078000->2007FFFF for the proprietary distance measurement library. 

Please see the nrf5340dk_nrf5340_cpuapp.overlay and nrf5340dk_nrf5340_cpunet.overlay files for the nrf_dm sample.

Best regards,

Edvin

[variant]

I'm not very familiar with the distance measurement sample, but it seems that the GATT traffic from the server to the client uses infrequent and small-sized PDUs.  Our case is the opposite.  Isn't there a relationship to the MTU size, data length size, ACL tx/rx size, and buffer counts to the amount of SRAM used by the SoftDevice Controller?

[Edvin]

I would assume it is, but I am not sure how quickly the cores will pick up the data from the SRAM. A BLE packet still ranges from somewhere between 20 bytes to 250 bytes, so still nowhere near the 50kBytes that are reserved by default. That being said, I am not sure how long the data needs to live in the SRAM, and hence, how much SRAM that is required.

But if you have no other option than increasing the part for the proprietary part, then you need to decrease the softdevice SRAM. I would think it is fine, as you do not reduce it that much (in %). 

Best regards,

Edvin

[Kevin Doss]

We can live with 14 kBytes of Shared SRAM in our current project. Longer term, though, we may have applications that require more than 14k. It would be helpful to have a more definitive answer to this question if/when that case arises. I find it a little hard to believe that the BLE soft controller can't live with less than 50 kBytes. If that's true trying to implement a data-intensive MPSL solution could be quite restrictive.

[Einar Thorsrud]

It is difficult to say what the minimum sizes of the shared SRAM is, as the amount that is needed will depend on the application (maximum packet sizes being used etc.). So reducing the size should be combined with proper testing to ensure you don't end up in a situation where it causes problems.

[Kevin Doss]

We understand that the answer to the question will vary depending on how hard the BLE stack is being driven (which is why we attached the configuration file above). Even if we knew the worst case (maximum packet size, minimum connection interval, moving as much data as possible in a 2Mbps connection) that would be helpful. It seems wrong to expect the customer to have to profile your application to figure out where it breaks.

[Einar Thorsrud]

I see your point. We have raised this issue internally, but I am not able to provide any numbers or way to estimate this at the moment though, unfortunately.

[Kevin Doss]

Just curious if there is anything new on this question.

Thanks,

Kevin

[Einar Thorsrud]

Hi Kevin,

Unforunately not. If you change this you will have to verify that the sizse of the shared RAM buffer is large enough for your sepcific use case, but we are not able to provide any speific guidelines or numbers for this.