RAM Memory Utilization

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

RAM Memory Utilization

Jump to solution
4,012 Views
utsavikalpesh
Contributor V

Hi,

I am working with TWR-K60D100M.

Stack Size I have used for Tasks is 21KB (Calculated from TASK_TEMPLATE_STRUCT, also seen from MQX Stack Usage).

Main Application BSS RAM is 34KB (seen from .MAP file).  So total RAM used is 55KB approx.

I declared some more variables then build the project and Study  .MAP file, that indicates Main Application BSS RAM is 62KB...And if I load that project it is stuck !!

From TWR-K60D100M User Manual I come to know that RAM Size is 128KB. Then why this is happening?

Is K60 RAM is divided under SRAM_L and SRAM_U of 64KB ? If yes then how can I access both RAM segments ? What changes I have to made in Linker File....?

Why I am not able to utilize 128KB of RAM?

Regards,

Utsavi Bharuchwala

Tags (1)
0 Kudos
1 Solution
2,233 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

Let me explain what I think is causing the problem and then you can do next test.

If you remember, SRAM is divided into 2 x 64-kB lenght blocks and they are accessed from different buses so we have to be sure that any object (variable, structure) is not stored by overlapping both sections, for example, next imagen shows a scenario where a 32-bit variable is stored between these blocks:

Allocation problem.jpg

In this case, there would be an access problem and program would crash. Remember that this could be avoided in compilation-time although it is difficult to prevent this on run-time

Now, by analyzing your map file, this is how your memory is used:

Current memory occupation.jpg

You application data (like .bss objects) does use 51 520 bytes, after this, there is a segment called __KERNEL_DATA_START that signals where KERNEL will start to use data for stack or heap from different tasks. What i think could be causing the crashing is the fact that kernel could allocate any objetc in the limit of both SRAM sections, so we can make a quick test to validate if this is the problem or you are really using all the RAM in your project.

I'd recommend you to move the __KERNEL_DATA_START address to 0x2000_0000 although the left ~13kB of SRAM_L would get unnused, but this way we can be sure that kernel will not allocate memory in the middle of both sections:

Move Kernel start.jpg

For doing this, you will need to modify your linker file (located at: <MQX_4_0_PATH>\lib\twrk60d100m.cw10\debug\bsp) and add next line in memory segment:

MEMORY

{

   vectorrom   (RX): ORIGIN = 0x00000000, LENGTH = 0x00000400

   cfmprotrom  (R): ORIGIN = 0x00000400, LENGTH = 0x00000020

   rom         (RX): ORIGIN = 0x00000420, LENGTH = 0x0007FBE0  # Code + Const data

   ram         (RW): ORIGIN = 0x1FFF0000, LENGTH = 0x00020000  # SRAM - RW data

   start_of_ram_u (RW): ORIGIN = 0x2000000, LENGTH = 0x00000000

   # kernel space starts after RAM variables (Location of MQX Kernel data + MQX heap)

   end_of_kd   (RW): ORIGIN = 0x2000FFF0, LENGTH = 0x00000000

   # Boot stack reused by MQX Kernel data

   bstack      (RW): ORIGIN = 0x2000FA00, LENGTH = 0x00000200  # Boot stack

   end_bstack  (RW): ORIGIN = 0x2000FC00, LENGTH = 0x00000000

}

And also, modify:

.kernel_data :

    {

        __KERNEL_DATA_START = ALIGN(0x10);

    } > start_of_ram_u

As you can see, a new section called start_of_ram_u is added and __KERNEL_DATA_START should be place at this segment, this way, MQX's kernel will use all available memory in SRAM_U and we can be sure that no object will be stored in the limit of these sections.

Please take in mind that this linker files will be overwritten if you re-compile bsp library, so, modify the linker file every time you compile bsp library.

You can make this test and corroborate if program still crashes, if so, probably your are consuming all availble SRAM.

I hope this can help you!

Best regards,

Isaac Avila

View solution in original post

0 Kudos
10 Replies
2,233 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

If you look at K60's reference manual in section 3.5.3.2 SRAM Arrays, you will notice that effectively, there are two SRAM sections (SRAM_L and SRAM_U), also, in next chapter, there is a section (3.5.3.4 SRAM accesses) that specifies the access to these regions:

SRAM accesss.jpg

