I don't like "replying" to my own messages to add more information, but that's the way the community works.
I have been able to track this down to what appears to be a corrupt task thread within the kernel. The problem is very repeatable. It also appears to be a problem with the KSDK and OS abstraction.
The attached project is a minimal one that demonstrates the problem. In it there are three breakpoints of interest:
- dispatch.S line 635 is set to catch when the illegal memory is addressed
- khci.c line 1449 is set to catch entry into the errant routine
- task.c line 3422 is set just prior to the fault happening
When debugging starts, it will hit the task.c breakpoint twice while the kernel sets up its task and the user task. These should be ignored as that all seems OK. Once the khci.c breakpoint is hit, then run until the task.c breakpont is hit. At this point single stepping into the _mem_transfer() routine will show what's wrong. At some point the td queue has an empty td on it. This means that the task_id is 0 as well as the various pointers. Someone knowledgeable of the kernel internals should be able determine what went wrong.
The debug trace at the point is:

For me, the project is dead until this can be resolved. It may be as simple as a problem back at the PE level, but if so then this needs to be corrected.
Thanks