Sysprogs forums › Forums › VisualGDB › Importing STM32CubeMX LL project
- This topic has 20 replies, 4 voices, and was last updated 5 years, 9 months ago by support.
-
AuthorPosts
-
December 11, 2017 at 18:08 #13239parsec67Participant
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 by
Debug/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?
December 12, 2017 at 06:43 #13241supportKeymasterHi,
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.
December 12, 2017 at 09:47 #13244parsec67ParticipantHi,
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.
December 12, 2017 at 10:53 #13248parsec67ParticipantIn 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.
December 12, 2017 at 21:59 #13255supportKeymasterHi,
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.
December 13, 2017 at 08:35 #13262parsec67ParticipantHi,
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.December 13, 2017 at 18:04 #13271supportKeymasterHi,
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.
December 14, 2017 at 19:06 #13287parsec67ParticipantHi,
I have reported it, will update this thread with any news from ST.
March 5, 2019 at 01:04 #24073SebastianParticipantHi 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
March 5, 2019 at 07:06 #24075kurta999ParticipantHAL 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.
March 5, 2019 at 08:33 #24078parsec67ParticipantYou 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.
March 5, 2019 at 15:21 #24083SebastianParticipantKurta, 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
March 5, 2019 at 18:09 #24091supportKeymasterThe 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.March 5, 2019 at 18:43 #24093SebastianParticipantDear 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.March 5, 2019 at 18:48 #24095 -
AuthorPosts
- You must be logged in to reply to this topic.