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.

[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