CubeMX and LwIP package update from 2.0.3 to 2.1.0

[TOlli]

Hi,

Is there an update to CubeMX in the works that would upgrade the LwIP package to the latest 2.1.0 release, instead of using the old 2.0.3 version currently in use by CubeMX?

Best regards,

[TOlli]

I see that it comes with individual HW packages, so I'm using H7 series chip. I saw that F7 has the update already so this makes me believe, that H7 would be coming as well.

[alister]

v2.1.1 and v2.1.2 are bug-fix releases.

v2.1.2 was released in 2018.

[MEdgerton]

Yes, I was wondering that as I have made the move from F7 to H7. But now my SSI code will not compile as the fsdata_custom.c has incorrect definitions.

Have you made the same change?

[MEdgerton]

Does this mean that the H7 will get the update. I have just moved to the new H743ZI2 Nucleo board from F746. It has a number of issues for the build (let alone at runtime) to resolve.

[alister]

Some lwIP resources

• Home https://savannah.nongnu.org/projects/lwip/.
• Repository http://git.savannah.gnu.org/cgit/lwip.git.
• Patches https://savannah.nongnu.org/patch/?group=lwip.
• Forum http://lwip.100.n7.nabble.com/.

>Does this mean that the H7 will get the update

v2.0.3 is stable. It builds fine. I'm developing an STM32H7 and I'm not waiting for v2.1.0.

Upgrading software is unproductive/unprofitable unless it fixes something or produces something you'd sell.

>H743ZI2 Nucleo board from F746. It has a number of issues for the build

v2.0.3 would not cause build problems.

>the fsdata_custom.c has incorrect definitions.

This is not an lwIP file. It has nothing to do with upgrading 2.03 to 2.10.

It's a Cube file. Doesn't matter it's broken. You'd have to modify it anyway.

Read widely. Search the web. Search community.

You didn't describe the build problem. Try https://community.st.com/s/question/0D50X00009XkY6NSAV/how-to-add-fsdatac-file-to-project.

[EDIT]

>I have just moved to the new H743ZI2 Nucleo board

See also https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet.

[MEdgerton]

Thank you for the reply. I have it working. There were some changes from 2.0.3 to 2.1.2 and the STMH7 settings did not default to the same defaults for lwIP as the F7. This I have fixed. You are right that there isn't much point changing as it doesn't add much value (except as you say the bug fixes in those versions which I will check up on.)

On that note, is it possible to apply those patches myself to the CubeIDE middleware for the H7 if I need to for the bug fix? If so who does one go about updating the inbuilt middleware?

[alister]

>is it possible to apply those patches myself to the CubeIDE middleware

Patches haven't been accepted/merged for one reason or another. You should expect to have to implement something.

>(how) does one go about updating the inbuilt middleware?

You may change anything. But if you change files generated by Cube it'll clobber your changes next time you generate.

There are many methods to manage this and your method would depend on your circumstances. For example...

• If you're unlikely to re-generate Cube, make the changes in situ, and if you do need to re-generate later, revert its clobbering before you commit.
• If you're likely to re-generate Cube, commit your changes somewhere else and exclude Cube's files you'd changed from your build.

[MEdgerton]

So I can not change the files CubeIDE uses to generate the files, only the generated files?

If so thats OK, although a little annoying. Is there a way to "lock" some of the output files so if for example I want to adjust the clock config I can "lock" the lwIP part so it does not regenerate those files? That would be useful.

If not, then as you say a version control like git could reset the changes.

I realise that you should setu the configuration then leave it alone, but in practice things always get changed especially at the early stages of a project!

[alister]

>I can not change the files CubeIDE uses to generate the files

You could. But it wouldn't be sensible to.

I'm on Windows. My Cube stores its firmware packages at C:\Users\alister\STM32Cube\Repository.

I organise my projects so any developer could join the team and build exactly the same as I do. I version control all projects. I've a text file in the root of each project describing all the tools needed to build it, their versions and any special instructions. This way, any commit that's pulled, even historical, its environment can be exactly reproduced.

Now let's say I changed Cube's firmware package or made and installed my own Cube package. Then I'd have to version-control that too.Too much effort. Waste of time. I seldom generate anyway.

>Is there a way to "lock" some of the output files

Not the way you'd described it.

Method 1: Before generating, commit your work. After generating, revert Cube's changes you don't want.

Method 2: Move the generated files you're changing out of Cube's Middlewares directory to somewhere among your source directories and exclude Cube's files from your builds. That way it doesn't matter if Cube changes them because you're not compiling them.

>I realise that you should setu the configuration then leave it alone, but in practice things always get changed

Yes. You want to minimise your generates or generate workflow as it's not productive time.

So try not to change Cube's things outside of its USER CODE BEGIN/END sections.

And if you do have to change its things, move the files or be prepared to have to revert each time or diff and revert only the changes you don't want.

There are other methods too. E.g. if there are USER CODE BEGIN/END sections, you might be able to put a "#if 0" in one USER CODE BEGIN/END section and "#endif and your changes to their things in the next USER CODE BEGIN/END section...