Skip to main content
DCyr
Associate III
October 3, 2019
Question

Errors compiling with STMCubeIDE likely because module libraries aren't included. How do you include missing libraries? Or could it be something else?

  • October 3, 2019
  • 33 replies
  • 14802 views

We generate the firmware code using the Motor Control Workbench that calls the STMCubeMX that then calls the STMCubeIDE. We were able to successfully compile the firmware this way using the IAR IDE, but we get many compiler errors with the STMCubeIDE. An example of the errors is:

../Drivers/STM32F3xx_HAL_Driver/Src/stm32f3xx_hal_timebase_rtc_alarm_template.c:98:1: error: unknown type name 'RTC_HandleTypeDef'; did you mean 'I2C_HandleTypeDef' RTC_HandleTypeDef    hRTC_Handle;

This topic has been closed for replies.

33 replies

ben5en
Associate II
October 12, 2019

Good Morning,

I have the same problem, is there no official answer? If you look at the response rate and the number of answers in the other topics, Motor Control Support seems rather sparse. I also asked a question here on 24.09.19 and so far have not received an answer. What a shame.

DCyr
DCyrAuthor
Associate III
October 12, 2019

I got it to compile by using the series of steps below that includes setting the "Target toolchain" to ST TrueSTUDIO, not STMCubeIDE, however, STMCubeIDE is still invoked and flashes the firmware. The missing modules seem to have been included with this change. Is this how you are compiling?

There were still 2 errors related to converting the "name.ELF" object module to "name.HEX". See below how to fix these 2 remaining errors.

Target Toolchain with STMCubeIDE doesn't work, but ST TrueSTUDIO works (with a couple of build errors - see below) 

"Open Project" intitates STMCubeIDE

THERE ARE 23 WARNINGS LIKE THIS:

warning: comparison between pointer and zero character constant [-Wpointer-compare]

THESE WERE THE 2 REMAINING ERRORS:

arm-atollic-eabi-objcopy.exe -O ihex "ElectronicSpeedControl.elf" "ElectronicSpeedControl.hex"

c:/st/stm32cubeide_1.0.2/stm32cubeide/plugins/com.st.stm32cube.ide.mcu.externaltools.make.win32_1.0.2.201907030841/tools/bin/sh: arm-atollic-eabi-objcopy.exe: not found

make[1]: *** [makefile:67: post-build] Error 127

make: *** [makefile:40: all] Error 2

"make all" terminated with exit code 2. Build might be incomplete.

21:18:48 Build Failed. 2 errors, 23 warnings. (took 34s.371ms)

Error 127 was due to the absence of a program that converts ELF to HEX.  Search for "objcopy.exe on your computer (there were 4 copies on mine!!!), then copy objcopy.exe to the same library mentioned in the error message above and rename it "arm-atollic-eabi-objcopy.exe". That eliminated this error.

DMolo
Associate III
November 12, 2019

I also have this problem, and have gotten around it by getting STMCWB to create a truestudio project I then import. This disables virtually all the CUBEMX functionality within CUBEIDE though, which is annoying...

Surely this is fairly high on ST's list of things to fix?

cedric H
Technical Moderator
November 12, 2019

Dear all,

The latest version of cubeIDE (1.1.0) is now able to handle correctly the motor control projects.

We tested our new MCSDK 5.4.2 successfully with cubeMX 5.4.0.

The MCSDK version 5.4.2 (upload on st.com ongoing) adds the support of the examples with cubeIDE.

So, CubeMX 5.4 + cubeIDE 1.1.0 + MCSDK 5.4.2 should work out of the box.

Regards

Cedric

DCyr
DCyrAuthor
Associate III
November 12, 2019

Hi Cedric,

We downloaded the latest MCSDK 5.4.2 and that seemed to fix some problems, but there is a new error that I can't understand because I can't find an explanation anywhere describing ERROR 1. Also, what does makefile:43 mean? This was using the STEVAL-SPIN3204 and the associated software "out of the box".

