There are a large number of existing STM32 sample projects set up to work with EWARM, MDK-ARM and SW4STM32. Even though use the migration guide for importing projects into STM32CubeIDE most of the time these projects do not import properly.

[ArawataBill]

Are there any instructions on how to import an existing STM example project into STM32CubeIDE such that is can be built and deployed. At the moment its a very frustrating process that wastes lots of time and energy.

[Tesla DeLorean]

I've railed before, many times, about the importance of "also ran" tools getting project import and translation right, and it should be at the top of the priority list.

At the end of the day you get the quality of tools you pay for, and you either value your time over money invested, or value other people's time appropriately. Creating and supporting free tools doesn't pay the bills.

[ArawataBill]

So what do you suggest as an alternative (paid or free)?

[Markus GIRDLAND]

Interesting, this does not reflect our internal testing.

Could you give more details as to what CubeIDE version, FW version and example projects you are trying to import?

Also, only the SW4STM32 or TrueSTUDIO projects can be imported. We don't have any importer for EWARM or MDK-ARM at the moment, so if those are the ones you're trying to import then I can understand that it won't work.

[Tesla DeLorean]

Given that IAR and KEIL are the predominant market players you're trying to lure customers from, they should be top-of-mind and the lowest hanging fruit.

Forum traffic suggests the solution is far too rigid, ie it fails hard when things aren't exactly as wanted, mismatched versions, or things which were bugs that were addressed in subsequent releases. If I were mining the forum I'd look for the Java Exceptions. CubeMX also suffers from inter-version issues where backward-and-forward compatibility are questionable. Hard failure in these cases shouldn't be tolerated, and should be fixed/addressed with minimum data loss. You might have to special case bugs from earlier project generators.

While a 1:1 import is clearly a goal, the ability to infer files constituting the project, command line defines, and include paths to get >=95% of the work done with a check list of items that are unknown or questionable for the user to review/address. I have static analysis tools that walk you through the finding of include paths where the inferences fail, or the project has been placed in a directory that lacks the placement context of the original.

[ArawataBil]

Here is just one example. Yesterday was watching the online ST LPWAN workshop (https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/lora-workshop.html). As this is an offical tutorial workshop the expectation is that all the samples are well tested and work. The tutor was going through the AT_slave example. So I download I-CUBE-LRWAN from https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html. The instructions in the migration guide (https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/7c/55/d0/7d/19/68/49/10/DM00613836/files/DM00613836.pdf/jcr:content/translations/en.DM00613836.pdf) are to put a copy of the project in the workspace and then from STMCubeIDE to open the project from the file system and to navigate to location of the project. I assume this means to navigate to the SW4STM32 folder. After importing attempt to build the project and get build errors indicating that include files are missing. Similar issues with the other projects End_Node and PingPong. This happens with so many sample projects. I am making the assumption that these projects worked and could be compiled successfully and that something has gone wrong in the import process.

Also say one selects the wrong folder by mistake (eg select AT_Slave parent folder instead of SW4STM32 sub-folder) and imports a project. Then if delete the faulty import including the disk copy cannot re-import the project as get an error message that a project with the same name has already been imported even though the previous import has been deleted.

The version of STM32CubeIDE is 1.1.0.

[Markus GIRDLAND]

I think I know what the confusion is about. The migration guide talks about making a copy of the project and placing it in the workspace of STM32CubeIDE because that manual assumes the project is self-contained. I should probably make a new revision of that document to specify that more clearly.

In the case of example projects from FW packages it's a different story. Those packages make references to files outside the scope of the project you imported but still inside of the FW package. This means that you will need to import "Projects from File System or Archive" and specify the project you wish to import. For example:

C:\Users\UserName\STM32Cube\Repository\STM32CubeExpansion_LRWAN_V1.3.0\Projects\STM32L073RZ-Nucleo\Applications\LoRa\PingPong\SW4STM32\sx1272mb2das

Because STM32CubeIDE will modify some SW4STM32 files when doing the importation you might want to save a copy of that entire FW package if you want to use it with SW4STM32 at a later time.

I tried it just now and it builds without errors. Let me know if doing it this way helped you build it.

[ArawataBill]

Anyway, thanks for your help.

[ArawataBill]

Fantastic! Works this time.

The problem was that I was just copying the actual project, eg PingPong, rather than the whole package. Ironically, if I had not followed the instructions then it would have worked, but because I did follow the instructions I ended up having all sorts of compile errors. So yes, it would be very helpful to outline in the instruction guide that importing sample projects are to be treated differently from self contained projects, otherwise other users will end up have the same issue I had.