Anybody from ST care to comment on when a reliable, working motor control SDK and firmware will be released? So many people having issues with V6, no documentation, bugs in the firmware, only half implemented and almost definitely not tested!

[jartim]

..

[cedric H]

Hello @jartim​ ,

I am sorry to read that you are having issues with Workbench 6.

It is true that Workbench 6.0.0 is not as complete as the previous Workbench 5.Y.4 or 5.4.8. It is the main reason why we kept Workbench 5.4.8 and 5.Y.4 available on st.com. The next version 6.1.0 of the SDK is planed for end of November. The main target of this version is to bring back all the features available on the previous 5.Y.4 and to remove this version from st.com. The version 5.4 is not developed anymore but we keep this legacy version and guarantee it stays functional with the latest version of cubeMX.

Documentation is a big subject we are addressing with the coming release 6.1.0.

Could you describe the issue you have and the hardware you use. We will do our best to find a solution.

Best Regards

Cedric

[jartim]

Hi Cedric,

My biggest issues are these -

1: Lack of documentation on the firmware installed by the V6 SDK - the middleware, the drivers etc. Basically we need documentation on HOW to use the API, NOT just a list of what the API functions do. The biggest culprit here is with IRQ call-backs - I have no idea which call-back I should be implementing for a specific IRQ, and no documentation to tell me.

2: Lack of on-line help in the Eclipse IDE - I should expect to be able to find context sensitive help on any function in the MC firmware, but there is totally 0% on-line help for anything.

3: Build a motor driver using the V6 workbench and the code doesn't compile. Fix the obvious bugs and it then compiles but the motor either does nothing or behaves erratically. Again there's no documentation to explain this or how we should modify things or adjust settings to get the motor working. Why doesn't the motor run as it should - the workbench built the software based on the motor settings, but the final code it doesn't do what it is meant to. This also applies to V5.4 and 5.Y, none of my projects have spun the motor first time so far.

4: Trying to identify what's wrong with a driver I built is almost impossible, the driver and middle-ware code is so badly written that trawling through it is mind-numbing.

5: Use of hard-coded constants everywhere and the use of s16 "special" units makes it even more difficult than it should be.

6: Again, without documentation, following the flow of the driver source is impossible - there's zero explanation as to what the hardware is doing and how the software interacts with it.

7: Here's a big problem - all driver projects are generated to disable compiler warnings for implicit conversions - a dangerous thing to do. But, enabling this warning generates almost 100 implicit type conversions (some of which are definitely incorrect) in the vector-table code alone. If you're going to allow these warning to be hidden, at least just hide them in the module where they occur, don't force the entire project to ignore them - my own code isn't perfect and I can easily make conversion mistakes but the compiler won't flag them as warning because you've turned that functionality off!

8: Another gripe - editing the .ioc file in the Eclipse GUI and re-compiling the pin allocations etc. changes the project's debug-build optimization from "Optimize for Debug" to "Optimize for size". Every time I have to go in and change this back again. Every time.

There's plenty more little things that cause me grief with this SDK, but I'm not going to list everything out, basically your SDK is not fit for purpose (in my opinion) and should never have been released as a usable product. I'm not the only person having issues like this, your forums are full of reports of drivers not running or displaying erratic operation. I guess most people give up and go to a different manufacturer, there's certainly very few answers from any ST people and most of the forum questions go unanswered. Personally I have wasted two months trying to get a positioning driver working with no luck; it has got to the point where I am seriously thinking of cutting my losses and going elsewhere. Unfortunately my client and their company insist I use ST.

[jartim]

Here's one more for the pot -

The motor control SDK uses a non-standard implementation of the Park and Clarke transforms where you appear to have switched everything by 180 degrees and offset the Id/Iq angle by 90 degrees. Why? How does that work? How are we meant to understand what is going on without the documentation to back it up, and why would you do that anyway? Is it 100% tested and fully proven to work correctly in this mode? More to the point, is this the main reason nobody can get a motor to spin properly? Just wondering.

[jartim]

Cedric, I am happy to announce that I am wrong regarding my statement that there is no documentation for the HAL and LL drivers! I have just found the Doxygen generated "help" files on my hard drive for the 1.5.1 STM32Cube drivers - totally by accident - while looking for the driver source. The help files are hidden in the STM32Cube repository folder in my user folder on drive C (which is a folder that is hidden to me in normal use). You could go a long way to improving things by advertising that these help files exist and where to find them! Better still, incorporate them into the Eclipse IDE, or at least put them somewhere sensible where users can access them!

