I’m adapting some Harmony 1.0 demo code by adding USART functionality to the Harmony RTOS/dual USB/CDC demo project through the Harmony Configurator. I think I’ve got the configuration correct. This is on the PIC32MZ starter kit board, with the XC32 1.33 compiler. FreeRTOS v8.? is as included in Harmony 1.0 distribution.
The problem is that when I try to run an extra task, the framework tasks seem to get starved out, and I get a stack overflow hook error. The task that throws the error seems to be the Framework (system) tasks, but sometimes it seems to be a NULL task, according to the current task stub object. If I suspend() the other task immediately after creating it, or before it gets into its for(; loop, then the whole original CDC project runs correctly. More specifically, if I try to block the task using the API routines Delay() or DelayUntil() (sp?), then the stack overflow hook is thrown.
I’ve tried increasing the framework stack size, doubling it to 2048 words, to no avail. Framework task priority is 1, other task priority is 4, max is set to 6.
If you are increasing the stack size but it still overflows then it could be that something is being called recursively, or that simply something has overwritten the stack (corrupted the stack).
What happens if you have your task(s) running at the same priority as the framework task?
I’ll try dropping the extra task priority to the same as that of the framework task. And check for anything recursive.
BTW, it seems that the overflow can occur before any framework code has been executed ( as verified by breakpoint on the first line). Harmony-generated code does not use assembly wrappers. Is it possible that a bunch of interrupts come in, nesting and increasing the stack usage?
I confused config_MAX_SYSCALL_INTERRUPT_PRIORITY with config_MAX_PRIORITY. I changed the former from 3 to 4, corresponding to that of my new task and the code works without a stack overflow. Sorry for wasting both of our times.
BTW, the question about assembly ISR wrappers is still confusing me. Even though Harmony does not auto-generate them, shall I write them out anyway to avoid the nested interrupt stack size problem? Do you suppose that Microchip will get around to providing this option?
I confused config_MAX_SYSCALL_INTERRUPT_PRIORITY with config_MAX_PRIORITY.
I changed the former to 4, corresponding to that of my new task and the
code works without a stack overflow. Sorry for wasting both of our times.
BTW, the question about assembly ISR wrappers is still confusing me. Even
though Harmony does not auto-generate them, shall I write them out anyway
to avoid the nested interrupt stack size problem? Do you suppose that
Microchip will get around to providing this option?
loop, then the whole original CDC project runs correctly. More specifically, if I try to block the task using the API routines Delay() or DelayUntil() (sp?), then the stack overflow hook is thrown.