MCU-PLUS-SDK-AM243X: susipcious created .text_tcm-section

Hi Felix,

The section "text_tcm" which is placed in the TCMA memory, consists majorly of the time critical functions in the PROFINET FWHAL. As shared in your first screenshot, the keyword 'FAST_CODE_HWAL' is appended to most function definitions in the PROFINET FWHAL, and the corresponding text for these functions is stored in TCMA memory. This speeds up the execution time of these functions and also provides better performance in high traffic load situations.

Kindly let us know if you have any follow-up questions

Regards,

Laxman 

Hello Laxman,

I understand the use-case and I never questioned it, but what bugs me is that is automatically placed in TCM without ever being referenced in the linker-script. I can't find any documentation to this and it's not a wanted behaviour to have something magically appear like that. I also cannot see that this follows the default placement algorithm of the linker.

I would've assumed you use the Smart placement (https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/smart_placement/index.html) for that or document that it should be placed in tcm (we did that anyway before that section occured) but not like a magically occuring section.

Where is the documentation for this? I'm just probably missing it.

Best regards

Felix

Hi Felix,

Felix Heil said:

but what bugs me is that is automatically placed in TCM without ever being referenced in the linker-script

These functions are selected and placed in TCM. For example, "void FAST_CODE_HWAL PN_PTCP_resetDelayTimings"

Any function with "FAST_CODE_FWHAL" appended in the definition will be a part of text_tcm section.

The section "text_tcm" is then placed in the TCMA memory as specified in the linker.cmd file.

This is not explicitly mentioned in the documentation, we will update this accordingly in the upcoming SDK release.

Best Regards,
Laxman

Thanks Laxman,

I understand the usage of this #define and this section. I do not think that's our problem. 

I also figured something out at our side. The profinet_device_rt_mrp_mii_icss_fwhal.am243x.r5f.ti-arm-clang.release.lib is placed inside the DDR-RAM in our linker-scripts.
We do NOT use the example and thus not the mentioned linker-script which places the .text_tcm-section in TCMA. We never reference this .text_tcm-section anywhere. Still it pops up inside the TCMA. So I still do not understand what brings this section automatically into the tcm, even when it's not mentioned anywhere and the library which contains the section is even placed somewhere else.
Following https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/05_linker_command_files/the-sections-directive-stdz0759595.html#section-allocation-and-placement it states: "If you do not tell the linker how a section is to be allocated, it uses a default algorithm to place the section." and if we look at the default algorithm https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/07_default_placement_algorithm/default-placement-algorithm-stdz0752588.html#stdz0752588 and also follow the default memory model https://software-dl.ti.com/codegen/docs/tiarmclang/rel4_0_2_LTS/compiler_manual/linker_description/05_linker_command_files/the-memory-directive-stdz075888.html#default-memory-model it states it will use the whole available 32-bit-memory address range. This would be the only explanation why it it placed inside the the TCMA, because it is located at 0x00000000. BUT: we also noticed that the .text_tcm-section will be automatically placed at the TCMB in another project, so at range of 0x41010000, if it is never mentioned in the linker-script:
 

So this can't be the whole story or the toolchain-documentation is not complete.

best regards

Felix

Hi Felix,

Thanks for the clarification, I now understand the issue you are facing. If the generated linker.cmd file does not explicitly mention the text_tcm section to be placed in TCMA section, then this behavior would not be expected. Few queries to understand this behavior better.

1) Could you share your syscfg file and the corresponding linker.cmd, to review this once?

2) Can you share a screenshot from the memory map to confirm any of the text from "text_tcm" being placed in the TCMA?

Best Regards,
Laxman

hey Laxman,

sorry for the late reply. Well, we do not use SysCfg. We modified the SDK-API to directly take configs instead of arrays and indexes and also we did all other initialization stuff manually because we implemented a C++-driver-library for our purposes. Our linker-file also uses some header-includes since we use multiple cores and define the address-ranges for the memory-directives for all cores in a header-file. But I can send you those in a private message of course.

here is a screenshot where we also place the text.hwi-section inside the tcma. the .text_tcm gets automatically placed afterwards:

the screenshot for the situation where it's placed in tcmb is in the previous post. I guess that happened because the tcma has no more space (0x7110 used, maximum space is 0x8000, so no place for 0x16fc .text_tcm-section). Please also notice the screenshot with tcmb uses Profinet irt. the screenshot with tcma uses only Profinet rt.

best regards

Felix

Hi Felix,

We expect the text_tcm section to be not placed in the memory section if this is not specifically mentioned in the linker.cmd file. However, let me discuss this internally and will get back to you soon. 

Best Regards,
Laxman

Hi Felix,

I just took a look into your inquiry and saw the same behavior you reported. Even if the section is not explicitly mentioned in the linker script, it is still defined by the linker and automatically placed in TCM. I'm trying to look for the proper documentation for this and I'll get back to you soon.

Kind regards,
Kamil 

Hey Kamil,

thanks for clarification, so it works like I also guessed. And just to make sure I got everything correctly: TCMA starts at 0x00000000. As soon as the space in there, which is defined in the memory-directive, is not enough, it moves the section to the next address defined in the memory-directive and in incremental order. So there is a "hole" seen by the linker between 0x00008000 (end of TCMA) and 0x41010000 (start of TCMB) which is not given to the linker as useable memory. Since the next useable address is the TCMB and GPMC, SRAM and DDR start afterwards (0x50000000, 0x70000000 and 0x80000000) it will use exactly this TCMB-address. But this memory needs to be made known to the linker inside the linker-command-file memory-directive. If in theory there would be another memory at let's say 0x30000000, it would use this address instead.

Is my assumption correct? I just wanna make clear I got everything right.

Hi Felix,

Thanks for your follow up.

Yes, your assumption is correct. The linker places the section in the first sufficient and "usable" memory space defined by the MEMORY directive of the linker.cmd file.

You can always verify this by playing around with the different regions defined within MEMORY and observing the generated map file to see where each section is allocated.

Kind regards,
Kamil