STM32CubeIDE / F4 V1.27.0 ETH generation fail

[VaZso]

Dear Community,

Time to time I am trying to use STM32CubeIDE and since STM32CubeMX started to declare itself as deprecated, I have tried it again - every time I had problems with it anyway.

First, it wants to use the latest firmware for my MCU (F4 V1.27.0) which has a rewritten Ethernet handling but in inconsistent state so it will not compile.

However, I can not go for an older firmware version which feature exists in STM32CubeMX but is missing in STM32CubeIDE although I also have older firmware(s) installed.

Why isn't is possible to first build a fully functional IDE before pushing users from old method?

...or at least to ensure basic generated firmware will compile?

I don't know where to give feedback for ST to update firmware code for working Ethernet functionality and to work on missing functionality of CubeIDE...

Still I feel STM32CubeIDE is not prepared for serious use... how are you feel about its current state?

[TDK]

> STM32CubeMX started to declare itself as deprecated

Huh? Where are you seeing this? Certainly isn't on the product homepage.

https://www.st.com/en/development-tools/stm32cubemx.html

> Still I feel STM32CubeIDE is not prepared for serious use... how are you feel about its current state?

If you use it with the most common settings, it's okay. The IDE itself is great, the CubeMX code generation is mediocre.

If you are on a "serious" project, keeping software versions the same and keeping the code in a version controlled repository is a minimum.

[VaZso]

Sorry, I was referring to a notice shown on project generation which is basically about "System Workbench for STM32" which is set under generation and which will be discontinued soon and they suggests to set generation for STM32CubeIDE

Also, SW4STM32 was set to not recommended (NRND) state.

So they basically try to push people to use STM32CubeIDE which basically seems to be a good IDE if it starts to work well... I used to miss programming option but debugging worked... last time programming has started to work but it could put the board to a state where only hardware reset worked but not through SWDIO.

>If you are on a "serious" project, keeping software versions the same and keeping the code in a version controlled repository is a minimum.

I wanted to check how it works so I have started a new project to see how it is working.

Basically generated code would be good if it would work especially for higher-level interfaces like Ethernet or USB. However, USB device function is not very good (there are better implementation) and LwIP is s 3rd-party project but the general idea would be good...

When I did some experience with STM32H7 microcontroller, it also had problems like it used a different PHY without easy way to set for the actual PHY used on my board and some other problems... now they seem to included support different PHY also for F4-series but they may only tested it for other MCU.

So this code generation is only more or less working and does not have serious testing...

...and yes, if starting point is a generated code, then it does not necessarily have an option to do things in a right way...

[TDK]

SW4STM32 has been NRND for some time now. They’re both based on eclipse and STM32CubeIDE is much better in many ways.
Agreed there are, or at least were, issues with ETH code generation for common scenarios.
CubeMX is free, expect to pay more for tested and verified code. The CubeMX examples are much better than the autogenerated stuff.

[Piranha]

https://community.st.com/s/question/0D53W00001VYkb5SAD/stm32f417-lwip-udp-packets-are-being-truncated