[cedric H]

@jartim​ ,

Just in case of you did not find it, there is also a doxygen documentation generated with the MC-SDK. It is far from being complete, but it is worth to read anyway. There are actions ongoing on our side to improve it.

Regards

Cedric

[Fred V.]

Hello @jartim​ ,

Indeed, this documentation, and some others, that have been around for some times, are not quite so easily accessible from the new Workbench (MCSDK 6), though it is here! We are working towards improving this. And also towards improving the content of it which, we know, is not at the level we would like it to be. Hopefully, version 6.1 of MCSDK should enhance that aspect.

Now, the documentation of the SDK is present in the 6.0.0 release. If you navigate to the MC_SDK_6.0.0\Documentation folder (MC_SDK_6.0.0 being the place where you installed MCSDK), you'll find some documentation. I acknowledge that fact that it is not sufficient to fully understand how to setup a motor control application with an STM32, but it gives a lot of information and we are working on improving it.

Your feedback is quite valuable. Some of the point you mention in you first comment will impact what we are currently doing in terms of documentation.

The how the functions works vs. what the functions do is an angle that we will address for instance.

Interrupt handling is another aspect we'll address, event though their name and usage is defined and described in the HAL/LL documentation and not in that of the SDK. Still, we understand that we should explain more how the Motor Control SDK uses and handles interrupts.

Now, when it comes to context sensitive help in STM32CubeID for MCSKD functions, this is something that we need to investigate before anything can be envisioned.

Your item 3 is a highest concern to us. Yes, we discovered, too late, that some of the configurations that the SDK generates do not build. Obviously. Now, the motor control library is a little touchy to handle. It allows for spinning a wide range of motors in a wide range of application profiles. So, indeed, it is sometimes not so straightforward to have it spin some motors in some situations. Guarantying that it'll compile is a commitment we are willing to take. Whether it will spin the motor "as is", without any tuning from the user (either software or hardware), is definitely not something that we can ensure. Every motor is peculiar, each motor application has its special profile. The MCSDK aims at providing you with the means to tune the application to these specificities. If this is not the case, then we are eager to know where and why.

Item 4 is too vague for me to answer. I can admit that the coding standard we use can be enhanced. More especially, we should comment your code more so that its operation is clearer. Is there more to it?

Item 5 is about the units we use, internally and that are described in the documentation we do provide with the SDK (STM32 Motor Control SDK - FOC User Manual.pdf, especially section 4.1 of this document). These units are being used because they optimize the usage of the measurements that can be made by the peripherals of the STM32 devices vs. the C types used to store them. We are currently looking at some of these units that may be optimized. But, they are all documented, I think.

Item 6 is about documentation, and I count it as such.

Item 7 is more a problem to me. Projects generated by STM32CubeMx for STM32CubIDE (and Motor Control projects generated through the SDK are part of these) do set the -Wall option to gcc. I doubt that this lets any non explicit type conversion go through without a warning. This is something that we explicitly check in our validation. I'll make sure that we do not have a hole in that respect, but I am quite surprised that we have such holes in the validation of MCSDK.

Item 8 is outside of our scope. Indeed, an STM32CubeIDE project always defaults to this "Optimize for size" build (release build actually), or so it seems. This is not something that we can act on at MCSDK level. This seems more an Eclipse behaviour. But, the capability to build a debug build is always possible from the UI of the IDE.

Be sure that we are taking your remarks into account. And I thank you to have provided your feedback as it'll allow us to improve the quality of ST Motor Control SDK.

The STM32 devices ecosystem is vast and many of them are suited for motor control applications. The most obvious are the G4, F3 and G0 families. But MCSDK supports many others.

I hope that we can soon provide a suitable answer to your questions. Please, be sure that we are actively working ont them.

Sincerely yours,

Fred.

[mattias norlander]

Hi @jartim​,

The discussion did not stall internally. To add to what already have been said let me just add some words based on further analysis and discussions with Fred, Cedric, some colleagues in IDE-team and also MX-team....

The points I would like to add to are : #2, 7, 8:

#2. "Online help".

