Sysprogs forums › Forums › VisualGDB › Importing a CubeIDE project
- This topic has 2 replies, 2 voices, and was last updated 1 year, 5 months ago by GeneM.
-
AuthorPosts
-
July 4, 2023 at 13:53 #34416GeneMParticipant
I’m making progress figuring out a way that works for me to import a CubeIDE project into VGDB. The goal is to create a skeleton project in CubeIDE that generates the startup and peripheral initialization code in order to make sure the basic functionality works but use all the nice features of VGDB to do the majority of the coding. So far, I have a STM32H7A3 skeleton project that builds and runs in CubeIDE. I’ve imported it into a VGDB project using the “Import an existing STM32CubeIDE .. Project” option. The VGDB program builds and runs as well but I have 2 questions:
Q1) The CubeIDE skeleton project uses USART1 with DMA and the character match interrupt. After I’ve imported the project into VGDB, I set a breakpoint in the character match callback. I can build and debug the program in VGDB but in between the time I start the program and the time it hits the breakpoint in the character match callback, I get the attached GDB timeout window popping up. To be clear, the VGDB program still runs and hits the breakpoint in my character match callback but is there something I can do to eliminate the GDB Timeout window popping up?
Q2) I’m trying to separate my new VGDB project from the original CubeIDE project so that regenerating code in CubeIDE won’t affect the code in my VGDB project. However, it looks like the VGDB project is referencing all the files in the CubeIDE project. I’m trying to get up to speed with CMake and it looks like what files get built are defined in the CMakeLists.txt file. I’ve copied the first part of that file below but it looks like the path to what files are being built is defined by
{CPFver5_vgdb_LOCATION}
I’ve been trying to find where this is defined but the only place I can find it is in this line in the CMackCache.txt file
CPFver5_vgdb_LOCATION:PATH=C:/Users/gene/Documents/CPF/Software/CPFsom2023Jun11/CPFver5
but changing it there doesn’t affect the build.
My question is, can I copy all the files I need from the CubeIDE project into my my new VGDB project folder and change the files that get built in my new VGDB project by redefining
{CPFver5_vgdb_LOCATION}
and if so, how do I change it to point at the files in my new VGDB project. Or do I have to manually add the full path to every file in the CMakeLists.txt file?Thanks
cmake_minimum_required(VERSION 3.15)
project(CPFver5_vgdb LANGUAGES C CXX ASM)
find_bsp(
ID com.sysprogs.arm.stm32
VERSION 2022.08
MCU STM32H7A3ZITxQ
CONFIGURATION com.sysprogs.mcuoptions.ignore_startup_file=1
HWREGISTER_LIST_FILE STM32H7xxxx/DeviceDefinitions/stm32h7a3xxq.xml
DISABLE_GNU_EXTENSIONS)
register_imported_project(NAME CPFver5_vgdb
PATH ../CPFver5/.cproject
LEVEL 0)
add_bsp_based_executable(
NAME CPFver5_vgdb
LINKER_SCRIPT ${CPFver5_vgdb_LOCATION}/STM32H7A3ZITXQ_FLASH.ld
SOURCES
${CPFver5_vgdb_LOCATION}/Core/Inc/main.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32h7xx_hal_conf.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32h7xx_it.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32_assert.h
${CPFver5_vgdb_LOCATION}/Core/Inc/main.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32h7xx_hal_conf.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32h7xx_it.h
${CPFver5_vgdb_LOCATION}/Core/Inc/stm32_assert.h
${CPFver5_vgdb_LOCATION}/Core/Src/main.cpp
${CPFver5_vgdb_LOCATION}/Core/Src/stm32h7xx_hal_msp.c
${CPFver5_vgdb_LOCATION}/Core/Src/stm32h7xx_it.c
${CPFver5_vgdb_LOCATION}/Core/Src/syscalls.c
${CPFver5_vgdb_LOCATION}/Core/Src/sysmem.c
- This topic was modified 1 year, 5 months ago by GeneM.
Attachments:
You must be logged in to view attached files.July 8, 2023 at 14:07 #34437supportKeymasterHi,
No problem, please find the answers below:
- The delays caused by -stack-list-frames and known workarounds are described on this page. You can also open it by clicking “read more about unresponsive GDB commands” link in the timeout window shown on the screenshot.
- The
CPFver5_vgdb_LOCATION
variable is set automatically based on the PATH argument passed to register_imported_project(). If you would like to update the relative path to the imported project, please consider editing the statement accordingly.
Also, the easiest way to make the imported project reusable is to create the initial VisualGDB project already in the imported project directory. You can do it using the checkboxes shown below:
Attachments:
You must be logged in to view attached files.July 9, 2023 at 17:10 #34442GeneMParticipantThank you, that’s what I need to move forward. If you’re interested, my goal with importing the CubeIDE project is to have a new project with copies of all the files in the original CubeIDE project. That way I can rearrange the files and subroutines in a way that makes sense to me. For example, I really don’t like the way CubeIDE puts all the critical DMA, UART, I2C and associated IRQ Handlers in various STM32XXX files. I’d rather have them with the peripheral they’re associated with. And I’d like to put the various peripheral initializations functions in other files also. This way when I do have to regenerate the CubeIDE project, it won’t affect my VGDB project. I’ll just copy and paste the new CubeIDE code into the VDGB project. If this makes sense, it might make be worth having a check box option when import an existing project that is something like “Duplicate existing project in new folder”
-
AuthorPosts
- You must be logged in to reply to this topic.