Why would anyone use STM32CubeMX if STMicro doesn't?

[MPlan.7]

I have the STM32F769 Discovery kit to evaluate using the F7 for a future project. I want to enable a timer input, so rather than claw through the poorly written examples (for instance, the TouchGFX example doesn't even load onto the chip) I thought I'd use MX to enable the peripheral I want.

Except when I run MX and tell it I have a Discovery board, it gives me a screen full of conflicts and unsupported features. MX does not, itself, understand how to configure a Discovery board (despite being able to pick it out of a menu), nor is there an .ioc file available for the Discovery board.

So STMicro's big new thing, that sets them apart from everyone else, a graphical configurator for board setups... isn't used by STMIcro.

Why even bother to make a discovery board if you're not going to support it with your own software? How, exactly, am I supposed to discover how to use their great tools and chips if they can't be bothered to finish the example? Why would anyone think this is a selling point?

If their software isn't good enough for their engineers, why would they think it's good enough for their customers?

I am not going to invest the time necessary to completely configure a complex board just so I can enable a timer. I'm just going to look at the example code and do it by hand. Of course this means when I go to actually do the project I won't bother with MX either. So two of the selling points of this product - TouchGFX and CubeMX - are already knocked down as useless vaporware.

Not a good start to an evaluation.

[Alex R]

I'm using STM32CubeMX Version 5.1.0 and downloaded the Firmware Package STM32Cube FW_F7 V1.15.0, when requested by the CubeMX.

I was able to select the STMicroelectronics STM32F769I Discovery Board and use all the default names and configurations for the pins, generate the code and compile successfully a test application (with Keil compiler) (all in less than 10 minutes)

I'm not sure why you were not able to configure a test project previously, but I would suggest give it another try, because the tools do work.

[Alex R]

[MPlan.7]

I can see the value of these tools to people who already know everything about this chip and just want help organizing it. For a company that is already heavily invested in ST, I imagine CubeMX is quite handy. However, I am not in that group; I am building my company's first ARM product.

When I used the default configuration for my board, I noticed two things: first, over half the pins were yellow, which made me wildly uncomfortable (I do not ship products that compile with warnings), and second. the Graphics were disabled by default. And I couldn't figure out how to enable them. Since graphics were a critical part of my evaluation this was an immediate problem.

I did use CubeMX to generate code for initializing my timers (by only enabling the specific timers I wanted and disabling everything else), which was handy, but unfortunately this also failed as apparently the timers can only count external events via external clocking, rather than as a direct input capture signal, and none of the external clock pins are exposed on the discovery board. I suspect they are being used for something else - which I could have verified if STMicro had shown me exactly how their board was laid out.

The fundamental issue remains: if CubeMX is the "proper" way to configure a board, then STMicro should lead the way. Their .ioc files should be models for the rest of us, showing what a professional approach looks like. Their discovery board should show off their tools to their best advantage, and vice versa.

The fact that they fell down on this highly visible task does not inspire confidence that they will be there when I am in a tight spot. Hence, the poor evaluation score. I mean, there are other options out there, and some of those manufacturers are getting decent evaluation scores.

[S.Ma]

Could you give your manufacturer ranking respective to evaluation score results?

[MPlan.7]

In order of best to last, based mostly on the tools and middleware (because the chips are all pretty good): Renesas S7G2, STM32F7, NXP IMXRT 1064. The Renesas is only an M4 rather than an M7, but at 240 mHz it's as fast as I need.

[AvaTar]

>... but at 240 mHz it's as fast as I need.

"m" is a valid unit prefix, as well as "M" - albeit the difference is 9 orders of magnitude ... ;)

I did evaluate 3 boards for a "semiprofessional" CAN project recently, an Atmel SAME70 XPLained, a F746 Nucleo, and a Keil MCB1760.

For both the Atmel and the ST, you either accept the restricting framework it comes with (CubeMX or ASF), or you do everthing anew.

And even worse, there is no LL support for the F74x CAN peripheral in the latest Cube package.

The MCB1760 has a NXP M3 MCU, but it took me about 1 hour to get the CMSIS driver lib based example up and running, adapting it to my purposes, and receive actual CAN frames. Sad to say, said driver lib for the LPC1768 is "legacy" too, like the SPL. NXP jumped a similar point-and-click frameware bandwagon.

[S.Ma]

Thanks for sharing. ;)

[DOsbo]

I too am evaluating the F7 (actually H7 but we can't get hold of an eval board) for an upcoming project. CubeMX sounded great on paper, but unfortunately it hasn't lived up to the marketing hype. My first demo project used ST's flagship evaluation board - STM32F769I. After loading the package into CubeMX and accepting the defaults I noticed nearly all the peripherals had conflicts. I set my self the task to get the Ethernet HAL enabled. Hours later I'm still no closer. I have disabled every peripheral on the board and yet it still complains about conflicts. Unless they are resolved, it doesn't allow you to link in the TCP/IP stack (LwIP) which is the whole point.

It's disappointing because now I have to expand my search for a suitable processor and development environment. I guess I'll start with the ones @MPlan.7​ mentioned. Who knows, expanding my horizons might do me good.

[Alex R]

Please try again with a new project, but do not choose the default values to initialized the peripherals.

See the attached picture below. It is possible to enable the LWIP Middleware without any conflict.

[DOsbo]

Hi Alex, thanks for your reply. I should have been more precise. I'm using the Evaluation Board STM32F769I-EVAL. I can see the discovery board does work like you said. However the STM32F769I-EVAL board starts out like this:

I think it has something to do with the FMC address/data lines taking up too many pins. I might have more luck if I start with just the micro (not board) and build the configuration up myself instead of taking things away from the board configuration.

I got Ethernet working on my little Nucleo144 board. There were a couple of gotcha's. The main one was with the tx/rx descriptors being cacheable. It appears DMA and the cache on the F7 don't play well together. Anyway, once they were made non-cacheable it all worked great.

The more I play with it, the more I like it. I'm going to persevere with it and hopefully use it in our next project.

Btw, the community website doesn't work well with my MS Edge 42.17134.1.0 (keeps hanging and the page needs reloading - might be related to viewing images). It works fine with my Chrome browser.

Cheers,

David