STM32Cube embedded software now on GitHub - Page 1
Forum section: electronics / general

author: Karel
author_rank: Super Contributor
timestamp: May 19, 2020, 01:20:22 pm
content: "STMicroelectronics is now publishing STM32Cube embedded software on GitHub,to open the STM32 embedded software offer to collaborative and community-friendly development and leverage faster,more efficient distribution of updates."https://www.eletimes.com/stm32cube-microcontroller-development-software-from-stmicroelectronics-now-on-github

author: chriva
author_rank: Regular Contributor
timestamp: May 19, 2020, 01:26:08 pm
content: They should bury that software under a rock somewhere instead of making that cancer spread even more.Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

author: Scrts
author_rank: Frequent Contributor
timestamp: May 19, 2020, 01:34:11 pm
content: Quote from: chriva on May 19, 2020, 01:26:08 pmIt took me 4 hours to start using I2C, SPI and UART with interrupts. I did not ever use STM32 before. I think those libraries are great for beginners and I am not sure why not to use them if you don't need to meet specific speed goal.

author: Jeroen3
author_rank: Super Contributor
timestamp: May 19, 2020, 01:35:49 pm
content: It's on github for some time now. They do not maintain it via github, so pull requests or issues will be ported to their internal tracking and removed.At least is would make upgrading somewhat easier if you can handle the submodules dependencies via a mirror server. (never use submodules to a third-party url!)I remember some topic here about a critical flaw in some driver that they fixed in the Fx hal and marked "solved" in the issue reports at the Fy hal with a mention that they fixed in Fx.... Yeah, that's not how it works.But it looks like they are using github features now.https://github.com/orgs/STMicroelectronics/projects/2

author: newbrain
author_rank: Super Contributor
timestamp: May 19, 2020, 03:00:54 pm
content: Quote from: Jeroen3 on May 19, 2020, 01:35:49 pmNice! I've just opened anissueon the CEC library.Let's see how it goes...It's only the third time I report it.

author: thm_w
author_rank: Super Contributor
timestamp: May 19, 2020, 09:10:51 pm
content: Quote from: Scrts on May 19, 2020, 01:34:11 pmThey can be good for beginners as you show, just ignore these kinds of gatekeeping posts.

author: uer166
author_rank: Super Contributor
timestamp: May 19, 2020, 09:14:46 pm
content: Quote from: chriva on May 19, 2020, 01:26:08 pmAmazing.. please don't spread this crap. That IDE is perfectly serviceable, even for large commercial projects. It's as much pain in the ass as any other vendor IDE.It's great for hardware engineers specially who want to confirm the pin mapping and do board bringup easily without doing firmware for a living.

author: chriva
author_rank: Regular Contributor
timestamp: May 19, 2020, 09:23:18 pm
content: Quote from: uer166 on May 19, 2020, 09:14:46 pmIt's buggy, it's slow, it's doing things that is wasting space, it's abstracting everything to kingdom come and makes porting a pain in the brown eye.Could as well recommend "engineers" to use arduino and code "C++"

author: lucazader
author_rank: Regular Contributor
timestamp: May 19, 2020, 10:59:09 pm
content: Quote from: chriva on May 19, 2020, 09:23:18 pmThat comment about c++ shows how archaic your views really are.C++ is a great language to use with micros, just too bad vendors do not really support it nicely out of the box.The STM32Cube is also a great set of tools to get a project up and running very quickly for the vast majority of use cases.Sure there are some cases where it wont work perfectly. And others where you need to optimize more than can be done using a HAL.But for most products that aren't produced in the 10's or 100's of thousands, it is likely going to be cheaper in the products development time to just throw a bigger/faster micro at the problem and save dev time than it would be to optimize everything to the nth degree.I am pleased that these are now up on github.Will allow for a much more transparent view of known bugs, what they are working on and what has been fixed.We use the stm32cube and the st hal to great success at the company that I work for. I would also recommend other companies look into using it as well, depending on how they can fit it into their workflow.

author: Karel
author_rank: Super Contributor
timestamp: May 20, 2020, 07:01:56 am
content: Quote from: lucazader on May 19, 2020, 10:59:09 pmNo, it's not. C++ is a horrible language for multiple reasons.You can read all about it and participate in the discussion here if you want:https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/

