Example leveraging all the SRAM in NXP LPC5500 devices

[DerekSnell]

Introduction

This example demonstrates and tests application data stored in the different SRAM arrays in the LPC5500 family. This example uses the LPC55S16, but is similar for other MCUs in the LPC5500 family. The example depends on #73533, and modifies the hello_world sample to test the different SRAMs.

LPC55S16 SRAM overview

Refer to the LPC55S1x User Manual for details on the SOC and the SRAMs. The LPC55S16 has a total of 96 KB of SRAM divided into 5 separate arrays. These arrays give flexibility for performance and power consumption. The SOC DTS below shows the sizes and address ranges of the 5 arrays:

	sramx: memory@4000000 {
		reg = <0x4000000 DT_SIZE_K(16)>;
	};

	sram0: memory@20000000 {
		reg = <0x20000000 DT_SIZE_K(32)>;
	};

	sram1: memory@20008000 {
		reg = <0x20008000 DT_SIZE_K(16)>;
	};

	sram2: memory@2000c000 {
		reg = <0x2000c000 DT_SIZE_K(16)>;
	};

	usb_sram: memory@20010000 {
		/* Connected to USB bus*/
		reg = <0x20010000 DT_SIZE_K(16)>;
	};

• SRAMX is intended for code execution to maximize performance, and is therefore located on the Code bus of the Cortex-M33 core at address 0x400_0000. SRAMX can be used for data, however its memory map is not contiguous with the other SRAM arrays.
• SRAMs 0, 1 and 2 are the primary arrays for data, and have contiguous addresses to combine for the linker.
• USB_SRAM is intended for the USB peripheral. This array is contiguous with SRAM2. If an app is not using USB, it can use USB_SRAM for data. But see the Zephyr limitations below.

Applications have flexibility how these SRAM partitions are used. The default setting in the LPCXpresso55S16 board DTS combines SRAMs 0-2 into a single 64 KB segment for the linker. The zephyr,sram chosen node points to this sram0 node, so by default apps have 64 KB of general RAM available.

&sram0 {
	reg = <0x20000000 DT_SIZE_K(64)>;
};

SRAM example application

The attached example is a simple app that leverages the different SRAM arrays, using nearly all of the total 96 KB. A simple test writes to these arrays and confirms the data written.

To test the combined SRAMs 0-2, the main stack size is increased to nearly 64KB. A local variable combined_array[] from the main task is used for testing.

The SRAMX and USB_RAM arrays are not combined with the other SRAMs. The app declares static variables in these arrays using the macro Z_GENERIC_SECTION(). This forces the linker to place the static variables in these arrays.

Enabling SRAM clock in early startup code

Some of these SRAMs have clock gates to reduce power consumption if the array is not used. Most of the clock gates are enabled by default. But in the LPC55S16, the USB_RAM clock is disabled by default. If the USB_RAM is used for app data, this clock gate must be enabled early in the startup code, before the startup code accesses the USB_RAM.

This example enables the USB_RAM clock with the function below in main.c. SystemInitHook() is a hook function used in the MCUXpresso SDK, which is part of the HAL for Zephyr. This hook is called very early in the startup code, before the memories, kernel, or driver are initialized. The example adds this hook to the application. But if using a custom board, SystemInitHook() could be added to the board code for portability.

void SystemInitHook(void)
{
	/* Enables clock to USB RAM early in startup code */
	SYSCON->AHBCLKCTRLSET[2] = SYSCON_AHBCLKCTRL2_USB1_RAM_MASK;
}

USB_RAM limitations with Zephyr

The USB_RAM address range is contiguous with SRAM2, and could be combined with SRAMs 0-2 to increase the app data size to 80 KB. However, since the USB_RAM clock is gated off by default, this can cause some complications for a Zephyr app. Zephyr uses the interrupt stack during startup, so the initial stack pointer points to the interrupt stack. This interrupt stack is used before SystemInitHook() is called, which is before the USB_RAM clock is enabled. Therefore, the existing Zephyr startup code cannot place the interrupt stack in the USB_RAM.

