Importing STM32CubeMX LL project

Sysprogs forums Forums VisualGDB Importing STM32CubeMX LL project

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
    Posts
  • #13239
    parsec67
    Participant

    Since CubeMX can now generate pure LL projects, is there a way to import such a project into VisualGDB? I tried following the “Using STM32CubeMX Startup Code Generator with VisualGDB” tutorial but failed miserably. While the project superficially appears to be imported correctly it fails to build with:

    1>make: *** No rule to make target Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c', needed byDebug/stm32f4xx_hal.o'.  Stop.
    
    

    Is it at all possible to import LL projects automatically? If not, are there other recommended methods to get an LL project to build?

    #13241
    support
    Keymaster

    Hi,

    We haven’t tested VisualGDB with LL projects yet, however this looks like the GPDSC file references some sources that were not copied by the STM32CubeMX tool. You could check this by examining the gpdsc file (or we could check this for you if you could attach the screenshots of your STM32CubeMX settings). If it appears that STM32CubeMX indeed doesn’t copy the files, please file a bug report with ST. If the files are copied to a different location or a named differently, please let us know and we will add a workaround.

    #13244
    parsec67
    Participant

    Hi,

    Your answer gave me a valuable clue to get it to work; In CubeMX->Project->Settings->Code generator tab there is an option “Copy all used libraries into the project folder” which must be selected. Previously I had not used the VGDB CubeMX importer and only copied necessary library files when generating code, which I think is also the default setting.

    After changing this option, generating the code and then importing into VisualGDB as per tutorial it almost worked. One additional step was necessary and that was to define USE_FULL_LL_DRIVER in VisualGDB Makefile settings/Pre-processor macros, otherwise the build will fail due to unknown type names.

    After doing the above I can now build, run and debug LL projects. My blinky test project is blinking much more efficiently than with HAL 🙂

    I’m still not sure why it wouldn’t work before but looking in the gpdsc file I found one reference to HAL drivers:

    <component Cclass="Device" Cgroup="STM32Cube HAL" Csub="COMMON" Cversion="1.3.2">
          <description>CubeMX Generated HAL COMMON</description>
          <files>
            <file category="header" name="Drivers\STM32F4xx_HAL_Driver\Inc\stm32f4xx_hal.h"/>
            <file category="sourceC" name="Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal.c"/>
          </files>
        </component>

    Both files are referenced in the imported project in VS Project explorer but not copied/cannot be opened (Error “Could not find file…”). So I guess the answer is to make sure that “Copy all used libraries into the project folder” is selected when generating code in CubeMX.

    #13248
    parsec67
    Participant

    In regard to my project that was generated with “Copy only the necessary library files” and failed to build;

    After some additional digging I’ve found that adding the two files stm32f4xx_hal.h/.c manually to the project from the Cube repository, and also adding the repository Drivers include path to the VGDB Include directories, the project will build successfully.

    So it is possible to use “Copy only the necessary library files” option in CubeMX after all, only that a couple of extra steps (add the missing files + repo path) are required to get it to build.

    I’m not sure if these missing HAL files are not copied by CubeMX due to a bug or by design but the important thing is that both ways I’ve tried turned out to work after sorting out the quirks.

    #13255
    support
    Keymaster

    Hi,

    If the files are referenced by the gpdsc file, it could be our bug. Please feel free to attach the generated gpdsc file (and files copied by STM32CubeMX) and we could quickly investigate whether this is something we could fix.

    #13262
    parsec67
    Participant

    Hi,

    Attached zip file contains the gpdsc file and the files copied by CubeMX. This is the project using “Copy only the necessary library files” option for code generation.

    I just now noticed there is one additional file that is referenced but not copied (stm32f4xx_ll_dmamux.h) and will obviously also fail to open in VS after project has been imported by VGDB. Firstly it is odd that it is referenced in gpdsc at all because no other project source file is including this file. Secondly,  stm32f4xx_ll_dmamux.h doesn’t even exist in Cube repository so there is nowhere to copy it from. This all sounds like a bug in CubeMX.

    Attachments:
    You must be logged in to view attached files.
    #13271
    support
    Keymaster

    Hi,

    Thanks for the attached file. It does look like STM32CubeMX references a file that is not copied (and not actually needed, as removing it from the .vcxproj file fixed the problem). It also doesn’t mention the USE_FULL_LL_DRIVER macro anywhere in the gpdsc file. This could be a bug worth reporting to ST and if it’s not fixed in one of the next STM32CubeMX updates, we will consider adding logic for detecting this and automatically adding the macro and skipping the missing file.

    #13287
    parsec67
    Participant

    Hi,

    I have reported it, will update this thread with any news from ST.

    #24073
    Sebastian
    Participant

    Hi Parsec67

    You have news about this issue, now I try use USART with LL driver but I have many error, I m wrote to ST but I haven’t any reply

    #24075
    kurta999
    Participant

    HAL is crap, it’s just for beginners. We are used it for commercial modules, but now I’m planning to move everything to low layer & raw register access. Anyway Congratulations for Visual GDB, I’m now trying to push my boss to buy a license (It’s a big plus that it works with ESP too) and throw out Atollic.  It’s a messy nonsense IDE. They fix a bug, creates two new.

     

    “This could be a bug worth reporting to ST and if it’s not fixed in one of the next STM32CubeMX updates, we will consider adding logic for detecting this and automatically adding the macro and skipping the missing file.”

     

    Good luck with that 😀 If VisualGDB staff can afford it, then please fix this because interest is here.

    • This reply was modified 5 years ago by kurta999.
    • This reply was modified 5 years ago by kurta999.
    #24078
    parsec67
    Participant

    You have news about this issue, now I try use USART with LL driver but I have many error, I m wrote to ST but I haven’t any reply

    I reported this back in December 2017 (https://bit.ly/2C56WG9). Rather quickly, only 11 months later in November 2018, an ST  employee replied that they would fix this issue in a future CubeMX update. I have not heard anything since so I’m guessing it is not a priority. Given the pace of things I think we can expect a fix in July 2021.

    HAL is crap, it’s just for beginners.

    HAL is what is states to be, hardware abstraction, and it does this job fairly well. I have effortlessly migrated portions of code between F0, F4 and F7 products which would not have been nearly as easy with code based on direct register manipulation. LL kind of improves on full manual low level coding but I found it poorly documented in some cases and it felt less mature at the time. Maybe things have changed now.

    #24083
    Sebastian
    Participant

    Kurta, parsec67, thanks for your reply

    I am trying to use USART with LL driver but I have the same problem I am not an expert yet so I do not know how to insert the reference (USE_FULL_LL_DRIVER) to use my project they tell me that I have to put it in the preprocessor, you have some example of how do this, or perhaps seeing these errors our friends of SYSPROGS can make us a manual because their support is needed for this case

     

    thanks

    #24091
    support
    Keymaster

    The USE_FULL_LL_DRIVER is just a regular preprocessor macro, so you can easily set it via the regular build settings as shown below:

    Regarding the automatic fix, if anyone could share the exact up-to-date repro steps for the issue and point out which files or flags need to be included, we should be able to add a workaround on our side in 1-2 business days. Otherwise, it will go into a lower priority queue, since it involves issues in 3rd-party components and we currently working on a few improvements to VisualGDB itself (specifically, stable VS2019 support and eliminating delays during VS startup).

    Attachments:
    You must be logged in to view attached files.
    #24093
    Sebastian
    Participant

    Dear Support

    Now I can compile the code but I have some error, <span class=”tlid-translation translation”><span class=”” title=””>maybe forget to include something</span></span>

    thanks

    Attachments:
    You must be logged in to view attached files.
    #24095
    Sebastian
    Participant

    I m forget include the error message when the VS start and log.xml file

    thanks for the help

    Attachments:
    You must be logged in to view attached files.
Viewing 15 posts - 1 through 15 (of 21 total)
  • You must be logged in to reply to this topic.