"have you asked FreeRTOS's team"
No; one tends to assume that there is no support for anything in hardware or software these days
Certainly that is the case for anything to do with ST. Their forum is full of questions and with mostly no answers. And same all over the internet.
"Remember also that FreeRTOS stack sizes are in words, not in bytes."
OK that would be 512 32-bit words; 2k bytes. Learn something every day
One of the functions called in the RTOS tasks allocates a 2k buffer, so that is probably crapping over something else.
"Very few tasks with that size would be enough to go out of memory "
The tasks currently running are allocating (words)
1024
1024
512
512
which totals about 12k bytes.
"Did you check the return values of xTaskCreate()?"
No
"Are you aware that FreeRTOS supports stack overflow checking via a configuration flag?"
Yes; currently disabled. I had a dig around that code when it was crashing when its buffer was in main RAM (0x2...) while the entry stack (which remains used for ISRs) was in CCM (0x1...) and I suspected this was causing a crash.
The news that the RTOS allocation is in words not bytes explains why it is working, and may explain why it crashes when I allocate 512*5 to one of the tasks. But that still doesn't add up to 48k.
Silenos - I fully understand your drift, and I don't like the idea of a heap at all. With decades of asm programming one learns to keep stuff deterministic even if it wastes RAM. I like static buffers and just re-use them. Messy but very reliable if you are organised, but nobody does that in C. But the ethernet stuff is above my pay grade and someone else is doing that. AIUI the ST ethernet code uses ~10 1500-byte (MTU-sized?) statically allocated buffers and drives these with DMA. They are not malloced. The stuff which is likely to be malloced is buffers for doing certificate handling; I had a dig around and some of these are 16k+, so it may be hard to go fully static on that, but obviously one must follow every malloc with a matching free otherwise you get fragmentation and the whole thing will fall apart. The guy doing this knows that.
What is interesting is that when I moved the 48k RTOS buffer and the stack into CCM, the ethernet stuff stopped working. No DHCP even. I wonder if there is a buffer on the stack? CCM is not DMA accessible.
Nobody is going to be allocating char[10000] inside a function because it would be stupid and there are only 2 of us working on this, but one can get funny stuff happening and a stack can grow out of control and this can be undiscovered for ages, in the right circumstances, hence my desire to see how far down the stack is growing.
This is a great learning experience for me - thank you all!