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

[DCyr]

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;

[cedric H]

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

[cedric H]

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]

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

[DCyr]

Duplicate entry deleted.

[cedric H]

​Hello David,

If you look at the image below, you will see a contextual menu allowing you to choose between Debug or Release mode.

The correct optimization level is set in Release mode.

This menu is accessible through the little arrow at the right of the hammer.

Let me know if it fixes your issue.

Regards

Cedric

[DMolo]

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.

STM32CubeIDE

Version: 1.1.0

Build: 4551_20191014-1140 (UTC)

STM32CubeIDE

Version: 1.1.0

Build: 4551_20191014-1140 (UTC)

[DMolo]

So restarting CUBEIDE, adding an arbitrary GPIO and regenerating made the hammer appear.

But now it can't build because it can't find main.h and a load of other arbitrary yet important things that are clearly there...

This stuff is eating up lots of development time, money etc. We need a stable solution that we can rely on behaving as expected and be able to update, change... without frigging it around in maze like ways every time we come to revise our design, and with predictable behaviour for when we come to deal with safety, future releases, upgrades, mods due to obsolescence etc.

When we ask the question

"Is this software we are comfortable using for products certified under 60335?"

the answer right now is:

"No, it does not behave predictably, and is rapidly being changed to fix major bugs, so while we might be able to painstakingly validate/verify one release, we have very little confidence that we will be able to replicate the behaviour without a complete, manual re-validation of the entire binary".

Which leaves us in a tricky situation. Our application involves relatively high powered heaters and fans, which if the motor or heater control mechanism fails would result in catastrophic meltdown. It will ultimately remain safe due to thermal fusing, which while saving the end user from harm results in a costly RMA situation.

[DCyr]

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]

Duplicate entry deleted.

[DCyr]

Hi Cedric,

STEVAL-ESC0001V1

After flashing the STEVAL-ESC0001V1 with STM32CudeIDE Version 1.1.0 using MCSDK Version 5.4.3, STMCubeMX Version 5.4.0 and the sample 1V1 program, the GUI won’t connect to the 1V1. The IDE flashes successfully and the GUI will connect to the 1V1 ONLY after running the ST Motor Profiler. The Profiler runs the motor successfully. However, since the Motor Profiler clears memory, loads its own program and does a reset, the program that the IDE uploaded is replaced. So there is no way to connect the GUI to the 1V1 with the sample program (same result with a custom 1V1 program).

The consistent error message is: “Connection failed! No response. check the communication cable, the power to the board or the baudrate (set to 115200 bps).�? Since the Motor Control Profiler works, so the cable should not be the problem. The baudrate is also set correctly and the voltage is 13V from a 20A power supply.

We also got this error: “Connection failed. The firmware version() doesn’t support the monitor (use 3.0.1 or above).�?

There is a reset pin (NRST) on the STM32F303 chip that resets active LOW. This did not help.

Any idea why the GUI won't connect to the 1V1 after flashing it with the IDE?

Comments & Questions:

1.     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)

2.     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 as is?

3.     Does the firmware for the STEVAL-ESC001V1 with a STM32F303 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 it does not, could you please suggest how this can be implemented since we seem to be having trouble with “Speed feedback�?. We are trying to drive a sensorless BLDC motor, with FOC, 500 to 8000 RPM that has to change speed quickly. 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.

STEVAL-SPIN3201

Using the STEVAL-SPIN3201, the GUI connects successfully and attempts to drive the motor but the motor starts turning for about 5 revolutions then dies with “speed feedback�? fault. We have tried all the suggestions in the FAQs without success. Strange, because other boards drove the motor reasonably well when using the IAR IDE. Any suggestions?

Thank you!

David Cyr