topic Re: Gcc ignoring pragma statements to place code into ITCM memory. in Model-Based Design Toolbox (MBDT)

Gcc ignoring pragma statements to place code into ITCM memory.

RNJ — Thu, 13 Aug 2026 08:17:02 GMT

Hello!

Using Matlab R2025b, Simulink and MBDT for S32K3 version 1.7.1 here.

To optimize the performance of a motor controller application we are developing we want to place some parts of the code into the ITCM memory and later on, DTCM memory for data.

As for now, for testing the workflow, I am trying to get a function placed into ITCM memory. I managed to get Simulink/ embedded coder to place the correct pragma statements in to the c code like:

#pragma GCC section text ".itcm_text"
static void Motor_Drive_Subsystem(void)
{
..........
}
#pragma GCC section text ""

However, when compiling the application gcc ignore these pragma statements and places the code in the standard .text segment. This can be concluded with The objdump command:

arm-none-eabi-objdump -h Motor_Control.o (beeing the .o file generated from the c-file containing the Motor_Drive_Subsystem function)

There are no .itcm_text in the list just .text.xxxx segments (among the other non text segments).

When compiling I use the standard switches for gcc set by the MBDT environment:

arm-none-eabi-gcc -O2 -c -std=c99 -fshort-enums -funsigned-char -fstack-usage -ffunction-sections -fdata-sections -g -pedantic -Wall -Wextra -fmessage-length=0 -funsigned-bitfields -fno-common -Wunused -Wstrict-prototypes -Wsign-compare -Werror=implicit-function-declaration -mcpu=cortex-m7 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv5-sp-d16 -DD_CACHE_ENABLE -DI_CACHE_ENABLE -specs=nano.specs -specs=nosys.specs --sysroot="C:\MATLAB_Add-Ons\Toolboxes\NXP_MBDToolbox_S32K3\tools\build_tools\gcc_v10.2\gcc-10.2-arm32-eabi\arm-none-eabi\newlib" -DSTEP_GPT_TIMER -DSTEP_GPT_CHANNEL=GptConf_GptChannelConfiguration_StepTimer -DSTEP_GPT_CHANNEL_FREQ=40000000 -DSTEP_GPT_CHANNEL_VALUE_MAX=4294967295 -DAUTOSAR_OS_NOT_USED -D__MW_TARGET_USE_HARDWARE_RESOURCES_H__ -DGCC -DS32K3XX -DS32K396 -DCPU_S32K396 -DENABLE_FPU -DMPU_ENABLE -DMBDT_INIT -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTERMFCN=0 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DTID01EQ=0 -DSTACK_SIZE=64 -DRT -DMODEL=Motor_Control -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO -DMODEL_HAS_DYNAMICALLY_LOADED_SFCNS=0 -IC: .....

By modifying the generated c code file and manually compiling it I can conclude the following:

Removing the “static” declaration of the function does not help. However, removing “static” and using the alternative way for this by adding an attribute statement on the function:

static void __attribute__((section(".itcm_text")))Motor_Drive_Subsystem(void);

will create a .itcm_text segment in the .o file.

I am not sure if I am doing something wrong here or if it is a tool problem.

Can someone guide me on how to get this working?

Of course, we want the tool chain to handle this and do not want to manually modify the c code after code generation.

As far as I can see it looks like the startup_cm7.s and linker_flash_s32k396.ld files are prepared for handling the ITCM and DTCM memories.

I found this post in the forum, not sure if it is relevant for this: https://community.nxp.com/t5/S32-Design-Studio/No-GCC-11-4-item-in-new-project-wizard-dialog-on-S32DS-3-6-2/td-p/2134523

The MBDT gcc seems to be build 1728 where as the fixed one in the post is build 1803.

Thanks in advance!

Re: Gcc ignoring pragma statements to place code into ITCM memory.

SorinIBancila — Thu, 13 Aug 2026 14:48:17 GMT

Hello,

Please check the following page on MathWorks website how to set up a custom storage class.: Control Data and Function Placement in Memory by Inserting Pragmas.
The part that you need to use is "Override Default Memory Placement for Subsystem Functions and Data".

After you created you custom storage class, you must configure the model to load it:

0. Create and configure the custom storage class:

1. Enter Code Perspective

2. Open Embedded Coder DIctionary (Model)

3. Load the custom class you previously created.

4. Inside the model, create a new Subsystem and set it to atomic.

5. Inside the Code Generation, set the Memory section for execution functions: "MemSection_ITCM" as set in the custom class.

6. arm-none-eabi-objdump properly repots that ITCM_ToggleDIO.o is loaded into the .itcm_text memory section

arm-none-eabi-nm -n s32k3xx_dio_s32ct.elf also says that ITCM_ToggleDIO is found at 0x0 address.

If the .elf is flashed from the S32DS and a breakpoint is used inside the s32k3xx_dio_s32c_ITCM_ToggleDIO function., in the disassembly view we can see that the instructions are stored starting at 0x0 address.

Best regards,
Sorin Bancila

Re: Gcc ignoring pragma statements to place code into ITCM memory.

RNJ — Fri, 14 Aug 2026 11:07:40 GMT

Hi Sorin

Thanks for helping out!

I was actually following those instructions at Mathworks web site.

Now I have the insertion of attribute statements instead of pragma statements working.

But still, gcc refuses to put the function into the .itcm_text segment.

I use these code generation settings for the block:

Generated code for function like this:

/* Redirect standard code generation to ITCM */
__attribute__((section(".itcm_text")))
static void Motor_Drive_Subsystem(void)
{ .... }

Conclusion:

No itcm_text segment in .o file
Gcc optimizes the function away completely (seen by disassembling .o file)
If I remove the “static” declaration of the function in the generated .c and manually recompile it I will get the .itcm_text segment in the .o file.
It looks like the “static” declaration makes the gcc compiler ignore the attribute prefix.

If I set the block to “Reusable function” in modelsim, hoping this would remove the static declaration:

I get:

Still no .itcm_text segment in .o file
Function still declared as “static” in generated c code
Disassembly of .o file shows that gcc keeps the function in the assembly code but there is no sign of directing to .itcm_text segment

So is the “static” declaration the problem (something with settings in Simulink or embedded coder) or is the problem with gcc prioritizing “static” over the “attribute” declaration?

Best regards