Been bashing my head against a fool bug, on and off, the past couple of days.
One current project is a cute little board with multiple functions, whereof one of the simpler is a port server, bridging a TCP socket and a UART.
Which works as expected, one character at a time. But... send a burst of data into the serial-port side, and there's a reboot, often with a panic message suggestive of stack corruption, or task-control-block corruption, or something that causes the program counter to end up pointing somewhere entirely unreasonable.
Just found it.
See, AGROS uses a glorified version of counting semaphores for task synchronization (in this case, I'm using a single binary semaphore to tell the bi-directional communication loop when to run around copying data hither and thither). So, I'm doing a P on the semaphore inside the loop, and a V when there's been an event on either port.
V potentially results in a task switch, running the scheduler and so on. That, after all, is what it's for.
The event handler is (usually, and always in the case of the UART) called from within an interrupt handler.
So I change the event handler to use Vc instead - free/increment semaphore and continue, without doing anything that doesn't belong in an interrupt handler - and now all seems well. (I'd forgotten that there's also a Vm function, which branches to V or Vc according to the current processor state and should be safe anywhere.)
Though I still have a great big comment regarding the need for careful examination of the TCP-to-UART path, with regard to high-speed data dumps and CTS from the target. That can wait; for now, the essential function is working, and I can proceed with other aspects of the project.