*** STMCube is NOT ready for prime time! ??? ***

[ceo]

Posted on August 08, 2014 at 08:45

I see a lot of talk about STMCube on here, and I am sure its exciting for ST to be developing this new product. But, this is NOT ready for professional level embedded engineers that need to ship products that work. I need to spend time building stuff, not hunting down bugs, and playing with APIs and tools that don't work.

I am shocked that ST is not supporting the Standard Peripheral Libs anymore. I have put in an email to leadership (I am the CEO of an Austin Embedded company, so hopefully it will find its way to decision makers), but that said, of the FAEs on here and professionals, have we heard anything that ST is going to come to their senses and retract the position of not updating and supporting the Standard Peripheral Libraries? And instead do the SANE thing of continuing to support the SPL while suggesting customer try out the new STMCube tech, and at such time the STM Cube tech is 100% operational then they can wind down the SPL support. Right now, these forums seem like free tech support and bug hunting by us customers, we are doing STs work for them! ST should have debugged this tech 100%, introduced it to ALL the compiler vendors 6 months ago, induced them to support it in ADDITION to the SPL, so this transition wouldn't be such a cluster frack! So, right now, I am torn between continuing to use the SPL and old libs potentially not being able to use a new Cortex chip I might need, switching to freescale, or potentially wasting 100-200 hours trying to get the STMCube tech to work and port everything, only to find it doesn't work. My initial findings are that, there is a lot of broken stuff, my tool vendor doesn't support it (Rowley), and there are going to be a lot of manual steps to make this all work. Generating the files with STMCube, copying them, hacking, etc. This isn't 1980's and DOS anymore, I want the tools to do everything. Its not well documented, tested, etc. And this is FINE, if it was a transitional library, but now its the ONLY supported library -- its like Windows 8 -- what is ST thinking? Thoughts? Opinions? Comments? What is everyone else doing? Andre' #stmcube-stmcubemx #i-want-to-smack-people

[schauer]

Posted on August 08, 2014 at 09:33

I started a commercial project at the beginning of the year with SPL. After I was required to fix some bugs in there Cube was released (around end of February) and I hoped things start to get better. And in the beginning it looks somehow more complete.

I was totally wrong. In the end my/our conclusion was that an own library might be a better solution. The biggest issue arose while developing the library: the uC's documentation is partly incomplete or not exact enough. If one would write a lib directly from manual it would simply only partly work. I tried to contact ST over the official channels but received no answer till now. Using the HAL with Rowley was not an issue for me, merely a few minutes of setting up the paths correctly - annoying, but not a real issue in regard to the other things... Personally I must say that this is the first time I use a uC from ST and if I would have had a chance to switch to another, I wouldn't be with ST anymore. Sadly the others do not offer the combination of peripherals that match our needs that good.

[Tesla DeLorean]

Posted on August 08, 2014 at 14:29

I'd up vote the parent but the forum only allows it for child posts.

I've written on this several times, if the forum had a better search feature I'd probably find some gems. Basically I think ST has made a crap ton of money from the STM32 and the original firmwares, developed by a few hardware leaning engineers, now we have a whole army of software engineers on an overreaching task of unifying something that isn't adequately similar, so a we can get a ''And the monkey presses the button'' approach to firmware development. ''The standard library is mature, relatively bug free and well supported by people like myself. ST has opted to cease development of it, and marked it Not Recommended for New Designs. The Cube/HAL has ST's active support, but is in the early stages of development and testing, and has a lot of bugs making it unsuitable for code you expect to deploy, and support in the field.'' [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32F2xx_HAL_Driver%20vs%20%20STM32%20standard%20peripheral%20library&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=253]https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FSTM32F2xx_HAL_Driver%20vs%20%20STM32%20standard%20peripheral%20library&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21¤tviews=253

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=44489&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32F4%20Discovery%20TIM1%20PWM%20Generation%20problem&Source=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?Root...

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/DispForm.aspx?ID=218&RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/STM32CubeF4%20Usb%20documentation&Source=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder%3D%252Fpublic%252FSTe2ecommunities%...

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/%5bbug%20report%5d%20Bug%20in%20HAL%20%28SPL%29%20delay%20function&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=323]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2F[bug%20report]%20Bug%20in%20HAL%20%28SPL%29%20delay%20function&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=323

