RAM segments merging

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RAM segments merging

Jump to solution
3,446 Views
maksimsalau
Contributor II

Hello,

S32K14x devices have 2 RAM regions named SRAM_U and SRAM_L. They are arranged in continuous manner. E.g.: S32K142 has the following RAM regions: 1FFF_C000 to 1FFF_FFFF and 2000_0000 to 2000_2FFF.

The linker scripts shipped with an SDK has separate memory segments for them:

/* Specify the memory areas */
MEMORY
{
  /* SRAM_L */
  m_data                (RW)  : ORIGIN = 0x1FFFC000, LENGTH = 0x00004000

  /* SRAM_U */
  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00003000
}

m_data is used to store code that should be in RAM, .data and interrupt vectors.

m_data_2 is used to store .customSection, .bss, heap and stack.

Since there is no gap between the sections, it feels natural to me to merge them into a single segment.

E.g.:

/* Specify the memory areas */
MEMORY
{
  /* SRAM_L + SRAM_U */
  m_data                (RW)  : ORIGIN = 0x1FFFC000, LENGTH = 0x00007000
}

This will make easier to manage big arrays, since you will have single RAM segment.

Are there any undesired consequences?

The only undesired consequence I can imagine of is unaligned access on the edge.

E.g.:

*(int32_t *)0x1FFFFFFF = 42;

But such reads/writes should be avoided in any case.

Thanks and regards,

Maksim.

0 Kudos
1 Solution
3,223 Views
BlackNight
NXP Employee
NXP Employee

Yes, misaligned accesses across that memory boundary will cause a hard fault. There has been a discussion on that topic at the end of the following article:

FreeRTOS Heap with Segmented Kinetis K SRAM

I hope that helps,

Erich

View solution in original post

4 Replies
2,893 Views
hemadri_payam
Contributor III

Hi,

I am working on S3k148 controller and faced the similar issue. I required more .bss section so modified the linker file accordingly.

 

Existing RAM split-up:

  /* SRAM_L */

  m_data                (RW)  : ORIGIN = 0x1FFE0000, LENGTH = 0x00020000

  /* SRAM_U */

  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x0001F000

 

Modified:

  /* SRAM_L */

  m_data                (RW)  : ORIGIN = 0x1FFE0000, LENGTH = 0x0003F000-0x2000

  /* SRAM_U */

  m_data_2              (RW)  : ORIGIN = 0x2001D000, LENGTH = 0x00002000

 

I have enclosed the complete linker file for your reference. The memory consumtion in bss in crossing the boundary region and still I did not face any issue of hard fault

Can I know the reason for hard fault not occurring. Looking at the above comments, I am supposed to get "Hard Fault" which has reduced my confidence level.

 

Can you please advice.

 

Hemadri

0 Kudos
3,224 Views
BlackNight
NXP Employee
NXP Employee

Yes, misaligned accesses across that memory boundary will cause a hard fault. There has been a discussion on that topic at the end of the following article:

FreeRTOS Heap with Segmented Kinetis K SRAM

I hope that helps,

Erich

3,222 Views
maksimsalau
Contributor II

Hi Erich,

Thanks! That helped very much.

I had the very same problem: FreeRTOS heap allocation, so I ended up modifying the linker script to allocate all the regular .bss, .data, interrupt vector table, heap and stack in SRAM_U, and reserve the whole SRAM_L region for FreeRTOS heap.

Best regards,

Maksim.

3,222 Views
BlackNight
NXP Employee
NXP Employee

Hi Maksim,

in that case you probably will find that one interesting too:

Using Multiple Memory Regions with the FreeRTOS Heap | MCU on Eclipse 

That way you can have multiple memory regions used by FreeRTOS.

I hope this helps,

Erich