I have used KDS/KSDK/PE/MQX to set up a simple USB host application for a FRDM-K22F board. My problem is that when the _usb_khci_task_create() routine is called, it does not return. Instead something goes awry and I get a "<signal handler called>() at 0xfffffffd".
I have tried single stepping through the process, but am now knowledgeable about the Kernel to understand what's happening.
Any pointers welcome.
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.