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
