Azure RTOS / MDK-Arm - Linking errors

[MLade.1]

I'm trying to build the example project "Tx_Thread_Creation" for the NUCLEO-F429ZI. During the build process with the MDK-ARM (uVision) V5.28.0.0 toolchain I got the following linker errors:

linking...
Tx_Thread_Creation\Tx_Thread_Creation.axf: Error: L6218E: Undefined symbol __RAM_segment_used_end__ (referred from tx_initialize_low_level.o).
Tx_Thread_Creation\Tx_Thread_Creation.axf: Error: L6218E: Undefined symbol _vectors (referred from tx_initialize_low_level.o).
Tx_Thread_Creation\Tx_Thread_Creation.axf: Error: L6218E: Undefined symbol g_pfnVectors (referred from tx_initialize_low_level.o).
Not enough information to list image symbols.
Not enough information to list load addresses in the image map.
Finished: 2 information, 0 warning and 3 error messages.
"Tx_Thread_Creation\Tx_Thread_Creation.axf" - 3 Error(s), 0 Warning(s).
Target not created.
Build Time Elapsed:  00:00:03

I also tried to build the same project with the STM32CubeIDE Ver. 1.8.0 toolchain. The build process finished successfully:

Finished building target: Tx_Thread_Creation.elf
 
arm-none-eabi-size   Tx_Thread_Creation.elf 
arm-none-eabi-objdump -h -S  Tx_Thread_Creation.elf  > "Tx_Thread_Creation.list"
arm-none-eabi-objcopy  -O binary  Tx_Thread_Creation.elf  "Tx_Thread_Creation.bin"
   text	   data	    bss	    dec	    hex	filename
  21328	     36	   6932	  28296	   6e88	Tx_Thread_Creation.elf
Finished building: default.size.stdout
 
Finished building: Tx_Thread_Creation.bin
 
Finished building: Tx_Thread_Creation.list
 
 
13:54:27 Build Finished. 0 errors, 0 warnings. (took 13s.891ms)

For the code generation I used the STM32CubeMX Ver. 6.3.0. I prefer to use the MDK-ARM for the project compilation. How can I solve the linker errors?

[Haithem Rahmani]

Hi,

Could please read the comment on the top of the tx_initialize_low_level.s file:

// by default AzureRTOS is configured to use static byte pool for
// allocation, in case dynamic allocation is to be used, uncomment
// the define below and update the linker files to define the following symbols
// EWARM toolchain:
//       place in RAM_region    { last section FREE_MEM};
// MDK-ARM toolchain;
//       either define the RW_IRAM1 region in the ".sct" file or modify this file by referring to the correct memory region.
//         LDR r1, =|Image$$RW_IRAM1$$ZI$$Limit|
// STM32CubeIDE toolchain:
//       ._threadx_heap :
//       {
//        . = ALIGN(8);
//        __RAM_segment_used_end__ = .;
//        . = . + 64K;
//        . = ALIGN(8);
//       } >RAM_D1 AT> RAM_D1
//  The simplest way to provide memory for ThreadX is to define a new section, see ._threadx_heap above.
//  In the example above the ThreadX heap size is set to 64KBytes.
//  The ._threadx_heap must be located between the .bss and the ._user_heap_stack sections in the linker script.
//  Caution: Make sure that ThreadX does not need more than the provided heap memory (64KBytes in this example).
//  Read more in STM32CubeIDE User Guide, chapter: "Linker script".
 
//#define USE_DYNAMIC_MEMORY_ALLOCATION

 either you are wrongly configuring your project or you are not defining the needed defines.

Are you using a project from scratch or using a preconfigured one?

[MLade.1]

Dear @Haithem Rahmani_O (ST Employee),

thank you for the fast feedback.

I'm using a preconfigured project, that has been delivered with the "X-CUBE-AZRTOS-F4" package version 1.0.0 (location on the disk: C:\Users\xxxxxxxx\STM32Cube\Repository\Packs\STMicroelectronics\X-CUBE-AZRTOS-F4\1.0.0\Projects\STM32F429ZI-Nucleo\Applications\ThreadX\Tx_Thread_Creation).

According to your suggestion I checked the mentioned comment:

1. The "Tx_Thread_Creation.sct" file has been created during the first build of the project and seems to be configured correctly:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
 
LR_IROM1 0x08000000 0x00200000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00200000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00030000  {  ; RW data
   .ANY (+RW +ZI)
  }
  RW_IRAM2 0x10000000 0x00010000  {
   .ANY (+RW +ZI)
  }
}

2. The "LDR r1, =|Image$$RW_IRAM1$$ZI$$Limit|" statement is available in the "tx_initialize_low_level.s" file and is only relevant for dynamic memory allocation:

...
#ifdef USE_DYNAMIC_MEMORY_ALLOCATION
    LDR     r0, =_tx_initialize_unused_memory       @ Build address of unused memory pointer
    LDR     r1, =Image$$RW_IRAM1$$ZI$$Limit         @ Build first free address
    ADD     r1, r1, #4                              @
    STR     r1, [r0]                                @ Setup first unused memory pointer
#endif
...

The project has been preconfigured with static memory allocation.

[Haithem Rahmani · Accepted solution]

Hi @MLade.1​ ,

just noticed that your compiler is MDK-ARM 5.28, which is not compliant with the recommended version 5.32

the link error comes from the fact that your asm compiler doesn't correctly prerpocess the ".s" file, thus the code is compiling the "GNU GCC" part instead

of the "__CC_ARM" one.

We didn't test this version of the compiler, could you try to rename the "tx_initialize_low_level.s" to "tx_initialize_low_level.S" and try to recompile.

regards

Haithem.

[MLade.1]

Hello Haithem Rahmani (ST Employee),

I tried the suggested solution, but it was not possible to build the project with the MDK-ARM 5.28 without errors.

I installed the MDK-ARM 5.36 on another PC. The preconfigured example and my own project from scratch could be compiled without errors.

Thank you for your support!

Kind regards

Michael

[ibrahimmd]

For those who are facing the linker error using STM32CubeIDE:

tx_initialize_low_level.S:521: undefined reference to `__RAM_segment_used_end__'

It turns out that CubeMX does not change linker files as per procedure in this link:
x-cube-azrtos-h7/Projects/STM32H735G-DK/Applications/ThreadX/Tx_FreeRTOS_Wrapper/README.md at main · STMicroelectronics/x-cube-azrtos-h7 · GitHub

While the procedure are intended for x-cube_azrtos-h7, I used it for my STM32U545 project because I have not find any other option!

I have tried to implement whatever mentioned in the guide and could get the project built successfully.

The guide suggests adding a section between .bss and ._user_heap_stack. it suggests a fixed size, but I tried to let this new section allocate all unused RAM:

  ._threadx_heap :
  {
     . = ALIGN(8);
      _size_so_far = . - ORIGIN(RAM);
     __RAM_segment_used_end__ = .;
     . = ((. + (LENGTH(RAM) - _Min_Heap_Size - _Min_Stack_Size) - (_size_so_far)) / 😎 * 8;
     . = ALIGN(8);
   } >RAM

And this caused RAM to be 100% used as shown in build analyzer:

For those who use IAR Embedded Workbench for ARM, or MDK-ARM, the guide suggests changing linker files as well.

I have not run the code for testing. So, use the above info at your own risk!

I wish somebody from ST follow up this matter because it looks like CubeMX does not take care of linker changes when the user activates Dynamic allocation of ThreadX.

For your info:
- I use Windows 10

- CubeMX version: 6.10.0