[SeaFood]

Posted on August 08, 2014 at 15:36

Hi Andre

Sorry to hear you had so bad experience with STM32Cube. Is it rather embedded software or tool on PC having issues ? Or both ? Hoping support is handling your issues requests properly and that quality on STM32Cube will be as high as Std Libs in a near future. We'll work internally to ensure your ''by forum debug'' perception disappears. This being said, there was a wrong assumption in your mail, and I'd like to make it clear for everybody:

Existing Standard Peripheral libraries ARE and WILL BE SUPPORTED.

These libraries were widely deployed, and ST understands there are many customers willing to keep them on existing STM32 series and we're commited to keep them on STM32 F0, STM32 F1, STM32 F2, STM32 F3, STM32 F4 and STM32 L1.

By keeping them I do not only mean they will be supported, but they will also by upgraded with the support of new STM32 members in the respective series. This process is already fully active: as an example, the Standard Peripheral Library was recently upgraded on STM32 F4 serie, with the addition of STM32F411 new MCU.

Only brand new series like STM32 L0 will have STM32Cube support from scratch, as we considered that anyway an effort is required to switch from an SPL to another: when switching to a new serie, better to allocate this effort a very last time !

Rgds

[Tesla DeLorean]

Posted on August 08, 2014 at 16:48

I think ST has messaged this poorly, both in flagging the firmware library as NRND, and making the Cube download more prominent in the download pages for the firmware libraries than the download itself that the page should be focused on. Now I realize that the NRND has been walked back at little, I'm still very disappointed that the library will not be extended to the L0 and other parts. Porting between the architectures to this point hasn't been that difficult.

This particular forum page shows the considerable issues people are having with Cube, and they are receiving significantly more active support from ST than has been shown to the STM32 at any level for the last 8+ years. The coding issues with Cube are also exceedingly disheartening.

[jwoolston]

Posted on August 08, 2014 at 20:19

I am no where near as experienced as the regulars who help people on this forum but I am not new to development either. I started using ST chips for a product over a year ago after a TI Stellaris line with Ethernet was not only found to be unreliable, but was NRND'd with no replacement timeline announced and our company decided to abandon TI completely for processors. I was originally attracted to ST by the combination of peripherals and library support. 

The product I am discussing was developed using the SPL and went pretty smoothly. My only complaints there were related to code formatting, unclear documentation and significant english errors in the documentation, all of which I can easily overlook since the code worked. Currently, I am working on a new product using STMCube (which I have an open ticket for). It seems there are a lot of errors hidden in the HAL libraries, particularly related to interrupts. It seems most of them have been fixed but as clive points out, it seems that the most experienced people here who could help are more or less unable to due to a lack of familiarity with the libraries, caused by their unwillingness to adopt them in the face of the problems they have demonstrated. One of the biggest concerns to me is pointed out regularly by clive: the read-modify-write cycle of volatile registers. One would think that a company who focuses so much on embedded processing would fundamentally understand the nuances of programming for an embedded target. My perception of the HAL libraries is that they were written by and for application level programmers, not embedded developers. I am disappointed because I feel like I would be a perfect use case for the HAL libraries. I have an understanding of how embedded systems function, and intrinsic differences between them and application level designs. I do not however have the experience with embedded systems or even a single ST processor to understand the intricate details of how it or its ARM core functions. Additionally, I am not looking to extract every ounce of performance from the system for our products, so I can deal with inefficiency if it means greater code abstraction. What I find though is that I am either tempted to modify the HAL libraries, or I get behavior that is unexpected and difficult to debug. It does seem like ST is making some effort to fix the problems with the libraries, but I am deeply concerned by the observations more experienced members have made regarding fundamental coding flaws, especially with the low level operations the HAL libraries are supposed to abstract out. My only hope is that eventually enough people will become familiar with them that some community support will be as effective as it is with the SPL.