author: shangaoren
author_rank: Regular Contributor
timestamp: May 20, 2020, 07:55:10 am
content: Quote from: Karel on May 20, 2020, 07:01:56 amstl is not good for embedded most of the time but the core of the language is good, maybe some times better than c, this is just a sterile debate, both language are good, there is just bad programmers.As for my vision many C programmer do object oriented programming, which is just horrible to read in Cbut performance and size will be similary for both languages if the program is well written

author: Karel
author_rank: Super Contributor
timestamp: May 20, 2020, 08:46:44 am
content: Please, let's not derail this thread and let's not divert from the topic.If you have something to say about C vs C++, consider doing it here:https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/Thank you for your cooperation.

author: newbrain
author_rank: Super Contributor
timestamp: May 20, 2020, 08:57:35 am
content: Quote from: lucazader on May 19, 2020, 10:59:09 pmQFT.I will also add that the HAL is not really worse than other vendors' libraries.Digging into the NXP ones for the i.MX RT series I already found more bugs in some months than I did in the HAL in years, and the amount of layering and bloat makes the HAL pale in comparison (handles inside handles inside handles - sometimes as pointers, sometimes as nested struct, and sometimes even misaligned, so they use an array of 3 to hold 2 and bitwise & the address with a mask).Still, they are very helpful to put together something quickly - and very often good enough.

author: Jeroen3
author_rank: Super Contributor
timestamp: May 20, 2020, 01:13:18 pm
content: Well, at least you can now easily report problems and suggest fixes.Do not forget that what ST is making there is actually quite complicated to manage. Now imagine doing this surrounded by project managers rushed by deadlines.

author: Karel
author_rank: Super Contributor
timestamp: May 20, 2020, 03:22:23 pm
content: Quote from: Jeroen3 on May 20, 2020, 01:13:18 pmMy biggest nightmare...

author: dtodorov
author_rank: Contributor
timestamp: May 20, 2020, 06:37:07 pm
content: I'm using CubeIDE happily for a few months for hobby projects. Works a treat, no bugs, no major issues whatsoever.

author: nuclearcat
author_rank: Unknown
timestamp: May 21, 2020, 12:10:43 am
content: Here is example, why Cube and github "initiative" is garbage.https://github.com/STMicroelectronics/STM32CubeF1/issues/6Bug is reported, fixed in DIFFERENT chip firmware, and when user say WTF? they answer "don't even expect a fix". (Chip is not EOL).IMO it is intentional sabotage.Here is one more example:https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memoryBasically Cube have broken memory allocation and printf %f for many month, for many chips, solution is known, but they keep "discussing".This is worst ever bug possible, that will cause race conditions, memory corruption and etc.Conclusion:If you make some kind of device based on this code, you will shoot yourself in the foot, since no one supports this code properly.So yes, this piece of dried s**t is not suitable for anything else, than to check code snippets and get idea how to implement some kind of not very well-documented functionality.(and at the same time remind yourself that there are programmers in the world who write such terrible code)ST have cool hardware, but their "Cube*" is ugh, just awful.It would be better if they pay&assist open source programmers (like opencm3 guys), and they can give customers MUCH better solutions.

author: thm_w
author_rank: Super Contributor
timestamp: May 21, 2020, 08:38:06 pm
content: Quote from: nuclearcat on May 21, 2020, 12:10:43 amThe fix is posted there, support specifically said you can port it to the F1. It seems clear to me that internally they were told not to release any more FW for the F1. So yeah that part sucks. But its part of dealing with a company that wants to focus on profit. You can't support old devices forever, at some point they are let go.I agree there are better ways to handle it though. There could be an "unsanctioned" or beta fork of the FW, where these fixes are implemented.

author: nuclearcat
author_rank: Unknown
timestamp: May 21, 2020, 10:09:06 pm
content: Somehow yes, but how many such intentionally left unfixed bugs are in FW packages?But one thing to defense of ST engineers - no one did PR, it would be interesting to see what the reaction would be.If they want to play opensource, they should accept it.If this is an imitation of opensource and interacting with community, it will be an interesting show.And btw bug with printf %f hit many chips, not only "virtually EOL" F1, not fixed either.

