No, that’s the correct and expected behavior. But then with the 8-byte stack “error” occurring only twice, it’s not likely the main stack would grow out of bounds and corrupt other memory. Maybe your configuration isn’t providing a valid main stack area?
Ideally, the library-provided vector table is full of functions that are defined “weak” so you can provide your own function by the exact same name and the linker will use yours. Then you can #define xPortPendSVHandler to be the name used in the vector table (maybe pend_sv_handler? or maybe the CMSIS standard name PendSV_Handler?) like this:
#define xPortPendSVHandler PendSV_Handler
And the vector table should be in the source code somewhere for you to inspect/hack if needed.
Can you please clarify? I do not quite understand what you mean.
Attached the source code you need the file in the previous message, look.
As I understand it (based on the source code of vector.c), I can declare the following define: #define xPortPendSVHandler pend_sv_handler?
I guess what I’m trying to say is you likely have a second problem. The first problem is not having xPortPendSVHandler installed directly in the vector table. That problem alone doesn’t seem to be enough to be causing all your symptoms. But we’ll get there…
I don’t know what’s in vector.c, but sure give it a shot.
No, I was wrong to think there was a second problem. I had figured (wrongly) that the main stack would just keep growing uncontrolled, but really those stacked words just became part of a task’s context, which of course isn’t safe on the main stack. Anyway, glad it’s working. We never would have figured it out if @rtel hadn’t asked about your PendSV installation.