I am trying to use the combination of HDS/KSDK/PE and MQX to set up a simple USB Host application. My starting point was merely an MQX task that printed an identifying banner. That worked OK.
When I added fsl_usb_framework, the task would never execute. It appears that some interrupt is coming in before control is passed over to my task. To test this idea, I went back to PE and disabled the "Auto Initialization". I know that nothing would get done with the USB, but when my task printed the banner, I knew that it was due to initialization of the component.
So I went back in and re-enabled it and of course, I'm stuck somewhere in the kernel.
If someone knows what I've done wrong, I'm willing to listen. If not, then I need some help to delve into the lower levels of the processor and find out what is causing the interrupt.
Thanks
Since this was sidelined by the assumption that the problem was an unhandled interrupt and thus bias the thinking, I am closing this issue and moving to _usb_khci_task_create() does not return which is more focused on the real issue.
This will have to be addressed by someone familiar with the kernel internals.
I *think* that in the default code generated by PE the USB interrupt may not handled. At the same time all unhandled interrupts go to the default IRQ handler.
In my code I just add explicitly this
void __attribute__((__interrupt__)) USB0_IRQHandler(void)
{
_usb_khci_isr();
}
It is referenced to as a weak link from the startup .S file
Is your environment with MQX? I believe that with MQX, the interrupt handlers are installed at run time and I was able to find an "install" of of _usb_khci_isr in the init process. However, at this time I was not able to determine whether or not it is actually called.
I did put a breakpoint in the code you suggested and it was never hit.
I'll continue to pursue this, but a secondary question is if anyone can help me narrow down where I can put a breakpoint in MQX to determine the exact source of the interrupt.