[ceo]

Posted on August 08, 2014 at 23:48

@Seafood,

First, I got confirmation from ST leadership that as you mentioned the SPL is going to continue to be supported. But, this is NOT clear at all as so many have mentioned. So, real simple, ST needs to go to every page they put that big white ''STCube'' graphic on make a 3-5 min video or PP presentation that illustrates the two options, roadmaps, and timelines. It might say things like, ''for those that want a mature and stable library we suggest the SPL, but if you are just getting into ST and want to check out our new ''initiative'' we suggest ST Cube''. Moreover, someone needs to make some videos for migration guides, or docs, etc. try searching for anything with the ST site, and its nearly useless, its better to search google and hope that googles bots spidered the ST page in question. Anyway, to answer your question, ST only has cube project files for 3 vendors, all with VERY expensive tools that IMO of 30+ years of embedded development, and I have written MANY compilers and interpreters...these tools are and continue to be overpriced. That said, there are a number of other great tools like coocox, crossworks, etc. that ST either needs to support OR someone SMART at ST needs to write a white paper, or make a video at ST that just gives a 30 min outline of ''ok, guys here's the things you need to do to get ST cube files to work on ANY compiler/tool''. I am tired of making a mess of my projects with copying files, editing, and hacking. For example, when I started with the SPL, I was like what the hell? Why do I have to go in and copy this file, edit that file, use this XLS clock tool to generate yet another file...all this was NOT clear, and I spent a lot of time being sherlock homes on this and figuring it out as did 100's or 1000's of others I am sure and everyone on this forum. So, on STCube, I don't want to go thru this again, I really like the ST chips, for the price, in the cortex M4F they can't be beat for what I need. But, freescale, Atmel, and others are knocking at the door (freescale has the same problem with tools, but Atmel does NOT, they do have a tool now and the ASF atmel software foundation), but the Atmel is not fast enough for my gaming app, so I selected the ST tech a year ago. But, ST really needs someone that is good at engineering AND good at explaining things as well to help with the documentation and migration of these things. I have made a career out of writing games and books about game dev, graphics, AI and really complicated things, so one thing I know is that engineers don't like writing and documenting things, I made a fortune by filling this niche in the 90's and early 2000's. So, when I look at all the work put into the Cube tech from a programming point of view, I am amazed, but then find it so hard to find clear docs on it and the SPL, their relationship, and any kind of overview of WHAT THE HELL IS THIS AND WHERE DID THE SPL GO? It frustrates me :) In any event, I think I have my answer now -- ST didn't deploy this with the right hand knowing what the left hand was doing, didn't take the time to put together a nice migration video(s), and surely didn't go thru the website and make sure that customers can EASILY find the SPL libs, this and that. I have spent the last week wasting time rather than coding. I just put in a rant to ST leadership about this, but with a suggestion, that like other vendors such as Atmel, Microchip, etc. ST build or license their OWN IDE and then tightly integrate the SPL, cube, and whatever comes next, so us customers can use both the silicon AND the tool from the same vendor. Sure if you love IAR, you can use it still, but ST is a billion $$ company, they have the money and resources to start their own IDE department up, and like Atmel or Microchip can start with a tool like eclipse, GNU, and then integrate their stuff, and make it FREE for the unoptimized version and $99-299 for the full blown enterprise version(s). This would be smart... and make us all happy. Andre'

[SeaFood]

Posted on August 27, 2014 at 11:25

@All: We understand now we were too aggressive in our communication to switch to Cube. We'll try to solve that in upcoming period

