INTERFACE_THREAD_STACK_SIZE: ethernet receive task stack too small in ethernetif.c

[alowell]

I saw a short thread from 2020 that mentioned this and solved the problem by increasing the specified stack size from 350 to 512.  At the time, there was no discussion of why the auto-generated stack is too small in the first place; and I have seen no follow-on/alternate discussions (or, at least, ones I can find).

FWIW, I have a theory and a suggestion for improvement...

We have two builds with identical CubeMX configurations, one of which works fine and one of which breaks in that specific way -- we must increase the stack size from 350 to something bigger (we use 512).

As near as we can tell the difference between the two is that one (the one that works) is built as a 'C' project using the 'C' compiler; and the other (the one that breaks) is built as a 'C++' project using the 'C++' compiler (but with no actual C++ source files in the simplified test build  -- they both use exactly the same source code and .ioc template).

My theory -- and it is only a theory -- is that the 'C++' compiler adds enough to the stack frame for handling thrown exceptions that it blows past that 350 bytes.

My suggestion is that CubeMX be modified to deal properly with that when it generates the Ethernet code -- or, at least that somewhere prominent there be some note about a need to make that change when using the 'C++' compiler...

                                                                                   -apl

[STea]

Hello @alowell ,

First of all, thank you for your contribution and interest given in this subject.

your point could be a valid point meaning that the C++ compiler could use more than the intended stack that's why you get the same project working with the c compiler. but my problem with that that this cannot be proven as it has too many variables which my impact the stack usage the compiler version optimization level and the user code  can impact stack usage so the generated MX code could not account for this beforehand ,and I think that it should be up to the developer to analyze the code and the stack usage in a debug session and determine the exact amount needed for stack for it to be optimized for his use case.

CubeMX purpose of code generation is not to generate working application but a jump-start with the configuration and a starting point of project development so some effort must be done on user side.
Hope this helps you, and very thankful for your investment on this subject.

Regards