- This topic has 8 replies, 2 voices, and was last updated 1 year, 7 months ago by
.
-
Posts
-
Hey everyone
I just startet to work with VisualGDB and STM and am runing in to a problem where i folow the tutorial to use the STMCubeMX and the VisualGDB Project wizard to generate a new project.
This is the tutorial i use: https://visualgdb.com/tutorials/arm/stm32/cube/advanced/The controller i use is the STM32L011K4T6 on a Nucleo board because they are “biginner” boards and cheap.
Now even with a empty projet, meaning just the generated files from STMCubeMX i can’t compile. I get this error:
Run “C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe ” in directory “C:\Users\s1uty\source\repos\ThisIsATest20230403\ThisIsATest20230403/build/VisualGDB/Debug” on local computer
Note ThisIsATest20230403 section._user_heap_stack' will not fit in regionRAM’
Error ld returned 1 exit statusRun “C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe ” in directory “C:\Users\s1uty\source\repos\ThisIsATest20230403\ThisIsATest20230403/build/VisualGDB/Debug” on local computer
C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
[1/26] Building ASM object CMakeFiles/BSP.dir/Core/Startup/startup_stm32l011k4tx.s.obj
[2/26] Building C object CMakeFiles/BSP.dir/Core/Src/sysmem.c.obj
[3/26] Building C object CMakeFiles/BSP.dir/Core/Src/syscalls.c.obj
[4/26] Building C object CMakeFiles/BSP.dir/Core/Src/main.c.obj
[5/26] Building C object CMakeFiles/BSP.dir/Core/Src/stm32l0xx_hal_msp.c.obj
[6/26] Building C object CMakeFiles/BSP.dir/Core/Src/stm32l0xx_it.c.obj
[7/26] Building C object CMakeFiles/BSP.dir/Core/Src/system_stm32l0xx.c.obj
[8/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal.c.obj
[9/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_cortex.c.obj
[10/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash.c.obj
[11/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_exti.c.obj
[12/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_dma.c.obj
[13/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_gpio.c.obj
[14/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash_ramfunc.c.obj
[15/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash_ex.c.obj
[16/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_i2c_ex.c.obj
[17/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_pwr.c.obj
[18/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_pwr_ex.c.obj
[19/26] Building C object CMakeFiles/ThisIsATest20230403.dir/C_/Program_Files_(x86)/Sysprogs/VisualGDB/CMake/embedded/dummy.c.obj
[20/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_rcc.c.obj
[21/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_rcc_ex.c.obj
[22/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_tim_ex.c.obj
[23/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_tim.c.obj
[24/26] Building C object CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_i2c.c.obj
[25/26] Linking C executable ThisIsATest20230403
FAILED: ThisIsATest20230403
cmd.exe /C “cd . && C:\SysGCC\arm-eabi\bin\arm-none-eabi-gcc.exe -g3 -O0 CMakeFiles/BSP.dir/Core/Src/main.c.obj CMakeFiles/BSP.dir/Core/Src/stm32l0xx_hal_msp.c.obj CMakeFiles/BSP.dir/Core/Src/stm32l0xx_it.c.obj CMakeFiles/BSP.dir/Core/Src/syscalls.c.obj CMakeFiles/BSP.dir/Core/Src/sysmem.c.obj CMakeFiles/BSP.dir/Core/Src/system_stm32l0xx.c.obj CMakeFiles/BSP.dir/Core/Startup/startup_stm32l011k4tx.s.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_cortex.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_dma.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_exti.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash_ex.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_flash_ramfunc.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_gpio.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_i2c.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_i2c_ex.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_pwr.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_pwr_ex.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_rcc.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_rcc_ex.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_tim.c.obj CMakeFiles/BSP.dir/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_tim_ex.c.obj CMakeFiles/ThisIsATest20230403.dir/C_/Program_Files_(x86)/Sysprogs/VisualGDB/CMake/embedded/dummy.c.obj -o ThisIsATest20230403 -“TC:/Users/s1uty/source/repos/ThisIsATest20230403/ThisIsATest20230403/STM32L011K4TX_FLASH.ld” -Wl,-Map=ThisIsATest20230403.map -Wl,-gc-sections -mcpu=cortex-m0plus && cd .”
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: ThisIsATest20230403 section._user_heap_stack' will not fit in regionRAM’
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld.exe: region `RAM’ overflowed by 608 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
————————————————————-
Command exited with code 1
Executable: C:\PROGRA~2\Sysprogs\VISUAL~1/ninja.exe
Arguments:
Directory: C:\Users\s1uty\source\repos\ThisIsATest20230403\ThisIsATest20230403/build/VisualGDB/Debug
Command-line action failed========== Project Rebuild Summary ==========
ThisIsATest20230403 rebuilt in 00:04
========== Rebuild: 0 Succeeded, 1 Failed, 0 Skipped ==========Any ideas on how to fix this?
Hi,
This means that the project you are trying to build does not fit into your device’s RAM. You can try building it for a different device and use Memory Explorer to analyze the memory usage so that you could reduce it.
Hi
Thanks for the answer. What I don’t understand is why a freshly configured projekt with no code from me does not fit. This has to be a error someware and not just a too small controller.Hi,
You can try generating a Makefile with STM32CubeMX and building it manually. If the generated Makefile builds for the same project on the same device without errors, while the VisualGDB-based project doesn’t work, we can help you compare the 2 projects an find what causes the difference. Just make sure you are using the same build type (debug vs. release) in both cases.
I just started coding and thought STM32 and VisualGDB would be a good place to start. I don’t realy know what a Makefile is or what it does. But I can Upload both project to a Google Drive and post a link to it if this would help.
Hi,
VisualGDB could be a good place to start if you are willing to separate VisualGDB-specific issues from the target-specific issues, and investigate the latter type on your own. Makefiles are not specific to VisualGDB, you can find lots of documentation and examples online (even specific to STM32CubeMX), and you will need that knowledge (or more specifically, a good understanding how C++ compilation/linking works and how to troubleshoot common errors) if you are planning to do any non-trivial development.
VisualGDB will save you a lot of time via its code navigation, live debugging features, and convenient GUI for editing various settings, but it’s up to you to take your time, read some online tutorials and understand how these settings work, where different parts of the project come from, and how to troubleshoot the cases where some of these parts don’t work together.
In our experience, users new to embedded development tend to underestimate the complexity of the embedded workflow and often expect VisualGDB support to handle issues that are a part of the normal project development cycle. This never works. Each time we tried to help and investigated them on behalf of our users, they would come back with more, the complexity of the issues would increase exponentially, the deadlines would get tougher, and users would eventually abandon the project, blaming VisualGDB for it.
We do not want our users to go down that spiral. We are happy to support them getting the best productivity out of VisualGDB’s features (in addition to the extensive documentation we have here), however we do expect them to be able to build their code outside VisualGDB and know how to fix issues in it. It doesn’t mean that you will need to do it for every project – VisualGDB provides numerous troubleshooting features (e.g. header discovery), but they rely on the user to have a good idea of the underlying project structure and semantics of various involved tools. And building the project manually (that will involve a lot of googling and trial-and-error) is a good way for a beginner to get familiar with these tools.
If you are not willing to do this, VisualGDB (or any other IDE really) won’t really work for you. Embedded projects often include code from multiple different vendors (even in your most basic STM32CubeMX example) and there are often rough edges that no software tool can fix automatically. For what it’s worth, the project templates included in our STM32 BSP will build out-of-the-box, because we tested them before releasing the BSP, and manually fixed a few minor issues present in the original SDK. If you are importing the code from elsewhere, it’s up to you to make sure it can be built – VisualGDB won’t do it for you.
Hi,
thank you very much for the long anwer. I am aware that the development for embeded devices is very complex and I kow that i need to differntiate betwenn problems from the tool and the user. This is why i am even writing here in the forum.
I thought when I bought VisualGDB that it would work “out of the box”. Maybe this was a wrong assumption from me. I am used to tools from the manufacturer and there this is mostly the case.
How would you recomend we fix this. In the current state of VisualGDB I can’t generate a project for any controller in the STM32L011 famili. If this is something that does not simply work with VisualGDB that is fine by me. But please let me know if this is the case.
I know that I have a lot to learn for embedded development but starting from a broken project is just not a lot of fun. I do this as a hobby not as a job so … yea.
You can use the minimal “Blinking LED” example included with our STM32 BSP by keeping default options everywhere in the Embedded project wizard. It will work out-of-the-box, as long as you replace the GPIO port/pin numbers with the ones relevant to your board.
If you are trying to import code that comes from elsewhere (namely, the STM32CubeMX generator), please don’t blame VisualGDB if that code doesn’t build or work.
- You must be logged in to reply to this topic.