make: *** [makefile:43: 6steps_STEVAL-SPIN3204-2019-11-12.elf] Error 1

"make -j8 all" terminated with exit code 2. Build might be incomplete.

16:06:50 Build Failed. 1 errors, 0 warnings. (took 7s.817ms)

make: *** [makefile:43: 6steps_STEVAL-SPIN3204-2019-11-12.elf] Error 1 6steps_STEVAL-SPIN3204-2019-11-12 C/C++ Problem

Thanks for your help,

David Cyr

The process uses the Motor Control Workbench to define the motor, MCSDK then calls STM32CubeMX that then opens the project in STM32CubeIDE. The Target Toolchain is specified as STMCubeIDE.

cedric H
Technical Moderator
November 13, 2019

​Hello David,

We just realized that the latest version of the workbench we put in the release does not allow to copy the example anymore.

Let me explain.

For some example, we provide a folder with additional files. For instance, the 6steps example is located by default here :

C:\Program Files (x86)\STMicroelectronics\MC_SDK_5.4.2\Projects\STEVAL-SPIN3204\Demonstration\6Steps_STEVAL-SPIN3204

The workbench must copy the content of this folder into the new location. It is required to keep the same stmcx name, just change the path.

Because of the copy issue of the Workbench, you must copy the folder manually, at the same level than the stmcx file.

Example : c:\My_test\6steps_STEVAL-SPIN3204.stmcx

                       My_test\6steps_STEVAL-SPIN3204\6steps_STEVAL-SPIN3204.ioc (+ all the files present inside C:\Program Files (x86)\STMicroelectronics\MC_SDK_5.4.2\Projects\STEVAL-SPIN3204\Demonstration\6Steps_STEVAL-SPIN3204 )

Once it is done, as we provide an IOC file, you must click on update instead of generate in order to not erase the IOC we provided.

(thanks to the update button, only the motor control parameters coded inside the IOC are changed)

I noticed another issue in the example provided due to an API changed in the HAL library.

So, if you use the version 1.11.0 , the line 250 of the file 6step_conf.c must be changed into :

HAL_TIMEx_ConfigCommutEvent((TIM_HandleTypeDef *) pHfTimer, TIM_TS_NONE, TIM_COMMUTATION_SOFTWARE);

We are preparing a new release to fix all these issues.

Regards

Cedric

DMolo
Associate III
November 14, 2019

Anther observation is that the stm32f3 library has, for no apparent reason,​ changed the timer synchro function to a timer synchronisation function, so it doesn't compile, can't find the function etc (written from my phone, sorry no actual function name)

I'd generally complain that the st cube software family results in a lot of frustration with things just not really working, compiler/project settings and​ code getting overwritten, libraries that are far too abstracted and variables defined and held in unpredictable, scattered and unfindable places...

I appreciate the tool to some extent since I'm a hardware engineer not a software guy, so when the mcsdk does work and the process flows smoothly it really does accelerate my progress hugely, but I do spend an extraordinary amount of time fighting broken st tools.

By contrast, infineon libraries are really easy to read and understand (for the motor ones at least) though their chips resist programming strongly (seggers seemingly can't touch them and their memtool simply doesn't work) and the code generation tools, examples and libraries are sparse.

cedric H
Technical Moderator
November 14, 2019

Hello David,

The reason to change the API is to bring coherence across all series. As some code is generated, it is mandatory that your cubeMX version follows the HAL version. The MCSDK 5.4.2 has been tested with cubeMX version 5.4.0. The F3 series with HAL version 1.11.0

I understand your frustration. We try to do our best to improve the quality of our delivery, and to guarantee a successful "out of the box" experience.

Unfortunately, we missed this target with the MCSDK 5.4.2 release.

You mentioned that the library is far too abstracted, I guess you are talking about the HAL flavor. We provide also a LL (Low Layer) flavor that aims to be very close to the hardware with direct access to peripherals registers with a minimal memory foot print. We use the LL internally inside the SDK, you can also generate the initialisation code (mainly main.c ) with the LL version.

