Other Parts Discussed in Thread: AM6442
Hello,
At first place, the key products and versions:
- OS: Windows 10
- CCS IDE 12.5.0.00007
- MCU+ SDK for AM64x v09.01.00.41
- SYSCONFIG v1.18.0
After upgrading to MCU+ SDK for AM64x v09.01.00.41, I was trying to import an example project, in this case hello_world_am64x-evm_r5fss0-0_freertos_gcc-armv7. I have separately installed a recent GCC version (arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi) and try to build the project. The result is a failed build with the following linker error:
makefile:156: recipe for target 'hello_world_am64x-evm_r5fss0-0_freertos_gcc-armv7-09.01.out' failed
C:/ti/arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.exe:syscfg/linker.cmd:12: syntax error
make was executing the following link command:
Building target: "hello_world_am64x-evm_r5fss0-0_freertos_gcc-armv7-09.01.out"
Invoking: GNU Linker
"C:/ti/arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi/bin/arm-none-eabi-gcc-13.2.1.exe" -mfpu=vfpv3-d16 -DSOC_AM64X -D_DEBUG_=1 -Og -ffunction-sections -fdata-sections -g -gdwarf-3 -gstrict-dwarf -Wall -Werror -Wno-unused-function -Wno-enum-compare -Wno-uninitialized -Wno-int-to-pointer-cast -fgnu89-inline -Wno-pointer-to-int-cast -Wno-unused-variable -Wno-unused-but-set-variable -mcpu=cortex-r5 -Wl,-Map,"hello_world.Debug.map" -static -Wl,--gc-sections -L"C:/ti/mcu_plus_sdk_am64x_09_01_00_41/source/kernel/freertos/lib" -L"C:/ti/mcu_plus_sdk_am64x_09_01_00_41/source/drivers/lib" -L"C:/ti/mcu_plus_sdk_am64x_09_01_00_41/source/board/lib" -L"/lib" -mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 -Wl,--build-id=none -o"hello_world_am64x-evm_r5fss0-0_freertos_gcc-armv7-09.01.out" "./syscfg/ti_dpl_config.o" "./syscfg/ti_drivers_config.o" "./syscfg/ti_drivers_open_close.o" "./syscfg/ti_pinmux_config.o" "./syscfg/ti_power_clock_config.o" "./syscfg/ti_board_config.o" "./syscfg/ti_board_open_close.o" "./syscfg/ti_enet_config.o" "./syscfg/ti_enet_open_close.o" "./syscfg/ti_enet_soc.o" "./syscfg/ti_enet_lwipif.o" "./hello_world.o" "./main.o" -Wl,-T"../linker.cmd" -Wl,-T"syscfg/linker.cmd" -Wl,--start-group -lstdc++ -lgcc -lm -lnosys -l:freertos.am64x.r5f.gcc-armv7.debug.lib -l:drivers.am64x.r5f.gcc-armv7.debug.lib -l:board.am64x.r5f.gcc-armv7.debug.lib -lc -Wl,--end-group
makefile:156: recipe for target 'hello_world_am64x-evm_r5fss0-0_freertos_gcc-armv7-09.01.out' failed
C:/ti/arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.exe:syscfg/linker.cmd:12: syntax error
As you may notice above, the linker is invoked with a linker script -T"../linker.cmd", which translates to syscfg/linker.cmd:
Unfortunately, the content of this file is not for GNU, but for TICLANG:
/* This is the stack that is used by code running within main()
* In case of NORTOS,
* - This means all the code outside of ISR uses this stack
* In case of FreeRTOS
* - This means all the code until vTaskStartScheduler() is called in main()
* uses this stack.
* - After vTaskStartScheduler() each task created in FreeRTOS has its own stack
*/
--stack_size=16384
/* This is the heap size for malloc() API in NORTOS and FreeRTOS
* This is also the heap used by pvPortMalloc in FreeRTOS
*/
--heap_size=32768
-e_vectors /* This is the entry of the application, _vector MUST be placed starting address 0x0 */
/* This is the size of stack when R5 is in IRQ mode
* In NORTOS,
* - Here interrupt nesting is enabled
* - This is the stack used by ISRs registered as type IRQ
* In FreeRTOS,
* - Here interrupt nesting is enabled
* - This is stack that is used initally when a IRQ is received
* - But then the mode is switched to SVC mode and SVC stack is used for all user ISR callbacks
* - Hence in FreeRTOS, IRQ stack size is less and SVC stack size is more
*/
__IRQ_STACK_SIZE = 256;
/* This is the size of stack when R5 is in IRQ mode
* - In both NORTOS and FreeRTOS nesting is disabled for FIQ
*/
__FIQ_STACK_SIZE = 256;
__SVC_STACK_SIZE = 4096; /* This is the size of stack when R5 is in SVC mode */
__ABORT_STACK_SIZE = 256; /* This is the size of stack when R5 is in ABORT mode */
__UNDEFINED_STACK_SIZE = 256; /* This is the size of stack when R5 is in UNDEF mode */
SECTIONS
{
.vectors : {
} > R5F_VECS , palign(8)
GROUP : {
.text.hwi : {
} palign(8)
.text.cache : {
} palign(8)
.text.mpu : {
} palign(8)
.text.boot : {
} palign(8)
.text:abort : {
} palign(8)
} > MSRAM
GROUP : {
.text : {
} palign(8)
.rodata : {
} palign(8)
} > MSRAM
GROUP : {
.data : {
} palign(8)
} > MSRAM
GROUP : {
.bss : {
} palign(8)
RUN_START(__BSS_START)
RUN_END(__BSS_END)
.sysmem : {
} palign(8)
.stack : {
} palign(8)
} > MSRAM
GROUP : {
.irqstack : {
. = . + __IRQ_STACK_SIZE;
} align(8)
RUN_START(__IRQ_STACK_START)
RUN_END(__IRQ_STACK_END)
.fiqstack : {
. = . + __FIQ_STACK_SIZE;
} align(8)
RUN_START(__FIQ_STACK_START)
RUN_END(__FIQ_STACK_END)
.svcstack : {
. = . + __SVC_STACK_SIZE;
} align(8)
RUN_START(__SVC_STACK_START)
RUN_END(__SVC_STACK_END)
.abortstack : {
. = . + __ABORT_STACK_SIZE;
} align(8)
RUN_START(__ABORT_STACK_START)
RUN_END(__ABORT_STACK_END)
.undefinedstack : {
. = . + __UNDEFINED_STACK_SIZE;
} align(8)
RUN_START(__UNDEFINED_STACK_START)
RUN_END(__UNDEFINED_STACK_END)
} > MSRAM
GROUP : {
.ARM.exidx : {
} palign(8)
.init_array : {
} palign(8)
.fini_array : {
} palign(8)
} > MSRAM
.bss.user_shared_mem (NOLOAD) : {
} > USER_SHM_MEM
.bss.log_shared_mem (NOLOAD) : {
} > LOG_SHM_MEM
.bss.ipc_vring_mem (NOLOAD) : {
} > RTOS_NORTOS_IPC_SHM_MEM
.bss.nocache (NOLOAD) : {
} > NON_CACHE_MEM
}
MEMORY
{
R5F_VECS : ORIGIN = 0x0 , LENGTH = 0x40
R5F_TCMA : ORIGIN = 0x40 , LENGTH = 0x7FC0
R5F_TCMB0 : ORIGIN = 0x41010000 , LENGTH = 0x8000
NON_CACHE_MEM : ORIGIN = 0x70060000 , LENGTH = 0x8000
MSRAM : ORIGIN = 0x70080000 , LENGTH = 0x40000
USER_SHM_MEM : ORIGIN = 0x701D0000 , LENGTH = 0x80
LOG_SHM_MEM : ORIGIN = 0x701D0080 , LENGTH = 0x3F80
RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0x701D4000 , LENGTH = 0xC000
FLASH : ORIGIN = 0x60100000 , LENGTH = 0x80000
/* For memory Regions not defined in this core but shared by other cores with the current core */
}
At first I thought, that sysconfig file is per default configured for clang, which is wrong, but it was the case:
Unfortunately, even after changing it to GCC, the problem remains.
Several remarks at the end:
- This behavior is not seen with MCU+ SDK for AM64x v09.00.00.30
- The reason why we want to use GCC is the support of C++ 20/23 in the recent versions
- The above described behavior is also seen under Linux (actually first seen there)
Any advice will be welcome!
Regards,
Angel Gavrailov
