I can't install library to STM32CubeMX

[Mehmet Can Yüney]

Posted on May 11, 2017 at 22:45

Hello,

Ä° just downloaded a library for STM32CubeMX, i just gave library's link below. I just can't install it to Cube. I'm opening the new library manager by clicking install new libraries in help and then clicking the from local... button. And it always says 'This Package version is not managed on this version of STM32CubeMX.'.

Library's Link = 

http://www.st.com/en/embedded-software/x-cube-classb.html

 

I really need to use this library and without Cube, it is so hard to do. So what should i have to do, please help me!

Thanks...

Mehmet Can

[Tesla DeLorean]

Posted on May 12, 2017 at 03:07

A lot of these expansion packages are stand-alone HAL implementations.

[Amel NASRI]

Posted on May 12, 2017 at 12:23

Hello

Y_ney.Mehmet_Can

‌,

All expansion packages aren't supported in CubeMX.

As this is a recurrent request, it is as well reported internally to think once again on how to do it.

It is still possible to download this library from ST web page and use it on standalone or merged with MX generated code.

-Amel

[Mehmet Can Yüney]

Posted on May 12, 2017 at 13:50

Hello Amel

As you said i tried to merge this library with my MX generated code but whenever i try to build it it always gave me bunch of errors that say uint32_t not implemented. I tried to include <stdint.h> but nothing changes. So how can i merge this library with my own MX generated code ? 

By the way, in examples of this library there is no mistake like i have. It works just fine. I'm using STM32F4 Discovery Board and i don't know how to merge this library. And there is no user manual about it so i just can't follow any instractions.

Is there any guide that shows how to merge library to our own projects?

Thanks...

Mehmet Can

[Amel NASRI]

Posted on May 12, 2017 at 15:31

may be you can get inspired from 

https://community.st.com/0D50X00009bMM6QSAW

.

-Amel

[Tesla DeLorean]

Posted on May 12, 2017 at 16:19

Well it really isn't that surprising, or shouldn't be, given that you're using the words Expansion and CubeMX together. You're using it to create branding and associativity, when it's really Additional HAL Examples and Demonstrations.

Unless CubeMX spits out customized boiler-plate code with these expansions the terminology seems misplaced.

Merging could also be made a lot easier if CubeMX didn't hide and obfuscate things related to configuration so much.

[E P]

Posted on August 16, 2017 at 17:30

I'm going through this right now.  Let's look at the page for this software package, maybe there's some documentation.  First the title:

Class B 60730-1 and 60335-1 Functional Safety Package with software expansion for STM32Cube

I'd say this suggests that it's meant for use with STM32Cube.  Next it claims:

The X-CUBE-CLASSB Functional Safety Package consists of a set of expansion software for STM32Cube

It seems reasonable to think that this means the package is meant to expand STM32Cube.  Of course, there's not any actual documentation on how to use the stuff, just a few malformed demo projects.

I can see why this might be a 'recurrent request.'  I'm playing with merging this into the firmware tree that Cube recognizes, though I'm not sure how this package could possibly make anything safer if there's no help on how to actually use it.

[Tesla DeLorean]

Posted on August 16, 2017 at 18:51

To me a lot of this has a 'Vent Radioactive Gas (Y/N)' feeling to it.

The more abstracted the implementation of 'Safety' becomes, the less it is likely to be safe. Doesn't safety come from actually understanding the potential failure mechanisms and addressing/detecting them, and going into some safe or neutral state?

An automated code tool should be able meet any static analysis or code review standards. I'm not convinced this is what's delivered.

>>

just a few malformed demo projects

This is another recurrent issue, demos need robustness because people are likely to use or adapt them. They need real-world testing, and to work outside the idealized case. The less aware will cut-n-paste the code and check the box.

[E P]

Posted on August 16, 2017 at 22:05

After getting over my initial grumpiness about this, what I've found is:

* The software package that they provide isn't an extension for Cube; it's basically a copy of a somewhat dated version of a Cube stm32fxxx firmware package, with any useful Cube metadata removed, a new Middlewares subdirectory with the STL code, and a few examples.

* There's no specific documentation with the firmware package, but there is a pretty thorough app note, AN4435, which goes over what is involved in compliance, and an overview of what the STL package does on various chips.* There are a handful of example projects for various dev boards that (presumably) can be compiled and run on ST dev boards.

So to me it's looking more like a standard ST software/documentation pile, which is to say that there's a lot of discussion of theory, and an extremely focused example implementation, but no real discussion of the details of their actual implementation.  The app note actually gives a fairly decent walk through of how to handle software safety.  I'm still attempting to merge their implementation into mine, and then there's the matter of coming up with tests to see if it actually does anything, but it seems like it should be workable.  The only code I've seen so far that gives me heartburn is

&sharpdefineGotoCompilerStartUp() { Startup_Copy_Handler(); SystemInit(); __libc_init_array(); main(); } /* entry to main() */

but aside from that, it's just a matter of figuring out what the heck their code is trying to accomplish and how to shoehorn it into an existing implementation.

Part of me really wishes that Cube actually could be extended to use this, because I get the impression that the structure of Cube-generated code should accept this stuff fairly readily, but it seems problematic to entrust human safety to a checkbox in CubeMX ('Vent radioactive gas ... VentRadioactiveGas must be 1 or 0.') so I guess it's better this way.  Being forced to step through this at least gives me a better chance of understanding it.

My only major (relevant) gripe at this point is that the library comes packaged with specific HAL and CMSIS versions - are they required to maintain UL's acceptance of the package?  The UL certificate doesn't mention any versions other than the STL, but that version is different than the HAL and CMSIS versions and those versions are different.  I can't find anything that discusses this, so I'm left to assume that I need to use the provided versions of HAL and CMSIS.  Ah well.

[Tesla DeLorean]

Posted on August 17, 2017 at 01:20

I'm not sure I'm grumpy as much as I'm frustrated.

Automated tools, and bad examples can magnify support issues, so it's important that they be solid. The more solid and robust this can be from the outset the less headaches there will be in the code generated, and the support effort wasted on repetitive noise.

There's also a strong case for signing the library source to ensure the UL status, though that's no guarantee it is bug free or the compiler hasn't introduced any anomalies.