Regarding your code getting overwritten, I would like to understand if you put your code inside USER CODE comments like this one :

 /* USER CODE BEGIN 2 */

 /* USER CODE END 2 */

If your code is outside USER CODE section, it will be lost at the next generation.

Thanks for your feedback

Best Regards

Cedric

DMolo
Associate III
November 17, 2019

Cedric,

I am careful to put my code inside those comments where required, though I sometimes miss it since the open and close comments are in odd places - e.g. wrapping the main function and main closing bracket, but not including the empty space in main - but this is not the explanation. I have experienced the CUBEMX overwriting the .cfg and the FLASH.id files when regenerating, which results in a program that won't build or flash. I use source control, so was able to find this fairly easily. This may have been fixed in a later release, I haven't experienced it for a month or so.

My MCSDK was 5.4.1, not 5.4.2, I'll try updating. Would be nice if it informed of new releases, or am I missing something? HAL level was correct though, and CUBEMX version was the same as released with CUBEIDE, which is no immediately clear as to what release it is, the only place I seem to be able to find the release number of the bundled CUBEMX is when I generate a project report, which says 5.4.0.

-------------30 minute time break updating everything and re-creating all the codes etc.---------

I now have the latest of everything, have meticulously followed the process MCSDK, CUBEMX, CUBEIDE generating a new project into a new blank folder in my "mydocuments" and can report...

It couldn't import the project still, and has the can't build hammer greyed out error. If I try to import it, it doesn't recognise the project atall, and if I click the .project file, it opens in CUBEIDE but can't build. Come on guys... This is getting silly. Can still import a TrueStudio project in the same way and it works. This is your flagship software, and it can't recognise its own generated code.

0690X00000As75GQAR.jpg

STM32CubeIDE

Version: 1.1.0

Build: 4551_20191014-1140 (UTC)

STM32CubeIDE

Version: 1.1.0

Build: 4551_20191014-1140 (UTC)

DCyr
DCyrAuthor
Associate III
November 14, 2019

Thanks for the quick and candid response.  Much appreciated!   

1)     Could you please give me a rough idea when you expect to release the next version that fixes these issues? 

2)     How do I generate FOC firmware for the SPIN3204, since only a 6-step library is provided?

3)     There is no file “6step_conf.c�? on my computer anywhere, and I downloaded STSW-SPIN3204 as well as the latest software MCSDK version 5.4.2. A file search found 2 files “6step_conf.c.ftl�?, and if these are what you referenced in your instructions, line 250 does not look appropriate to change as described.

4)     You say copy the files manually, but I downloaded the STSW-SPIN3204 and put it in the STM32CubeIDE workspace, so it’s not in the C:\Program Files (x86)\STMicroelectronics\MC_SDK_5.4.2\Projects\STEVAL-SPIN3204\Demonstration\6Steps_STEVAL-SPIN3204 library. Is that OK or is the folder within the MCSDK more updated than the STSW-SPIN3204 I downloaded?

5)     There is no folder for the STEVAL-SPIN3201 in C:\Program Files (x86)\STMicroelectronics\MC_SDK_5.4.2\Projects\.  I assume we can download STSW-SPIN3201 and file it anywhere such that the MCSDK can open the sample project. Is this correct?

Since I am unable to understand and execute what you described, I will have to wait for the next release. I have 3 ST evaluation boards, the STEVAL-SPIN3201, STEVAL-ESC001V1 and STEVAL-ESC002V1. I was considering ordering the STEVAL-SPIN3204, which is why I am trying to compile that code.  This is the status of each:

STEVAL-SPIN3204: As discussed in this thread