There is a note that says: "Burst-access cannot occur across the 0x2000_0000 boundary that separates the two SRAM arrays. The two arrays should be treated as separate memory ranges for burst accesses".

Problem here is when any object is stored sharing both sections, if this case occurs, we need to modify linker file to allocate a dummy section/variable in this limit to avoid any crashing due SRAM access.

In order to be sure that this is the problem you are facing, could you please be so kind to attach your map file?

Best Regards,

Isaac Avila

0 Kudos
2,233 Views
utsavikalpesh
Contributor V

Hi Isaac,

Thanks for reply.

In my project I am using MFS and RTCS Lib.

i have not changed the .lcf file (default single 128kb block of SRAM linker

file ) and .map file find in attachment.

I our application I write like this:

1.

printf("Static RAM Usage:  %d Bytes\r\n",

(uint32_t)_mqx_get_initialization()->START_OF_KERNEL_MEMORY -

0x1FFF0000);

2.

printf("  Peak RAM Usage:  %d Bytes(%d%%)\r\n",

(uint32_t)_mem_get_highwater() - 0x1FFF0000,

((uint32_t)_mem_get_highwater() - 0x1FFF0000)/0x51E);

3.

printf("Current RAM Free:  %d Bytes(%d%%)\r\n", memget_free(),

memget_free()/0x51E);

and show RAM usage as.,

Static RAM usage: 51520 Bytes

Peak RAM usage: 130484 Bytes(99 %)

Current RAM Free: 1484 Bytes (1%)

In MAP file BSS + DATA  RAM = 51520 Bytes RAM match with Static RAM usage

Please elaborate Peak RAM usage...It is 78980 Bytes more than .MAP

file(51520)?

Where this size come from?

Is RTCS and MFS Library use 78980  Bytes RAM?

Please Elaborate this...I am confused..

Regards,

Utsavi Bharuchwala

On Wed, Feb 10, 2016 at 6:49 AM, isaacavila <admin@community.freescale.com>

0 Kudos
2,233 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

Which MQX version are you using? I noticed that your linker file is different to mine in some aspects (extensions are also different) and _mem_get_free function is not described in MQX 4.2's reference manual.

Best Regards,

Isaac

0 Kudos
2,233 Views
utsavikalpesh
Contributor V

hi isaac,

Thanks for your reply,

I am using Codewarrior version 10.6, *Freescale MQX™ RTOS Version 4.0.1 *and

Tower KIT TWRK60D100M (Proc-MK60DN512VMD10).

i upgraded Freescale MQX™ RTOS Version 4.2 but in this version our tower

TWRK60D100M lib (BSP,PSP,RTCS,MFS....) missing in cw10 folder.

(C:\Freescale\Freescale_MQX_4_2\mqx\build\cw10) (Not using GCC )

so without lib we cant use this version of MQX 4.2 . so i move further in

Version 4.0.

please help me out in RAM Scenario in MQX 4.0..

On Thu, Feb 11, 2016 at 3:34 AM, isaacavila <admin@community.freescale.com>

0 Kudos
2,234 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

Let me explain what I think is causing the problem and then you can do next test.

If you remember, SRAM is divided into 2 x 64-kB lenght blocks and they are accessed from different buses so we have to be sure that any object (variable, structure) is not stored by overlapping both sections, for example, next imagen shows a scenario where a 32-bit variable is stored between these blocks:

Allocation problem.jpg

In this case, there would be an access problem and program would crash. Remember that this could be avoided in compilation-time although it is difficult to prevent this on run-time

Now, by analyzing your map file, this is how your memory is used:

Current memory occupation.jpg

You application data (like .bss objects) does use 51 520 bytes, after this, there is a segment called __KERNEL_DATA_START that signals where KERNEL will start to use data for stack or heap from different tasks. What i think could be causing the crashing is the fact that kernel could allocate any objetc in the limit of both SRAM sections, so we can make a quick test to validate if this is the problem or you are really using all the RAM in your project.

I'd recommend you to move the __KERNEL_DATA_START address to 0x2000_0000 although the left ~13kB of SRAM_L would get unnused, but this way we can be sure that kernel will not allocate memory in the middle of both sections:

Move Kernel start.jpg

