Specific RAM Section mapping

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
sureshbabu806
Level 1
Level 1
First reply posted First question asked Welcome!

Hi All, 

I am working Aurix TC33x microcontroller, I need to create a specific RAM location for variables.

Eg: 

i have created a section as below 

#pragma section farbss "Ram_sharedmessage"
#pragma protect on

am using the above statement before the variable.

In linker file i have configured the memory section as below

memory dspr0_ram // Data Scratch Pad Ram CPU0
{
mau = 8;
size = 16;
type = ram;
map cached (dest=bus:tc0:fpi_bus, dest_offset=0x7002BCC0, size=16, priority=3, exec_priority=0);
map not_cached (dest=bus:tc0:fpi_bus, dest_offset=0xd002BCC0, size=16, priority=3, exec_priority=0);
}

and created a section as below 

section_layout :tc0:linear
{
group (ordered, contiguous,align = 32,run_addr=mem:spe:dspr0_ram)
{
section "Ram_sharedmessage" (size = 0x10, attributes = rw, fill = 0x00)
{

select "*.Ram_sharedmessage";
}
}
}

 

after successful complication memory map does not located as per my section defined memory. 

Kindly can someone share your thoughts on it , please. Kindly do not hesitate to ask me for more information.

Many thanks, 

0 Likes
1 Solution
User13836
Level 6
Level 6
50 likes received 50 solutions authored 100 sign-ins

Please review the map file content. Does it show sections with the name .bss.Ram_sharedmessage which is the resulting section name for non initialized (cleared) far accessed data? If the section name is .zbss.Ram_sharedmessage instead it will be non initialized (cleared) near addressable data instead. Then you can consider to apply the C compiler option -N0 to disable the default near allocation of all variables but variables defined using the __near qualifier explicitly.

Another possible explanation:

If you are using the virtual core approach (vtc) and you define a shared variable you need to assign the section including that variable in a vtc layout instead of the tc0 (core 0 local) one:

section_layout :vtc:linear
{
group (ordered, contiguous,align = 32,run_addr=mem:spe:dspr0_ram)
{
section "Ram_sharedmessage" (size = 0x10, attributes = rw, fill = 0x00)
{

select "*.Ram_sharedmessage";
}
}
}

Another possible explanation. If your LSL file does include some more generic assignments like:

 

group my_far_bss (...)
{
   select ".bss.*";
}

And this group is defined previously to your group definition in the LSL file, the linker will assign the .bss.Ram_sharedmessage sections to this group First come, first serve. The linker does process the LSL file content from top to bottom.

Best regards,

Ulrich Kloidt
TASKING tools support

 

 

View solution in original post

0 Likes
5 Replies
User13836
Level 6
Level 6
50 likes received 50 solutions authored 100 sign-ins

Please review the map file content. Does it show sections with the name .bss.Ram_sharedmessage which is the resulting section name for non initialized (cleared) far accessed data? If the section name is .zbss.Ram_sharedmessage instead it will be non initialized (cleared) near addressable data instead. Then you can consider to apply the C compiler option -N0 to disable the default near allocation of all variables but variables defined using the __near qualifier explicitly.

Another possible explanation:

If you are using the virtual core approach (vtc) and you define a shared variable you need to assign the section including that variable in a vtc layout instead of the tc0 (core 0 local) one:

section_layout :vtc:linear
{
group (ordered, contiguous,align = 32,run_addr=mem:spe:dspr0_ram)
{
section "Ram_sharedmessage" (size = 0x10, attributes = rw, fill = 0x00)
{

select "*.Ram_sharedmessage";
}
}
}

Another possible explanation. If your LSL file does include some more generic assignments like:

 

group my_far_bss (...)
{
   select ".bss.*";
}

And this group is defined previously to your group definition in the LSL file, the linker will assign the .bss.Ram_sharedmessage sections to this group First come, first serve. The linker does process the LSL file content from top to bottom.

Best regards,

Ulrich Kloidt
TASKING tools support

 

 

0 Likes

Hi Ulrich, 

Thanks for your response.

I have tried to use the section vtc instead of tc0

section_layout :vtc:linear

and am getting compilations error as below 

ltc E821: ["D:\Daimaler_EOL\app\variants\mb_mma_25_scu_red\mb_mma_25_scu_red.lsl" 131/1] syntax error: could not find core vtc for section layout
ltc F018: Invalid LSL file, aborting.. 

 

 

0 Likes

Thanks for the verification. Then it's one possible cause less. Please verify the other two use cases I mentioned in my previous reply.

0 Likes

I have tried the below option 

group my_far_bss (...)
{
   select ".bss.*";
}

Even though after successful compilation. Section variables are not placed as my expection  

 

0 Likes

Without knowing your use case it is not possible to locate the cause of the unexpected locate result. To review this the LSL files used (also the ones included using #include in a main LSL file are needed plus the linker invocation options and a map file excerpt including the locate result section snippet which shows where the section(s) in question are placed by the linker. 

0 Likes