author: uer166
author_rank: Super Contributor
timestamp: May 21, 2020, 10:48:16 pm
content: Quote from: nuclearcat on May 21, 2020, 10:09:06 pmThe brand new G4 series that just came out has it and had us spend weeks tracking the crashes down. This is where ST support is garbage, I just don't necessarily think it's to do with anything about the STM32CubeIDE. The IDE itself is not at fault, but the shitty libraries that come from ST. You'll hit the same issues if you use those libraries without the IDE.

author: thm_w
author_rank: Super Contributor
timestamp: May 21, 2020, 11:33:04 pm
content: That printf bug does sound hellish. I wonder if any sort of static analysis would catch it.I like to use this lib where its possible instead:https://github.com/mpaland/printfMixing FreeRTOS into their own code just feels like a bad idea then. could be better off managed outside of the company via open source funding, etc.At least the theory is with HAL they should know the abilities/limitations of their own hardware.

author: lucazader
author_rank: Regular Contributor
timestamp: May 21, 2020, 11:57:50 pm
content: mpaland's printf lib. Much smaller than the c stdlib implementation, especially if you want to print floats.I also find it weird that they are hasting their own for lack of a better word "fork" of freertos.Surely it would be better to pull in the official source, and then either patch it, or have a vendor specific support repo for it?Will be interesting to see what they do when users start submitting PRs.I dont think they wll actively accept them until they move their development fully out into the open on github. (if that would happen at all)With their internal system not being tightly linked, and them only pushing snapshots it seems like it would be hard for them to manage except for manually coppying over a diff to their internal projects.Would also be great for them to move the development out into the open as then when they patch a fix internall (but it hasn't passed release validation) users would still be able to see it, and use/test it out while they are waiting for a "stable" release.

author: Psi
author_rank: Super Contributor
timestamp: May 21, 2020, 11:59:57 pm
content: I've not used STM32Cube in ages, so i'm not sure if my opinion is still valid but...STM32Cube just went a little to far.The goal of it seemed to be to hide away all the registers so idiots can code. (My guess is they were trying to do Arduino2.0 using their chip)When the goal should have been a system to show how the registers can be used to do various tasks.Ideally you want to get something working with the library then run an automated process to remove the library calls from source and replace with commented raw register calls.So you can then look through and remove any crap that's not needed for your application.It's not helped by the fact that the STM32 registers are not very human friendly at the best of times. Give me AVR registers any day.And different library versions makes things a huge mess.I really did like the concept of the GUI to graphically setup all the GPIO/Peripheral/Clock registers and click a button to get code for it. That makes a lot of sense. You can see exactly what your doing better in the app.But it needed to be register based not library based, or at least have the option.