STEVAL-SPIN3201: Compile errors as indicated in another thread (https://community.st.com/s/question/0D50X0000BaJqRwSQK/what-is-the-reason-for-compile-errors-with-stm32cubeide-for-stevalspin3201-and-stevalesc001v1-sample-programs-that-are-unable-to-find-modules-even-though-the-libraries-with-the-missing-modules-are-in-the-includes?t=1573654791725)

STEVAL-ESC001V1: Compiles OK with the new MCSDK Version 5.4.2 and downloads to the eval board but it does not run the motor with a PWM signal even though the Motor Profiler and the GUI do, so I know it is electrically connected properly. Perhaps a code change is required to recognize the PWM signal as the speed controller, but I can’t find where in the generated code.

STEVAL-ESC002V1: There is only an EWARM sample program for IAR’s IDE. Since my IAR license expired, with the intent to use the STM32CubeIDE, I can no longer generate firmware. Motor control was also deficient, as the ESC lost control of the motor if the speed request was altered too rapidly.

A general comment about ST products: I attended a workshop in Montreal earlier this year. Preparation for the lab was detailed to the point that is was very easy to install and set up the environment. It would be most helpful if this type of guide were provided to implement the evaluation boards. For example, there is no indication in the user guides where to unpack STSW files.

cedric H
Technical Moderator
November 14, 2019

Hello,

1) We plan to release it today, I hope it will be available at st.com on Friday.

2) This board is 6-steps focused. FOC is doable with single shunt topology but not recommended it is why we do not propose it out of the box.

3) 6step_conf.c will be inside your generated project. (you have to press update button at the generation phase in order to generate this file (and the whole project)

4) I thought you used the MCSDK in order to generate your 6 steps example. We started the support of the 6steps algorithm in the MCSDK as example only. This is this example feature that we will fix in the coming MCSDK 5.4.3 release.

(perhaps It is not clear enough: when you start the ST Motor Control Workbench, your window is split in two parts : "Recent Projects", and "Example projects", the example I am talking about is the latest of the list : "Six-Step drive with STSPIN3204")

I checked the delivery STSW-SPIN3204 and it seems that cubeIDE is not supported by default ( I guess it is your initial issue). I will inform the team responsible of this package of this issue.

To answer your question, the 6steps algorithm present inside the MCSDK comes from the team who developed the STSW-SPIN3204 firmware. So it is similar.

The MCSDK aims to bring more customization capabilities, but the integration effort has just started and there is a lot of limitation that are described inside the readme provided with the example.

So, I would say that generating your 6steps through the MCSDK will allow you to generate a STM32CubeIDE project (as soon as we release the 5.4.3) .

STEVAL-SPIN3201: I tested it successfully with MCSDK 5.4.2/ cubeMX 4.0/ HAL version 1.11.0 / CubeIDE 1.1.0 (Mode release is required otherwise without optimization, code does not fit into the memory)

STEVAL-ESC001V1:  it does not run the motor with a PWM signal - It is because you did not start with the example "STEVAL-ESC001V1 electronic speed control" from the example list. (but here again, wait the coming 5.4.3 ) (And press update button not generate )

STEVAL-ESC002V1: This board is 6steps only and not supported by the MCSDK. I will inform the responsible team to support cubeIDE.

Regards

Cedric

DCyr
DCyrAuthor
Associate III
November 18, 2019

Hi Cedric,

Thanks again for your guidance! The compile now fits in memory with “Release�?, however, several errors occur with different variations of the code. Since my focus will now be on the FOC STEVAL-SPIN3201, I wonder why it doesn’t compile clean for me since you said you were successful with the current versions of the development tools. I get this error with the sample program “SDK5x - STEVAL-SPIN3201 - BullRunning.stmcx�? that comes with STSW-SPIN3201:

C:/Users/david/STM32CubeIDE/workspace_1.1.0/SPIN3201/SDK5x - STEVAL-SPIN3201 - BullRunning/Src/main.c:28:10: fatal error: mc_extended_api.h: No such file or directory

Line 28 of main.c is the statement that fails: #include "mc_extended_api.h"

It compiles clean if I comment out this statement, but it fails to drive the motor saying “software error�?. This file does not exist in the MCSDK Version 5.4.2, but is within 5.4.0. Pointing to that library caused even more errors, so that didn’t help.