For doing this, you will need to modify your linker file (located at: <MQX_4_0_PATH>\lib\twrk60d100m.cw10\debug\bsp) and add next line in memory segment:

MEMORY

{

   vectorrom   (RX): ORIGIN = 0x00000000, LENGTH = 0x00000400

   cfmprotrom  (R): ORIGIN = 0x00000400, LENGTH = 0x00000020

   rom         (RX): ORIGIN = 0x00000420, LENGTH = 0x0007FBE0  # Code + Const data

   ram         (RW): ORIGIN = 0x1FFF0000, LENGTH = 0x00020000  # SRAM - RW data

   start_of_ram_u (RW): ORIGIN = 0x2000000, LENGTH = 0x00000000

   # kernel space starts after RAM variables (Location of MQX Kernel data + MQX heap)

   end_of_kd   (RW): ORIGIN = 0x2000FFF0, LENGTH = 0x00000000

   # Boot stack reused by MQX Kernel data

   bstack      (RW): ORIGIN = 0x2000FA00, LENGTH = 0x00000200  # Boot stack

   end_bstack  (RW): ORIGIN = 0x2000FC00, LENGTH = 0x00000000

}

And also, modify:

.kernel_data :

    {

        __KERNEL_DATA_START = ALIGN(0x10);

    } > start_of_ram_u

As you can see, a new section called start_of_ram_u is added and __KERNEL_DATA_START should be place at this segment, this way, MQX's kernel will use all available memory in SRAM_U and we can be sure that no object will be stored in the limit of these sections.

Please take in mind that this linker files will be overwritten if you re-compile bsp library, so, modify the linker file every time you compile bsp library.

You can make this test and corroborate if program still crashes, if so, probably your are consuming all availble SRAM.

I hope this can help you!

Best regards,

Isaac Avila

0 Kudos
2,233 Views
utsavikalpesh
Contributor V

Thanks Issac,

As you suggest I modify Linker file but It seems that my stack reach its Limit.

Regards,

Utsavi Bharuchwala

0 Kudos
2,233 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

Just to keep things clear, have you found the root cause for this issue? how did you realize that you are consuming all the stack? are your referring to stack for any task or your total stack size?

If this is related to stack for any task, you can increase it, on the other hand, if this is related to total stack you should pay attention to unnecessary allocation and/or avoid recursive callings, etc.

Remember that _mem_get_highwater() function returns the highest address that was assigned by MQX kernel, however, it does not imply that you are consuming all the available memory, because you can free memory below this address and you'd still have available memory.

I hope this can help you!

Best Regards,

Isaac

0 Kudos
2,233 Views
utsavikalpesh
Contributor V

Hi Issac,

Sorry for the delay and thanks for reply.

I am talking about total Stack Size.

I  am still not able to declare that my all RAM is consumed.

As you suggest in discussion, by modifying the .lcf file as above and program still crashed then it indicates all RAM is consumed. So I modify .lcf , I see the effect of this into .map file and my program is not working so from that suggestion I come to know that my all RAM is used.

If I am going to modify Linker File like below :

  start_of_ram_u (RW): ORIGIN = 0x2000000, LENGTH = 0x0000FFFF 

.kernel_data : #AT(ADDR(.main_application_bss) + SIZEOF(.main_application_bss))

    {

        __KERNEL_DATA_START = ALIGN(0x10);

    }> start_of_ram_u

Now it wouldn't be the case of

Allocation problem.jpg

then why my program stucks??

From the above discussion _mem_get_highwater()  will not give me exact RAM occupied but, can _mem_get_free() give me exact value of Free RAM available?

Regards,

Utsavi Bharuchwala

0 Kudos
2,233 Views
isaacavila
NXP Employee
NXP Employee

Hello Utsavi,

If after doing the test you still got stuck, then it seems that your program is using all available memory. Are you validating every dynamic allocation so program could be able to detect when there is no enough space?

Also, system could be crashing due some invalid values (NULL pointers) or any memory corruption, you will need to debug your project and get the exact moment where the problem is gotten and check what could be causing the problem (invalid pointers, memory corruption, not enough space, etc).

Regards,

Isaac

0 Kudos
2,233 Views
utsavikalpesh
Contributor V

Hi Issac,

Thanks for Reply.

I will debug the project and check if any memory corruption occurred?

Regards,

Utsavi Bharuchwala

0 Kudos