author: lucazader
author_rank: Regular Contributor
timestamp: May 22, 2020, 12:27:41 am
content: Quote from: Psi on May 21, 2020, 11:59:57 pmIn some ways they have this now (kinda, i haven't really used it so cant comment with authority).But in the cube you can now generate the project using LL libraries. Which are mostly just macro abstractions of the direct register changes.Its not available for all peripherals. but is for the most common ones.It also isnt super obvious how to do this because the ui isn't that great (they should really get a ui/ux person to go over some of their stuff. i think it would help usability a lot with these things)You can also mix and match, eg use HAL for uart, but use LL for gpio and clock.I probably should check out how useable and good the LL hal is. from a little bit of playing around it does remove a lot of the code bloat so projects compile to smaller more optimized programs out of the box.

author: Karel
author_rank: Super Contributor
timestamp: May 22, 2020, 07:15:25 am
content: Quote from: thm_w on May 21, 2020, 11:33:04 pmThank you very much for sharing thisI already wrote my own printf() implementation but it doesn't support float/double yet.I'm going to try this one.

author: nuclearcat
author_rank: Unknown
timestamp: May 22, 2020, 10:16:33 am
content: Problem is that it is not only printf %f, it is about whole newlib faulty implementation.Anything that uses internally malloc might give you unexpected surprise. Anything it means something not very obvious, like printf.Here is one more example of ultimately shitty code in Cube:https://github.com/gmgunderground/STM32-RTOS-USB-HowToFix/blob/master/README.mdNot only faulty malloc, but also doing malloc in interrupt? Oh my...

author: shangaoren
author_rank: Regular Contributor
timestamp: May 22, 2020, 01:07:42 pm
content: IMO default malloc and printf should never be used in embedded targets, CUBE MX or not.And even HAL and LL sucks CUBE MX still be an handfull tool to map pins when you are routing a circuit and when building your system drivers as a summary of your wiring.even if it is not a perfect soft, a bit slow and with some functions not very usefull it still a good helper

author: nuclearcat
author_rank: Unknown
timestamp: May 23, 2020, 07:41:04 pm
content: Quote from: shangaoren on May 22, 2020, 01:07:42 pmprintf is just convenient way of debugging. It is better to avoid in production, but if you just want to debug something silly and software crash on that - this is ridiculous.About malloc - AFAIK it is very bad habit to use dynamic memory allocation in interrupt routine, and even calling any other complex functions from it.

author: radioactive
author_rank: Regular Contributor
timestamp: May 24, 2020, 12:30:50 am
content: Maybe things are different with STM32H7 series and others, but I had a very good experience after I got to V1.4 (not the lastest available). The only thing I found less than expected was the SPI drivers. I still was able to make it work. Of course, the CubeMX software is intended to just get you going on your project with minimal pains of low-level driver initialization and configuring pins. If you don't use it to allocate your pins before layout, I think you are crazy. It saved me a lot of grief compared to what would have happened in the past without it on the STM32H7 part. I highly recommend that you use it before you do any kind of layout for the more complex parts. If you are just working with the older STM32F4 parts that you already know, then by all means just use the legacy drivers that you know and the layout and pinouts that you know. Please quit making the guys trying to help you feel like shit. If you don't like it, don't use it. STM32M0 != STM32H7. For me, the STM32CubeMX is excellent. The HAL drivers still need some work as of V1.4, but now that I know there is an update, I will check it out.

author: Karel
author_rank: Super Contributor
timestamp: May 24, 2020, 07:47:55 am
content: CubeMX is great for pin allocation and clock/pll setup.But I never use the code generated from it.Sometimes I let it generate the code so that I can have a look at it,but I always write my own implementations that don't suffer from abstraction.Most of the time I hate abstraction. For me, it makes the code difficult to read.But I guess that, for people with less knowledge of C and electronics, it looks attractive.

author: nuclearcat
author_rank: Unknown
timestamp: May 24, 2020, 01:28:16 pm
content: Seems they don't think so. After all, a lot of money is spent on this product, and ultimately customers pay this money in the form of added value.While idea is great, implementation is shitty as hell.While digging Cube code, found this "pearl".https://www.st.com/en/embedded-software/x-cube-iota1.htmlImplementation of most flawed and scandalous cryptocurrency in Cube.Relatively latest news:https://www.coindesk.com/iota-being-shut-off-is-the-latest-chapter-in-an-absurdist-historyAnd it was obvious from the beginning, the one who made this decision - flushed to the toilet ST reputation and company money.It would be better if they spent these "human hours" to fix fundamental flaws of Cube core functionality and improving low-quality code.Either we are observing death of the ST, or there a "hype-enabled" manager who is driving company(or department responsible about Cube) straight to the wall.I wonder if investors are aware about such idiotic moves.

author: shangaoren
author_rank: Regular Contributor
timestamp: May 25, 2020, 08:52:10 am
content: Quote from: nuclearcat on May 23, 2020, 07:41:04 pmBe carefull a printf is not negligeable, the execution overhead created by printf can hide or create bugs, on multitask system it is dangerous, it is more reliable to use debugger functionnality such as RTT from segger

author: Dubbie
author_rank: Unknown
timestamp: May 25, 2020, 09:33:15 am
content: After you use a debugger you will never go back to printfIt just screws all your timing up.

author: nuclearcat
author_rank: Unknown
timestamp: May 25, 2020, 11:51:33 am
content: Quote from: Dubbie on May 25, 2020, 09:33:15 amIf i have board with SWO routed/free and debugger (J-Link or proper ST-Link with SWO) under hand - it is great, better and preferable.But sometimes, for example, it is just printf for temperature i got from DS18B20, and it is convenient to get it simplest way possible, over trivial USB-TTL.

author: westfw
author_rank: Super Contributor
timestamp: May 25, 2020, 09:56:46 pm
content: QuoteIt screws up your timing in a DIFFERENT WAY than using a debugger...QuoteSome implementations of printf() use malloc() (or at least cause malloc() to be included in your binary.)QuoteYou mean like the multitasking, multiuser operating systems that printf() was first developed for? That seems to be a bit of an overstatement!(of course, printf() probably either blocks (freezing all tasks) or allows other tasks to run, both of which CAN be problems.)QuoteUm. Are we going to down-rate library quality due tomoral incorrectness and hindsight into the usefulness of the algorithms implemented? I think that's going too far. Presumably ST said "implement something that shows off the crypto accelerator on these chips"?QuoteI've heard that "recent" versions of the ST code are better than the older code. It might be too late to fix their reputation, though. (There's a lesson there!)

author: thm_w
author_rank: Super Contributor
timestamp: May 25, 2020, 10:34:05 pm
content: Abstraction is wonderfulQuote from: Dubbie on May 25, 2020, 09:33:15 amI agree that I dislike straight printf debugging. But there can be value in using both, specifically printf for logging to a PC or file system over long periods of time.You can use DMA as well.

author: lucazader
author_rank: Regular Contributor
timestamp: May 25, 2020, 10:44:32 pm
content: I personally use printf debugging extensively. and build the delays that it brings into the overall software arch.One thing i find important to make printf less detrimental to program performance is to copy the printf string to a fifo buffer and then when the processor is not busy (eg in an idle task in an rtos) the data will slowly get printed out. this was the software is blocked for the least amount of time in critical areas as the memcpy is pretty snappy.The main reason that i rely on this however is more to do with the products i work on. I mostly deal with motor control and hitting a break point while controlling a motor (especially if you are commutating a bldc motor) can cause lots of fun things to happen (eg motor stops spinning and dumping a lot of power into a motor) and or control loops get out of wack etc. So quite often i have to rely on not using the debugger.I do agree with westfw that the more recent cube hal releases have been getting better in a slow but steady way (for the most part). But unfortunately there is a bit of a bad reputation from the earlier releases that they will have to try and get around.(edit to correct spelling of westfw)

author: nuclearcat
author_rank: Unknown
timestamp: May 26, 2020, 03:24:11 am
content: Quote from: westfw on May 25, 2020, 09:56:46 pmYes, definitely!I think you agree that there is a million and another one reputable and useful way for "crypto accelerator show-off"?Particularly showing an example by implementing deeply flawed Curl-P hash used exclusively in IOTA.https://eprint.iacr.org/2019/344.pdf(also there was discussion between cryptographers how bad it is).Ah yes, Keccak that is used in Curl-P is not "cryptoaccelerated" in STM32. It's SHA-3, and max STM32F4/7 have - SHA-2.And (giggling), all this code heavily bundled with printf+FreeRTOS "explosive kit", just check their sources.I don’t even know what the purpose of writing this code was.Scandalous cryptocurrency with known to be flawed crypto, includes printf that they are unable to fix for almost year and it will hang this code at random moment...One thing i know, they show that there is absolute mess in ST Microelectronics "Cube department".This is seems some kind of shitshow.

author: Jeroen3
author_rank: Super Contributor
timestamp: May 26, 2020, 06:05:30 am
content: Printf is amazing for behavioral tracing. Printf is horrible for driver debugging.Use the tools where they work best.If you have any recent toolchain the use of printf willnotuse malloc.In fact, it won't even do anything! You'd have to implement the system calls first. eg:int fputc(int ch, FILE *f)andint ferror(FILE *f).http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938931411.htmlFor ARM, none of stdio function depend on malloc, which is the relevant lib here.http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938930615.htmlFor GCC I don't know where to find the docs.

author: nuclearcat
author_rank: Unknown
timestamp: May 26, 2020, 06:50:30 am
content: Quote from: Jeroen3 on May 26, 2020, 06:05:30 amSTM32CubeIDE using gcc. And newlib/gcc printf, if you have %f - will use malloc. (probably %s too)

author: Jeroen3
author_rank: Super Contributor
timestamp: May 26, 2020, 07:27:28 am
content: Only when using asprintf though, which is exactly what you expect it to do.https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=1aaf05aa44a2fc1442405d8d6739c70fc66091a3;hb=HEAD

author: nuclearcat
author_rank: Unknown
timestamp: May 26, 2020, 07:41:31 am
content: I'm not entirely sure why printf crashes(i stopped using cube), but it is explained in long thread i sent before (https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory).It can be also because of reentrant function issues, but anyway, i believe mentioned issues is essential functionality and should be fixed ASAP.

author: shangaoren
author_rank: Regular Contributor
timestamp: May 26, 2020, 07:46:34 am
content: Quote from: westfw on May 25, 2020, 09:56:46 pmprintf on embedded system go most of the time to UART, debugger (on arm target) use serial wire interface which is way more faster than UART ...Quote from: westfw on May 25, 2020, 09:56:46 pmMultitask doesn't mean desktop, RTOS are common on embedded targets .... that's not an operating system and not multi user ...

author: nuclearcat
author_rank: Unknown
timestamp: May 28, 2020, 08:16:15 pm
content: https://community.st.com/s/question/0D50X0000BsRNNV/stm32cubeprogrammer-execute-fail-with-could-not-find-or-load-main-class-comstappmainAnd one more. Just each god damn "Cube" software kit i download and expecting to work, wont be really working out of the box.

author: robermeyer
author_rank: Newbie
timestamp: June 21, 2020, 12:20:19 am
content: I use CUBE IDE to configure the cpu pin out and assign peripherals before layout. I generate functional self test for the initial board bring up before the software guys are even bothered with new projects. We have done this for many boards with no issues. Our programmers are very talented and wasting their time optimizing and bitching about the style of STs HAL or LL code because it can be better makes no sense to me. There is always plenty of functional code to write and debug that can be written anyway the talented programmers find productive. Reinventing the drivers and init code because it can be better and faster makes no sense if it works the way it is. Design cycles are too short to rewrite the ton of code ST has already provided for free.Personally I am amazed at the huge effort ST has in maintaining Cube considering the number of different CPUs they have in production.

author: nuclearcat
author_rank: Unknown
timestamp: June 21, 2020, 03:27:57 am
content: Quote from: robermeyer on June 21, 2020, 12:20:19 amhttps://www.eevblog.com/forum/microcontrollers/stm32h7b3-warning-cubeide-1-3-all-projects-are-in-a-broken-state/msg3099437/#msg3099437Then you have to read about H7 story as example, where this particular board wont pass such functional self-test in Cube, because you got "old generation" cpu, that got significant changes, but no changes in part number, so even ST own HAL fail to work with it.Also, check libopencm3, which is really amazing, and where guys managed to keep relatively unified API for several different ARM vendors and processors.While Cube get fixes for one MCU, and intentionally wont get same fix for another, without any reasonable explanation.ST has really great MCUs till now, and Cube was(and probably still) cool about looking to idea how things should work, configure peripherals and clocks, but not more.Moreover, i suspect this messy code in it helping to hide serious problems.For example, recent find that at least some STM32L0 have issues with SPI and it needs "to be set specific I/O configuration".It is mentioned VERY indirectly in 2.6.3 in ES0255 (Errata Sheets, STM32L052x6/8 device limitations).Cube also does solve this "automagically", without any comments or reference:Code:initStruct.Mode = GPIO_MODE_AF_PP;initStruct.Pull = GPIO_NOPULL ;initStruct.Speed = GPIO_SPEED_HIGH;initStruct.Alternate = SPI1_AF ;HW_GPIO_Init(RADIO_SCLK_PORT, RADIO_SCLK_PIN, &initStruct);HW_GPIO_Init(RADIO_MISO_PORT, RADIO_MISO_PIN, &initStruct);HW_GPIO_Init(RADIO_MOSI_PORT, RADIO_MOSI_PIN, &initStruct);Without this "magic", their own ST branded boards not working properly and getting data corrupted.So seems many , embedded developers run a bunch of code and have no idea what this code does and why.And actually they have no choice. Either copy unreliable pieces of initialization code from Cube (and get bugs like mentioned before, like malloc), or get such undocumented problems with hardware.After what i experienced, these examples, i would really think that it is bad idea to use cube code for anything meaningful, even self-tests.More than that, when i got used to high quality code in opensource, where any strange tricks are commented and documented, seeing this pile of poorly documented magic mixed with .a binaries dumped on github is far from something that should be praised.It's cool to reuse code like libopencm3, if license permits, but cube? Hell no, it's ticking bomb.