If I generate a “NEW�? project, it compiles clean but won’t run the motor using the GUI or the user start/stop button and pot for which I added the suggested user code. The motor starts turning for perhaps 5 revolutions then stops with a “speed feedback�? fault. I tried all the suggestions in the FAQs without success. Strange, because I got the other boards to drive the motor quite well when I was using the IAR IDE.

Questions and comments:

1)     Are compiler error messages described or explained somewhere?

2)     Document UM2152 has an error in the suggested user code on page 8/16:

LL_EXTI_C1earFlag_0_31 (LL_EXTI_LINE_0) should be LL_EXTI_ClearFlag_0_31(LL_EXTI_LINE_0)

3)     Related to this suggested user code for “stm32f0xx_mc_it.c�?, there is no /* USER CODE END START_STOP_BTN */ inside the program, so it is not apparent how to insert the suggested user code. Should the lines of code already in the program following the /* USER CODE BEGIN START_STOP_BTN */ be deleted or left in before or after the added END statement? 

4)     We had success driving our motor with the IAR IDE, but we now must use the STM32CubeIDE. But, we were having trouble starting the motor and also keeping control at low speed. Does the STEVAL-SPIN3201 with a STSPIN32F0 use high frequency injection? An excerpt from UM1052 page 1; “ In this user manual we will refer to this technique as "High Frequency Injection" also called HFI. This new algorithm take benefit of the floating point unit of STM32F30x and STM32F4 series.�? If the SPIN3201 does not, could you please suggest a controller and evaluation board that supports HFI for a sensorless BLDC motor, FOC, 500 to 8000 RPM motor that has to change speed quickly (braking not required). Motor characteristics from the ST Motor Profiler: Rs=0.1, Ls=0.2mH, V/krpm=0.7V, Friction 17microN.ms, Inertia= 1microN.ms, Imax=15A, Vbus=14V.

We will try the other boards what we get the new MCSDK V 5.4.3

Thank you!

David Cyr

DCyr
DCyrAuthor
Associate III
November 15, 2019

Hi Cedric,

Glad to hear there are fixes coming quickly. Related to the items above:

2) After hearing the webinar today with Francesca Sandrini, I have concluded that FOC is a more accurate method of running a BLDC motor, so I will stick with the SPIN3201 that I have in hand, and forget about the 3204 for now, however, we get the following errors with “out of the box�? STSW-SPIN3201 while using the MCSDK. This may have to do with using “Mode Release�?.  Where and how do you specify this Mode Release?

......

c:\st\stm32cubeide_1.1.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.0.0.201904181610\tools\arm-none-eabi\bin\ld.exe: region `FLASH' overflowed by 17576 bytes

collect2.exe: error: ld returned 1 exit status

make: *** [makefile:43: 320120191114.elf] Error 1

"make -j8 all" terminated with exit code 2. Build might be incomplete.

14:33:14 Build Failed. 1 errors, 0 warnings. (took 8s.610ms)

Or with LL specified we get this error with even larger overflow:

c:\st\stm32cubeide_1.1.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.win32_1.0.0.201904181610\tools\arm-none-eabi\bin\ld.exe: region `FLASH' overflowed by 19524 bytes

collect2.exe: error: ld returned 1 exit status

make: *** [makefile:43: 320120191114.elf] Error 1

"make -j8 all" terminated with exit code 2. Build might be incomplete.

18:30:45 Build Failed. 1 errors, 0 warnings. (took 2s.825ms)

4) Yes, I am (always) using the MCSDK but I see in the “Examples�? only the 3204 is listed; not the 3201.  When I open MCSDK, I choose “Load Project�? and select the sample that comes with STSW-SPIN3201 that has the name “SDK5x - STEVAL-SPIN3201 - BullRunning.stmcx�?. I customize the motor in MCSDK and let it generate the code in STM32CubeMX.  I always choose “Update�? whenever it is shown. It then opens the project in STM32CubeIDE.

I look forward to trying the new version!  Thank you for your very constructive help!

David Cyr