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

cross mob
lock attach
Attachments are accessible only for community members.
hamba
Level 2
Level 2
10 replies posted 25 sign-ins 5 questions asked

Hi!
I am currently working on an ERIKA project for TC39x, and I'm trying to remap my application from PFLASH to RAM.
I have made some modifications to the linker script, but I am encountering the below errors, and I have not been able to resolve them.
I'm using TASKING v6.2r2.
Find attached the linker script (just remove the “.html” at the end of its name).

ltc E112: cannot locate 8 section(s):
ltc I455: requirement: 0x108 bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: range restriction - range(s) 0x70100000-0x70110000
ltc I457: .rodata.CPU0.ee_kernel_const (8743) (0x8 bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (6) (0x8 bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (43) (0x8 bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (42) (0xc bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (29) (0x14 bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (36) (0x1c bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (49) (0x34 bytes)
ltc I457: .rodata.CPU0.ee_kernel_const (14) (0x80 bytes)
ltc E112: cannot locate 5 section(s):
ltc I455: requirement: 0x90 bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: range restriction - range(s) 0x60100000-0x60110000
ltc I457: .rodata.CPU1.ee_kernel_const (24) (0x4 bytes)
ltc I457: .rodata.CPU1.ee_kernel_const (25) (0x8 bytes)
ltc I457: .rodata.CPU1.ee_kernel_const (7) (0x10 bytes)
ltc I457: .rodata.CPU1.ee_kernel_const (52) (0x34 bytes)
ltc I457: .rodata.CPU1.ee_kernel_const (15) (0x40 bytes)
ltc E112: cannot locate 5 section(s):
ltc I455: requirement: 0xcc bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: range restriction - range(s) 0x50100000-0x50110000
ltc I457: .rodata.CPU2.ee_kernel_const (8) (0x8 bytes)
ltc I457: .rodata.CPU2.ee_kernel_const (31) (0x14 bytes)
ltc I457: .rodata.CPU2.ee_kernel_const (38) (0x1c bytes)
ltc I457: .rodata.CPU2.ee_kernel_const (55) (0x34 bytes)
ltc I457: .rodata.CPU2.ee_kernel_const (16) (0x60 bytes)
ltc E112: cannot locate 5 section(s):
ltc I455: requirement: 0xcc bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: range restriction - range(s) 0x40100000-0x40110000
ltc I457: .rodata.CPU3.ee_kernel_const (9) (0x8 bytes)
ltc I457: .rodata.CPU3.ee_kernel_const (33) (0x14 bytes)
ltc I457: .rodata.CPU3.ee_kernel_const (40) (0x1c bytes)
ltc I457: .rodata.CPU3.ee_kernel_const (58) (0x34 bytes)
ltc I457: .rodata.CPU3.ee_kernel_const (17) (0x60 bytes)

 Many thanks,

0 Likes
1 Solution

The linker is still 'unhappy' about the approach to place ROM sections in RAM memory. The vector table sections are ROM sections. I think the easiest solution to solve this is to modify the tc39x.lsl file which is included by your LSL file. To do so you should copy the default tc39x.lsl which which is located in the ctc\include.lsl subfolder of the TriCore tools installation folder into your project folder wherein your ee_tc_tasking_flash.lsl file is located. Afterwards you can remove the write protection from this file and start adapting the content. 

Please change the memory type of all RAM memories wherein you would like to place const or program code sections from RAM to NVRAM. Then the linker will accept the placement of ROM sections in the given memories. E.g.

memory pspr0 // Program Scratch Pad Ram CPU0
{
mau = 8;
size = 64k;
type = ram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=64k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=64k);
}

will have to be changed to:

memory pspr0 // Program Scratch Pad Ram CPU0
{
mau = 8;
size = 64k;
type = nvram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=64k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=64k);
}

Best regards,
Ulrich Kloidt

View solution in original post

10 Replies
Meet_T
Moderator
Moderator
Moderator
25 likes received 50 solutions authored 100 replies posted

Hi @User13836 , Could you please help here?

Thanks,

Meet.

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

The cause of the linker error is likely, that you try to place non initialized const data sections in core local PSPR RAM memory. The linker does not accept the placement of const data in RAM memory if the const data is not initialized (copied from flash to RAM, typically executed by the C startup code).

If you want to use initialized const data, you can modify the group entries for all groups locating const data in PSPR RAM and add a copy keyword. E.g. the entry 

group tc0_liner_const (run_addr=mem:mpe:pspr0) {
...

can be changed to 

group tc0_liner_const (copy, run_addr=mem:mpe:pspr0) {
...

 

A LSL FAQ is avaialble at:

https://resources.tasking.com/tasking-whitepapers/linker-script-language-lsl-tips-tricks-for-tasking...

This descibes some typical use cases and might be helpful.

 

Best regards,

Ulrich Kloidt
TASKING tools support

0 Likes
hamba
Level 2
Level 2
10 replies posted 25 sign-ins 5 questions asked

Hello Ulrich,
I have attempted the solution you suggested, but unfortunately, I encountered another error.
The error message I received was:

ltc E821: ["C:\Users\mmefteh\ECLIPS~4\ERIKAD~1\erika\mk\EE_TC_~1.LSL" 106/3] 
Section .rodata.CPU0.ee_kernel_const in group tc0_liner_const has memory type RAM
but expected memory type ROM like section [.rodata.CPU0.ee_kernel_const] in the same group.
ltc F019: unrecoverable error: fatal locate error

Actually my application was compiled successfully for PFLASH, which means I need to perform a flash operation every time I make changes to my app and compile again. To streamline this process, we plan to map all the code to RAM, allowing the application to be loaded into RAM instead.
Can you please advise on how to address the matter?

0 Likes

The linker error is due to the select line you are using which is e.g.:

select "*(.CPU0.ee_kernel_const|.CPU0.ee_kernel_const*)";

This selct will select a section named:

.rodata.CPU0.ee_kernel_const

as well as the ROM copy section of this section which does have the same name but is embraced by square brackets:

[.rodata.CPU0.ee_kernel_const]

and because the ROM copy section shall be placed in ROM, the linker complains. 

You can consider exclude the selection of the ROM copy section by adding an attributes entry to the select line like:

select "*(.file_1.main|file_1.main*)" (attributes=+i);

which will select only initialized sections with a name that matches the select pattern. Then the linker will not select the ROM copy of the initialized section anymore.

I'm not sure if I understood your comment:

 Actually my application was compiled successfully for PFLASH, which means I need to perform a flash operation every time I make changes to my app and compile again. To streamline this process, we plan to map all the code to RAM, allowing the application to be loaded into RAM instead.

If your goal is to have a debugger to load the application code directly into RAM memory, then the debugger will take care of the initialization and the C startup code does not need to do so anymore, you can consider to remove the 'copy' entry again from the LSL group and just add a writeable attribute to the group definition. Then the linker will have to place the section in RAM memory:

group tc0_liner_const (run_addr=mem:mpe:pspr0, attributes=rw)) {
...

Best regards,

Ulrich

0 Likes
lock attach
Attachments are accessible only for community members.

Thank you, Ulrich, for your suggestion.
I have a Lauterbach debugger, and I want to load the application into RAM memory.
Following your instructions, I was able to compile the application without any issues.
However, when I attempt to load the ELF file using the debugger, I encounter a bus error at address range P:0x80000000-0x8000001F.
It appears that there may be other sections mapped to FLASH memory.
How can I verify this?
Please find attached the linker script (just remove the “.html” at the end of its name).

0 Likes

Thanks for the update. You are using macros in the linker LSL file to adapt the placement of the interrupt and trap vectors in order to locate them in RAM memory. This is indeed required to place them in RAM too. But you are using the wrong order in your LSL file. You need to ensure the macros are defined before the inclusion of the <derivative>.lsl file, here tc39x.lsl. Since otherwise the default values are used which are defined in the tc39x.lsl file. Please adapt your LSL file and use:

 

# define TRAPTAB0 0x70100000+0x1F00
# define INTTAB0 (TRAPTAB0+0x100)

# define TRAPTAB1 0x60100000+0x1F00
# define INTTAB1 (TRAPTAB1+0x100)

# define TRAPTAB2 0x50100000+0x1F00
# define INTTAB2 (TRAPTAB2+0x100)

# define TRAPTAB3 0x40100000+0x1F00
# define INTTAB3 (TRAPTAB3+0x100)

# define TRAPTAB4 0x30100000+0x1F00
# define INTTAB4 (TRAPTAB4+0x100)

# define TRAPTAB5 0x10100000+0x1F00
# define INTTAB5 (TRAPTAB5+0x100)

# define RESET 0x70100000
# define TRAPTAB TRAPTAB0
# define INTTAB INTTAB0

#if defined(__PROC_TC39X__)
#include "tc39x.lsl"

After this modification, you can try to build the application again. 

Best regards,
Ulrich Kloidt

 

lock attach
Attachments are accessible only for community members.

Hello Ulrich,
Thanks for the detailed description.
Unfortunately following your instructions I got another errors related to the interrupt and trap tables.

ltc E112: cannot locate 1 section(s):
ltc I455: requirement: 0x10 bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: absolute restriction - at address 0x70102020
ltc I457: .text.inttab0.intvec.001 (1470) (0x10 bytes)
ltc E112: cannot locate 1 section(s):
ltc I455: requirement: 0xa bytes of ROM area in space mpe:vtc:linear
ltc I456: section type: absolute restriction - at address 0x70101f00
ltc I457: .text.traptab0.trapvec.000 (1242) (0xa bytes)

I am wondering why the linker is encountering difficulties when attempting to place these sections into memory. According to the error, it seems that the specified memory addresses do not conform to the constraints outlined in the linker script. However, we already redefined these sections to the 0x70100000 address.
Could you please provide us with some guidance or hints for resolving the reported issue?

0 Likes

The linker is still 'unhappy' about the approach to place ROM sections in RAM memory. The vector table sections are ROM sections. I think the easiest solution to solve this is to modify the tc39x.lsl file which is included by your LSL file. To do so you should copy the default tc39x.lsl which which is located in the ctc\include.lsl subfolder of the TriCore tools installation folder into your project folder wherein your ee_tc_tasking_flash.lsl file is located. Afterwards you can remove the write protection from this file and start adapting the content. 

Please change the memory type of all RAM memories wherein you would like to place const or program code sections from RAM to NVRAM. Then the linker will accept the placement of ROM sections in the given memories. E.g.

memory pspr0 // Program Scratch Pad Ram CPU0
{
mau = 8;
size = 64k;
type = ram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=64k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=64k);
}

will have to be changed to:

memory pspr0 // Program Scratch Pad Ram CPU0
{
mau = 8;
size = 64k;
type = nvram;
map (dest=bus:tc0:fpi_bus, dest_offset=0xc0000000, size=64k, exec_priority=1);
map (dest=bus:sri, dest_offset=0x70100000, size=64k);
}

Best regards,
Ulrich Kloidt

hamba
Level 2
Level 2
10 replies posted 25 sign-ins 5 questions asked

Hello Ulrich,

Thank you for your support; it has been very helpful.
I have one more question: where can I find detailed documentation on linker syntax? I have more modifications to make and would like a better understanding of this topic.

Best Regards,

0 Likes

Thanks for the feedback. You can have a look at the LSL FAQ I referred to before which shows some linker use cases:

https://resources.tasking.com/tasking-whitepapers/linker-script-language-lsl-tips-tricks-for-tasking...

You can also contact the TASKING support (support@tasking.com) in order to request login credentials for the TASKING Support Center. The Support Center does include some additional linker related FAQs.

The LSL language itself is explained in the TriCore Tools User Guide (ctc_user_guide.pdf) in chapter

17. Linker Script Language (LSL)

Best regards,
Ulrich Kloidt