Using Zephyr's linker files, the linker places the interrupt stack in the .noinit section of RAM. And the .noinit section is placed after .bss. Therefore, .noinit is at the upper end of the RAM addresses used by the application. If the app combines USB_RAM with the other SRAMs, and if the app uses enough data, then the linker will place the interrupt stack in the upper USB_RAM array, and this will likely cause issues for the app.

To avoid this issue, this example app keeps USB_RAM as a separate memory segment for the linker, and specifies the variables placed there. If a Zephyr app combines USB_RAM, this likely requires two options. One is for the app to use a custom linker file, which Zephyr does support. Or the app would need to use modified startup code or a secondary bootloader, which would enable the USB_RAM clock before the interrupt stack is accessed.

hello_world_SRAM.zip

[pmjokas]

Hello, i did the changes that you sugest in this example:
So in my overlay i add this:
&sram0 {
reg = <0x20000000 DT_SIZE_K(96)>;
};
I've also added the SystemInitHook function in the main.c

Altough this changes, the same error appears, i've tried other things to but without success

[DerekSnell]

Hi @pmjokas ,
I see you set the sram0 size to 96 KB, which means you are including the USB_RAM array. Please see the limitations of using this RAM above. I suspect this is part of your issue. You likely need to limit the sram0 size to 80 KB. And if you app needs more RAM to fit, then use the linker macros to force some variables in USB_RAM, like the example I shared.

Best regards

[pmjokas]

Well, im new to Zephyr eco-system and i didn´t understood how to use the linker marcos to force variables in USB_ram, i've tried some things but it's not working
its suppose to add this :
//#define SRAMX_WORDS ((uint32_t)DT_REG_SIZE(DT_NODELABEL(sramx))) / 4U
#define USBRAM_WORDS ((uint32_t)DT_REG_SIZE(DT_NODELABEL(usb_sram))) / 4U

//static uint32_t sramx_array[SRAMX_WORDS]
//Z_GENERIC_SECTION(LINKER_DT_NODE_REGION_NAME(DT_NODELABEL(sramx)));
static uint32_t usbram_array[USBRAM_WORDS]
Z_GENERIC_SECTION(LINKER_DT_NODE_REGION_NAME(DT_NODELABEL(usb_sram)));

in my main.c with the respective #includes?

[DerekSnell]

Hi @pmjokas ,
We provided the attached hello_world_SRAM.zip for you to use as a reference. The PR #73533 merged, so this is now supported in the main branch. If you have not already done so, I suggest you update your local Zephyr repo to the latest main branch, copy the attached over the samples\hello_world application, and test that app. Since that shows how to use the USB_RAM, you can then apply it to your app.

Best regards

[vChavezB]

Do you happen to know how I can allocate a Thread Stack to a specific SRAM section ?

By default I think all stacks defined by K_THREAD_STACK_DEFINE are allocated in the default RAM section.

I see in the final linker and map file that these objects are allocated in k_stack_area.

Use case: I have some stacks which I would want to allocate in other SRAM regions as I do not have enough space in the main SRAM.

I am already using zephyr_code_relocate in my CMakeLists but as the stack is defined with the K_THREAD_STACK_DEFINE macro these are treated as kernel data objects through the python/cmake scripts of Zephyr.

[vChavezB]

I looked around on the header files so this is what I came up with, not sure if there is another easier approach in Zephyr?

static Z_KERNEL_STACK_DEFINE_IN(my_stack_in_sram2,
                                4096,
                                __attribute__((section(".sram2_no_init"))));

and in my extra linker script I added

SECTIONS
{
    /* Place the .noinit section at the start of SRAM2 */
    .sram2_no_init (NOLOAD) :
    {
        . = ALIGN(4);
        _snoinit = .;
        *(.noinit)
        . = ALIGN(4);
        _enoinit = .;
    } > SRAM2
}

[DerekSnell]

Hi @vChavezB ,
Please create a new Discussion for your topic. Your topic is general to Zephyr, but the title of this topic is specific to the LPC5500 RAM. If left here, there are many in the Zephyr Community who will ignore it. Feel free to link to your new Discussion here. Thanks

[vChavezB]

Here is the link #74020 👍