nRF9160: Assigning variables to RAM slots

[paul.lander]

Hi,

In one module of an application I would like to statically declare a large buffer in SRAM:  static uint8_t largeBuffer[65536];

The application fails to link with the following error:

/opt/toolchains/zephyr-sdk-0.11.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/9.2.0/../../../../arm-zephyr-eabi/bin/ld: region `SRAM' overflowed by 62972 bytes

For the nRF9160, is there a reference for how to assign variables to SRAM slots, allowing modules to manage their own encapsulated static data?

Thanks,

Paul

[paul.lander]

Hi Håkon,

In the NRFX LIB documentation it says in the discussion of porting the BSD library that the application in the non-secure partition can use the upper 128 KB of SRAM, plus 2 areas of the lower 128KB (0x2000 0000 - 0x2000 FFFF (64 KB) and 8,160 bytes in the 7th block, above the BSD library). I assumed that SRAM blocks would be assignable by some means, either in a project configuration or declaratively in code.

Could you please give some guidance on interpretation of the SRAM map?

Thanks,

Paul

[Håkon Alseth]

Hi Paul,

 

The SPU peripheral can setup RAM blocks for secure or non-secure in 8 kB chunks, so the region will have to be rounded up to the nearest block:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/spu.html?cp=2_0_0_5_14_2#ram_access_control

 

The partition configuration can be found here:

https://github.com/nrfconnect/sdk-zephyr/blob/master/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160_partition_conf.dts#L40-L58

 

As you mention, you can technically move one 8 kB block of reserved RAM to the non-secure application, per the documentation. Not sure why we haven't done this yet. I'll create an internal ticket on this matter.

 

If you need as much as 64 kB extra RAM, adjusting the above will not satisfy that need, unfortunately.

 

Kind regards,

Håkon

[DeltaXP]

Hi Håkon,

The latest version of the BSD lib (0.7.3) of NCS (1.3.0) seems to support user application specified location and size for bsd library memory:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.0/nrfxlib/bsdlib/doc/api.html#_CPPv417bsd_init_params_t

I am not sure yet how to approach this, but my initial thoughts are to reduce the secure region size of 64kB. What is the reason for such a large memory allocation to the SPM? My understanding is the SPM configures peripherals and memory regions for secure and non-secure then launches the non-secure application. Are there any secure services/functions that are continuing to run or be callable? If so, does bsd lib depend on them?

If the secure region of RAM can be reduced to something minimal or zero, then allocate 256kB to the non-secure user application and set up a static array of 49,184 bytes and pass that to bsd_init function. Then the linker can figure out how to organize the RAM for another 64kB array for this particular application's required buffer.

-Jonathan

[Martin Lesund]

Hi Jonathan,

Please check the Secure Partition Manager documentation, by default, it provides certain Secure Services to the non-secure FW.

The default flash space set aside for SPM needs to match the requirements set by the Partition Manager.

Anyway,  please check out the PR, https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/2080 

This gives the possibility to freely configure SRAM and could be of interest.

That PR extends the partition_manager to also manage the SRAM.

Note, when building a project, you should get a report about the flash and RAM usage of each image. Those should probably give you an indication of the lower limit.

---

Note:
The BSDLib is compiled to use a fixed region in RAM: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/bsdlib/doc/ug_bsdlib_porting_os.html#memory