2016-03-29 10:33 AM
Hi,
I'm trying to build an ''empty'' project generated by CubeMX using FreeRTOS and gcc for STM32F103xB. I'm using the latest CubeMX (4.14.0) and latest HAL (1.3.1). I've successfully built projects using CubeMX, HAL, gcc that work, I just get errors when I'm trying to use FreeRTOS. I've added to the include path (-I) FreeRTOS/Source/CMSIS_RTOS FreeRTOS/Source/include FreeRTOS/Source/porteble/GCC/ARM_CM3 I've included in the build: FreeRTOS/ FreeRTOS/Source FreeRTOS/Source/CMSIS_RTOS FreeRTOS/Source/portable/GCC/ARM_CM3 FreeRTOS/Source/portable/MemMang/heap_4.c + all the other stuff needed to make a CubeMX/HAL project works. but I get undefined reference to `pxCurrentTCB' port.c undefined reference to `vTaskSwitchContext' port.c BTW if anyone from ST is listening it would be nice if you didn't include in the main.c template the cmsis_rtos stuff so one would be free to chose to use FreeRTOS directly or not without having to edit main.c every time. #stm32f1 #cubemx #freertos #gcc2016-03-30 08:13 AM
Hi borgonovo.ivan_sergi,
?You don?t need to add the freeRTOS manually, you can enable it through MX :as in the figure bellow?I recommend you to have a look to thehttp://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00105262.pdf
User manual about developing applications on STM32Cube with RTOS.-Syrine-2016-04-05 06:34 AM
Hi and thanks for the reply,
I'm using Eclipse + ARM plugin not the SW4STM32 IDE. I'm using make managed build in Eclipse. The problem seems to be at linking stage. This compile successfully: arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -fno-move-loop-invariants -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wpadded -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -g3 -D__weak=''__attribute__((weak))'' -D__packed=''__attribute__((__packed__))'' -DUSE_HAL_DRIVER -DSTM32F103xB -DARM_MATH_CM3 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/STM3210E_EVAL -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Adafruit_Shield -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/STM32F1xx_Nucleo -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/STM3210C_EVAL -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/STM32VL-Discovery -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/Common -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/stlm75 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/ak4343 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/st7735 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/lis302dl -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/spfd5408 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/ili9325 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/hx8347d -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/cs43l22 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/ili9320 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/BSP/Components/stmpe811 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/STM32F1xx_HAL_Driver/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Drivers/CMSIS/Include -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Utilities/Log -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Utilities/Fonts -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Utilities/CPU -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/FreeRTOS/Source/include -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3 -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/FatFs/src -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/FatFs/src/drivers -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/test/unit -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/test/unit/tcp -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/test/unit/etharp -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/test/unit/core -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/test/unit/udp -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/system/arch -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/system/noOS -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/system/OS -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/netif/ppp -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/ipv4/lwip -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/netif -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/posix -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/posix/sys -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/ipv6/lwip -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/Third_Party/LwIP/src/include/lwip -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/Template/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/MSC/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/HID/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/DFU/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/CustomHID/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Class/AUDIO/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/Template/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/HID/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/CDC/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/MTP/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Class/AUDIO/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STemWin/Config -I/usr/local/src/STM32Cube_FW_F1_V1.3.0/Middlewares/ST/STemWin/inc -I''/home/ivan/Documents/workspace/stm32f1/STCube/Inc'' -std=gnu11 -Wmissing-prototypes -Wstrict-prototypes -Wbad-function-cast -MMD -MP -MF''STCube/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.d'' -MT''STCube/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.o'' -c -o ''STCube/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.o'' ''../STCube/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c'' but at linking stage I get: undefined reference to pxCurrentTCB undefined reference to vTaskSwitchContext Curiously a) none of those symbol are included in any header rather they are defined in tasks.c b) they are referenced in port.c in inline asm Maybe this is confusing Eclipse make managed build. I'm going to investigate. Automatic tools have pros and cons. One of the cons is you've to figure out what they actually did. I'll install SW4STM32 to just see how it is configured to try to replicate the setup on ''plain'' Eclipse but I'd be glad if anyone can spot the problem before I start this adventure. I already read UM1722 but unfortunately it is not going to help with this issue. I'm going to reiterate my suggestion. It would be nice if the CubeMX main.c wouldn't depend on cmsis_rtos or at least in a way that could be overridden. /me going to check if I can have automatic notification by email from the forum. thanks again2016-04-05 07:15 AM
Hi borgonovo.ivan_sergi,
1.I do the test with SW4STM32 and I don’t face any issue 2.Me going to check if I can have automatic notification by email from the forum: go to Actions > Alert Me -Syrine-2016-04-05 07:44 AM
Hi,
that's exactly the point, I'm not using SW4STM32 but ''plain'' Eclipse + the more generic ARM eclipse plugin. I did try to use the ''internal'' builder in spite of make managed build but I get the same errors at link time. At least now I noticed it is a link issue and not a compile time issue. Still a bit puzzled since all the sources are there, all the (-I) include are specified, all the modules get compiled, there is no change in the HAL + FW code still Eclipse can't link the files. Finding some clue in the compilation log + symbols in the generated objects will take me some time before I can come up with some interesting news. Thank you for moral support. Now that I've a vague idea about where to look for the problem I hope to get beck with a solution or at least with some really helpful clue. Would you be so kind to post a successful compile log of an ''empty'' CubeMX/FreeRTOS project somewhere so I could spot the differences? thanks Hi borgonovo.ivan_sergi, 1.I do the test with SW4STM32 and I don’t face any issue 2.Me going to check if I can have automatic notification by email from the forum: go to Actions > Alert Me -Syrine-2016-04-06 04:02 AM
> Still a bit puzzled since all the sources are there, all the (-I) include are specified, all the modules get compiled, there is no change in the HAL + FW code still Eclipse can't link the files.
Obviously some source is missing - if I remember correctly, those ''missing references'' are data structures of FreeRTOS. If the respective source file is actually included in the build (as stated above), perhaps the definition of those items is enclosed in
#ifdef
s, and drop out because of a missing#define
.2016-04-06 01:42 PM
I don't have that much linking FU, pardon my naiveness.
To recap: pxCurrentTCB (a ptr to a struct) and vTaskSwitchContext (a function) are defined in tasks.c (and not declared anywhere else, there is no header declaring them) and they are used in port.c in inline asm. tasks.c is part of the ''common'' code of FreeRTOS, port.c is a specialization for Cortex-m3 CPU. The correct port.c get compiled (GCC/ARM_CM3). let alone pxCurrentTCB, tasks.o get compiled and: $ arm-none-eabi-objdump -t tasks.o | grep vTaskSwitchContext 00000000 l d .gnu.lto_vTaskSwitchContext.e526ddf3dbf0a904 00000000 .gnu.lto_vTaskSwitchContext.e526ddf3dbf0a904 So I assume the symbol vTaskSwitchContext should be available at linking time. Looking at the build log, linker output: LOAD ./STCube/Middlewares/Third_Party/FreeRTOS/Source/tasks.o ... /tmp/ccXrr7NF.ltrans0.ltrans.o: In function `PendSV_Handler': ./ldscripts/startup_stm32f103xb.o /home/ivan/Documents/workspace/stm32f1/Debug/../STCube/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c:444: undefined reference to `vTaskSwitchContext' TIM3_IRQHandler /tmp/ccXrr7NF.ltrans0.ltrans.o ... vTaskSwitchContext ./STCube/Middlewares/Third_Party/FreeRTOS/Source/tasks.o (symbol from plugin) /tmp/ccXrr7NF.ltrans0.ltrans.o So somehow the symbol is there, tasks.o get loaded by the linker, but seems to be ignored. PendSV_Handler is actually ./STCube/Inc/FreeRTOSConfig.h:#define xPortPendSVHandler PendSV_Handler2016-04-06 10:36 PM
You might have a kind of circular reference here.
I would try the --start-group...--end-group linker options, e.g. described . This tells the linker to search the named archives/objects multiple times, until all references are resolved. Say, something like --start-grouptasks.o--end-group.2016-04-10 09:44 AM
Hi,
thanks for pointing me to something that may help to solve or at least understand the problem, but it didn't help. Adding tasks.o and/or port.o to the group just adds several ''multiple definition of ...'' errors. If people have been able to compile FreeRTOS with HAL in SW4STM32 IDE, that should be substantially Eclipse + a dfferent set of plugins than ARM Eclipse plugin, there should be something simpler in the Eclipse settings or ''code setup'' to solve the problem. But I'm still missing it. CubeMX substantially generate a .cproject and .project file for Eclipse. Source code is the same as in the ST framework. I've added all the include -I related to FreeRTOS as the one generated by CubeMX in my project. Even the -D define are the same. I'll install SW4STM32 IDE and see if I can actually get a successful build for STM32F1. Then I'll see if I can get rid of all the CubeMX FreeRTOS related things and just use CubeMX for HW initialization, add an upstream copy of FreeRTOS and get a successful build. But this just out of desperation since if people have been able to successfully compile a CubeMX generated project with FreeRTOS for STM32F1 it should be just a matter of some Eclipse setup I'm missing.2016-04-11 11:35 AM
[SOLVED]
the difference seems to be in the -flto option. Skipping that option now I got it compiling. thanks