Sysprogs forums › Forums › VisualGDB › STM32CubeIDE import question.
Tagged: STM32CubeIDE
- This topic has 7 replies, 2 voices, and was last updated 4 years, 5 months ago by support.
-
AuthorPosts
-
May 31, 2020 at 11:03 #28279parsec67Participant
Hi,
VisualGDB 5.5 preview 5 build 3595 running on VS2019.
I’m trying to use the import feature for an existing STM32CubeIDE project, Move and Rename options deselected. STM32CubeIDE version is 1.3.1. The import process goes through all the motions, gets MCU type right but no project source files or folders are actually copied. There are no errors reported as far as I can see.
Is this feature only available for specific project types or not fully implemented yet in the preview release?
I’m not a fan of Eclipse and will import manually to VGDB/VS2019 if needed. That said, STM32CubeIDE is a useful tool for initial pin and peripherals configuration as well as basic function tests so having a direct import option available would be really nice.
May 31, 2020 at 17:48 #28283supportKeymasterHi,
Most likely, this happens because the project is referencing entire source directories instead of specific files, and we have not fully tested this case yet.
Please try this build: VisualGDB-5.5.6.3661.msi. It should be able to handle the directory-level references correctly.
June 1, 2020 at 06:35 #28286parsec67ParticipantHi,
Still hit a few snags:
1. CubeIDE project has a startup assembler code ‘startup_stm32f415rgtx.s’ which clashes with VGDB default startup C file:
C:/Users/..../VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F4xxxx/StartupFiles/startup_stm32f415xx.c:955: multiple definition of `Default_Handler';</code>
Excluding startup_stm32f415rgtx.s from the project fixed this issue.
2. Existing CubeIDE linker script was not imported, instead the project defaulted to VisualGDB's linker script. This caused a linker error:
<code>ld.exe: C:\dev\stm32\VisualGDB\bootmx/../../CubeIDE/Core/Src/main.c:178: undefined reference to `_app_start'
Also it appears the source hyperlink in the error message evaluates incorrectly. Clicking on it caused an exception:
VisualGDB version: 5.5.6.3661 ------------------ vz1 ------------------ vz1: Failed to open 'c:\sysgcc\arm-eabi\arm-none-eabi\CubeIDE\Core\Src\main.c:178'. ---> System.ArgumentNullException: Value cannot be null. Parameter name: textBuffer at Microsoft.Requires.NotNull[T](T value, String parameterName) at ....
Creating a local copy of the linker script and modifyng it to match the original fixed this issue.
3. A few header files were not added to imported project subfolders (filters) where they were supposed to be. Notable here is that the CubeIDE project has .c and .h files bundled in some folders. For instance, FATFS\Target contains ffconf.h, user_diskio.h and user_diskio.c. VGDB splits FATFS\Target into two instances in Solution explorer, ‘Header files’ and ‘Source files’, but only imports user_diskio.c to ‘Source files\FATFS\Target’
4. One entire project subfolder was not imported (but was listed under Include directories):
Middlewares\Third_Party\FatFs\src
This caused a couple of undefined reference linker errors. After I added it manually in Solution Explorer the project finally built with no errors.
5. I am unable to start a debug session. The solution is not recognized as a VisualGDB project and I only have option Debug->x86 in the VS navigation bar. The project properties shows platform as VisualGDB. Right-clicking on project in Solution explorer and selecting “Debug->Start new session” gives me an error dialog: “Unable to start debugging. Check your debugger settings…”. Settings are good (ST-Link V2) and identical to what I use for other projects.
Since it may be difficult to follow exactly what is going on based on my explanations only I’d be happy to send you the entire CubeIDE project if you want to try to replicate on your end.
June 1, 2020 at 06:42 #28289parsec67ParticipantPS. Sorry for formatting issues but this editor really blows and I was unable to edit more than twice.
June 1, 2020 at 10:21 #28296parsec67ParticipantUpdate: Scratch my point #5, I got it to debug when importing as MSBuild. On my first attempt with VGDB build 5.5.6.3661 I accidentally had GNU Make set when importing.
The other 4 points remain and I was able to get the project in working condition by following and fixing each step as outlined above.
June 5, 2020 at 02:24 #28340supportKeymasterNo problem, please try this build: VisualGDB-5.5.7.3671.msi. It resolves the issue with the linker script and startup files.
In order to fix the problem with include directories and the FatFs folder, we would need to examine your project file (.cproject and .project) and also see the list of all source files in the project directory (obtained by running dir /s /b > list.txt). You can post it here, or send it to our support form.
If the project structure is confidential, you can also simply build our STM32CubeIDE project importer from source and adjust it on your side.
June 11, 2020 at 07:43 #28377parsec67ParticipantHi,
Linker script and startup files appears okay now.
I have uploaded the problematic CubeIDE test project here: https://filebin.net/wjpfj52dull5gmcr
Thanks
June 11, 2020 at 19:28 #28382supportKeymasterThanks, we have updated VisualGDB to handle it correctly: VisualGDB-5.5.7.3679.msi
-
AuthorPosts
- You must be logged in to reply to this topic.