It sounds like you are just suffering from a data corruption. Previously you reported adding one additional test variable caused corruption when calling xTaskCreateStatic() (the assert that the stack was NULL), which may even point to the linker script being wrong. In any case, it sounds like that assert gets triggered before the scheduler starts, which will make it much easier to debug. If data watchpoints aren’t working then view the variable in the debugger as you step through the code to the point you can see the variable getting written over.
I wish I could just take my time and step through the code, but I can’t, since the modem will then time-out as the keep alive message is not sent during debugging pause.
I have to figure out another way to see what is executed just prior the the assert.
Another thing that complicates things, is when I re-run the same code, the moment the problem occurs varies wildly. It can happen at any random iteration and just stepping through a single iteration already is hundreds of lines. Like finding a needle in a haystack clicking and fighting against the timeout of the modem, in which I’m not succeeding.
Which sounds like the assert happens before you have created the task, so I am assuming that is before you start the scheduler and before you start using the modem. Is that right? If so you really need to find the cause of this assert before trying to find the cause of the assert you originally posted about as they are probably both symptoms of the same issue. Of the two asserts, the one in xTaskCreateStatic() is going to be much easier to debug, especially as it is so reproducible.
I increased the stack size of my default task from 256 to 4096. Then my task would not start-up. The only thing which was then running was the idle task.
I changed the stack size to 1024 and all my problems were gone!
I specifically implemented the stack overflow hook and tested the hook with a very small stack, which worked. So when I ran with a 256 stack and the hook was not triggered I assumed 256 was big enough. But apparently it still wasn’t and changing it to 1024 solved the problem. A problem that looked like a memory corruption, which sent me on a wild goose chase for a couple of days…
The remaining question I have now is; why does my task not run when I change the stack size to 4096? I’m running on a uC which has a generous 128kB RAM.
Now that MQTT is up and running, I will need an additional task for OTA, which requires a larger stack, so I need to get it running with larger stacks.
One possible explanation is that the task creation failed because the memory allocation for large stack failed. You can and should check the return of xTaskCreate to ensure that the task was created successfully.