Glad that you finally did find the doxygen related documentation. STM32CubeIDE, being Eclipse/CDT based, should also be able to help you navigate code, jump to declaration/definitions, auto-completion of API functions. BUT - most of these editing features rely on CDT being able to automatically build a symbol "index" (database) over the project files/functions/data/... Quite often auto-generated projects and example projects do not contain the h-files and because of this the CDT Indexer engine does not have sufficient input data to enable all of these editing / code navigation features.

We are aware if this issue internally. Not sure when/if it can be sold.

#7. Implicit conversions.

I can confirm that these warnings are not shown by default. From an IDE point of view we have to find the right balance. And we made the choice to skip it by default. If we enabled it by default we would see issues inside FreeRTOS, CMSIS, HAL, ... pretty much everywhere. What is the right default balance in terms of warnings? Depends on who you ask I guess... For now we have to stick with our warning level, but I would be interested to hear more opinions on the topic. All this said, we must of course address specific conversion bugs in the code. Motor controller team is looking into conversion issues.

#8. Reverting the Optimization level.

IDE is not the root-cause of the issue. The ioc-file contains a specific setting which forces the optimization level set by the Motor Controller team. There is no doubt that "some code" must be compiled with higher optimization to ensure that motor control functions actually work reliably.

But a better approach could be to just enforce this optimization level on the few files/functions requiring higher optimization. This will be investigated. If this is a viable way forward, then we could envision to drop the "forced optimization level" on project scope. Analysis to be performed by Motor controller team.

Not sure if this solves any of your issues, but at least it gives some context and some insights to on-going activities and options going forward...

Kind regards, Mattias

[jartim]

Hi Mattias,

Thank you for continuing to discuss my issues. I am not intending to cause you guys more problems, but I am trying to get across to you the difficulties experienced from the end-users perspective, especially when coming into this the first time.

In answer to your points -

#2 - if the compiled projects and examples don't contain the header files, how do they compile? The include paths must point to the headers or the compilation would fail. If the project contains the correct include paths, the CDT indexer should be able to find them and create the index.

#7 - implicit conversion are always dangerous. If we were building to safety or MISRA standards, we would have to set the compiler to show all warnings, and furthermore, to treat them as errors. If you are saying the FreeRTOS, CMSIS and HAL contain intentional conversions then they should be handled using casting should they not? Otherwise the modules are not usable in safety or MISRA environments. In any case, the user's code should be able to check for these warnings even if your code doesn't, to disable the warnings for the entire project is not acceptable in my opinion.

#8 - compiling the .ioc file in the IDE surely could check the state of the project optimization settings and keep the setting the user has made? Why overwrite the user setting by default? It is not a case of which code should be optimized which way, it is the user's choice in the end, if I need to set optimization to Debug level for my project, surely it should stay that way until I change it, not change whenever the ioc file is re-compiled? Even if this is not possible, you could notify the user the optimization level might change instead of just doing it silently?

Regards

Tim

[Fred V.]

Hi Tim,

About #2: what Mattias means here is that headers files are not explicitly referenced by the STM32CubeIDE projects that STM32CubeMx generates. Only the paths to the folders containing theses files are. So, the toolchain is indeed able to find them. However, since this explicit reference is missing, Eclipse does not index these.

About #7, we'll check for implicit conversions in Motor Control code. There is some level of support for MISRA C 2012 in the Motor Control FW, but I do not have the exact set of rules that we do follow at the top of my head. When it comes to safety, I'm not sure that there qualified exist versions of gcc. Maybe, having a look towards toolchains like IAR's EWARM could help (for both points).

About #8: I'm quite puzzled here. I tried several situations where I modified the IOC file and regenerated the code. I have not come across a situation where the optimisation options are changed.

May you provide us with more details?

Best Regards

Fred

[jartim]

Hi Fred, sorry for the long delay in replying.

Here's how I found this optimisation issue -

1:Import the project into the IDE from the workbench generated code

2: Set the C/C++ Build / Settings / MCU GCC Compiler / Optimization / Optimization level to None (-O0)

3: In the IDE, load the IOC file and change something - add a peripheral, modify a GPIO line etc.

4: In the IDE, compile the IOC file.

5: Go back to C/C++ Build / Settings / MCU GCC Compiler / Optimization / Optimization level - the value has changed to Optimize for size (-Os)

Regards

Tim