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:
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:
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:
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
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:
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
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:
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:
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:
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
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
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
