nRF9160: Assigning variables to RAM slots

RE: nRF9160: Assigning variables to RAM slots

Martin Lesund — Wed, 01 Jul 2020 11:37:28 GMT

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

RE: nRF9160: Assigning variables to RAM slots

DeltaXP — Fri, 26 Jun 2020 15:10:03 GMT

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

RE: nRF9160: Assigning variables to RAM slots

Håkon Alseth — Wed, 17 Jun 2020 10:36:16 GMT

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

RE: nRF9160: Assigning variables to RAM slots

paul.lander — Tue, 16 Jun 2020 14:50:12 GMT

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

RE: nRF9160: Assigning variables to RAM slots

Håkon Alseth — Tue, 16 Jun 2020 13:46:22 GMT

Hi,

[quote user=""]For the nRF9160, is there a reference for how to assign variables to SRAM slots, allowing modules to manage their own encapsulated static data?[/quote]

The non-secure region has 128 kB flash available to the application. Based on the output from the linker, you are overflowing the region with ~62kB:

[quote user=""]/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[/quote]

Placing it in another region will not help here, as you're using up all the RAM.

Kind regards,

Håkon