@Andre: I think we're in synch. Please see below comments on your post First, I got confirmation from ST leadership that as you mentioned the SPL is going to continue to be supported. But, this is NOT clear at all as so many have mentioned. So, real simple, ST needs to go to every page they put that big white ''STCube'' graphic on make a 3-5 min video or PP presentation that illustrates the two options, roadmaps, and timelines. It might say things like, ''for those that want a mature and stable library we suggest the SPL, but if you are just getting into ST and want to check out our new ''initiative'' we suggest ST Cube''. Moreover, someone needs to make some videos for migration guides, or docs, etc. try searching for anything with the ST site, and its nearly useless, its better to search google and hope that googles bots spidered the ST page in question.

--> We agree. We'll create some documents to explain the various possibilities. Part of pending actions to smooth the message and not push too aggressively people to switch to Cube.

Anyway, to answer your question, ST only has cube project files for 3 vendors, all with VERY expensive tools that IMO of 30+ years of embedded development, and I have written MANY compilers and interpreters...these tools are and continue to be overpriced. That said, there are a number of other great tools like coocox, crossworks, etc. that ST either needs to support OR someone SMART at ST needs to write a white paper, or make a video at ST that just gives a 30 min outline of ''ok, guys here's the things you need to do to get ST cube files to work on ANY compiler/tool''. I am tired of making a mess of my projects with copying files, editing, and hacking.

--> Well actually this topic is diconnected from SPL or STM32Cube, as we only have indeed some project files for commercial IDEs in the examples. This being said, it is accepted in ST that we can't stick to that position anymore. There will be moves on that topic, with the 1st visible offers by year end

. For example, when I started with the SPL, I was like what the hell? Why do I have to go in and copy this file, edit that file, use this XLS clock tool to generate yet another file...all this was NOT clear, and I spent a lot of time being sherlock homes on this and figuring it out as did 100's or 1000's of others I am sure and everyone on this forum. So, on STCube, I don't want to go thru this again, I really like the ST chips, for the price, in the cortex M4F they can't be beat for what I need. But, freescale, Atmel, and others are knocking at the door (freescale has the same problem with tools, but Atmel does NOT, they do have a tool now and the ASF atmel software foundation), but the Atmel is not fast enough for my gaming app, so I selected the ST tech a year ago.

--> The STM32CubeMX tool was also made to get rid of this XLS files and so on. And STM32Cube firmware offer is very similar in the concept to ASF. We need to increase maturity on those offers indeed, but it seems to go in the direction you describe.

But, ST really needs someone that is good at engineering AND good at explaining things as well to help with the documentation and migration of these things. I have made a career out of writing games and books about game dev, graphics, AI and really complicated things, so one thing I know is that engineers don't like writing and documenting things, I made a fortune by filling this niche in the 90's and early 2000's. So, when I look at all the work put into the Cube tech from a programming point of view, I am amazed, but then find it so hard to find clear docs on it and the SPL, their relationship, and any kind of overview of WHAT THE HELL IS THIS AND WHERE DID THE SPL GO? It frustrates me :)

--> As said. Point taken :). We'll explain that.

  In any event, I think I have my answer now -- ST didn't deploy this with the right hand knowing what the left hand was doing, didn't take the time to put together a nice migration video(s), and surely didn't go thru the website and make sure that customers can EASILY find the SPL libs, this and that. I have spent the last week wasting time rather than coding. I just put in a rant to ST leadership about this, but with a suggestion, that like other vendors such as Atmel, Microchip, etc. ST build or license their OWN IDE and then tightly integrate the SPL, cube, and whatever comes next, so us customers can use both the silicon AND the tool from the same vendor. Sure if you love IAR, you can use it still, but ST is a billion $$ company, they have the money and resources to start their own IDE department up, and like Atmel or Microchip can start with a tool like eclipse, GNU, and then integrate their stuff, and make it FREE for the unoptimized version and $99-299 for the full blown enterprise version(s). This would be smart... and make us all happy.

--> As said above, this is the direction we go indeed