Split: Problems with STM32CubeMX and VisualGDB

Sysprogs forums Forums VisualGDB Split: Problems with STM32CubeMX and VisualGDB

This topic contains 7 replies, has 2 voices, and was last updated by  support 6 days, 19 hours ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #30454

    Dols
    Participant

    Hello,

    I have a ST Nucleo F439 board with some added hardware. I’m trying to generate complete fresh new project for it using the STM32CubeMX Project Wizard. I’m following these intructions, https://visualgdb.com/tutorials/arm/stm32/cube/advanced Only thing i’m doing different is in the CubeMX i select the Nucleo F439 board. At first glance everything looks it’s working. But cannot correctly open the project/solution. It is missing files.

    Diving into this I noticed all the “Core/Src/*.c” files are missing, it should have e.g. “main.c” and several “stm*.c” files, althoug the “Core/Inc/*.h” files are all there. I also noticed midway the process these files are actual generated, but deleted again at the end of the process.

    What am i doing wrong?

    Notes:

    I tried with Embedded Project Wizard. This actual works.

     

    Development System:

    VS2019 Professional

    VisualGDB (V5.5 trial also tried with beta of 5.6)

    STM32CubeMX v 6.2.1

    #30457

    support
    Keymaster

    Hi,

    It could be a bug in the STM32CubeMX tool. Please try running it manually, creating a new project, and generating a .gpdsc file for it. Does the generated file reference all the relevant sources? Are they physically present?

    #30460

    Dols
    Participant

    The gpdsc file look ok. The STM32CubeMX tool is generating the c files, both manually also when visualGDB is regenerating and starts the STM32CubeMX tool. But after STM32CubeMX tools closes, VisualGDB deletes these files.

    #30466

    support
    Keymaster

    Strange. VisualGDB does not delete any of the source files as a part of the importing process. Most likely, something else is going on.

    Please share the complete steps we could follow on our side to reproduce the problem, including the screenshots of all relevant settings, and we will recheck what could be causing it.

    #30469

    Dols
    Participant

    Steps below to reproduce.

    • Start VS2019
    • Create New Project
    • Double click on STM32CubeMX Project Wizard
    • Giving the project a name and location.
    • Place solution and project in the same directory = checked
    • Press Create
    • Toolchain = “ARM in c:\SysGCC\arm-eabi” (already selected)
    • Select “STM32F439ZITx”
    • STM32CubeMX tool is launched
    • Click on the “STM32F439ZITx” in the crumb bar
    • Select “Board Selector” tab
    • Double click on “NUCLEO-F439ZI” board
    • Initialize all peripherals with there default mode ? = Yes
    • Ctrl-S to save the IOC File (overwrite the old file)
    • Close the SMT32CubeMX Project (don’t generate code, didn’t change any other settings)
    • Regenerating is started. Automatically starts the STM32CubeMX again.
    • All files are generated including the “main.c”
    • STM32CubeMX closes again automatically
    • Getting the “New STM32CubeMX Project” dialog again, now on tab “Debug Method”.
    • The “main.c” file is gone.

    #30470

    Dols
    Participant

    Actually the whole “core/src” folder is gone.

    I tried to generate the project from within the STM32CubeMX tool, commit in git. And afterwards restore these files. But still having some errors when compiling. I Suspect i’m missing some changes in the files or settings.

    Also note i’m new to VisualGDB and STM32CubeMX. So it could be very well a rookie mistake i’m doing.

    #30471

    Dols
    Participant

    I think I found the problem, it’s indeed the STM32CubeMX.

    Project Manager > Code Generator > Generated files > Delete previously generated files when not re-generated = OFF (this is Enabled by default at my system)

    Don’t know why this is enabled by default. Seems silly to me.

    #30472

    support
    Keymaster

    Hi,

    Thanks for pointing this out. We have reproduced the problem.

    Turns out, when you select a different board in the STM32CubeMX, it re-creates the .ioc file from a different template, overriding the default source directory:

    Later on, VisualGDB asks STM32CubeMX to first generate a Makefile-based project, and then a GPDSC-based project:

    Apparently, if the source directory is overridden, STM32CubeMX will delete the Src folder during the second project generation.

    You can work around it by commenting out the ProjectManager.MainLocation line in the .ioc file and regenerating the project once again via the context menu on STM32CubeMX Files the in Solution Explorer.

    We will also add a warning about this to the next VisualGDB release.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.