Hi everyone,
I have a problem concerning the InterruptInPipe busy flag of the USB handler of a i.MXRT1052 project. Following the HID device bare metal example, messages are received and then processed by the generic callback function, addressing the case kUSB_DeviceHidEventRecvResponse. In my case the message is processed and the answer to that message is put into a queue. A FreeRTOS task is then called periodically checking the queue. And if a message is available to be sent, this message is handed over to USB_DeviceHidSend(). The first message (answer) is sent properly. However, the next message is never sent because the HID handle's interruptInPipeBusy stays '1', blocking the transmission. This flag is checked in USB_DeviceHidSend().
As far as I can see, the interruptInPipeBusy flag is only set to '1' in USB_DeviceHidSend() before the transmission is initiated. Now, when the transmission was successful the USB_DeviceHidInterruptIn() interrupt is triggered and the interruptInPipeBusy flag is reset. This works for the first transmission, but not anymore for the following. It looks like the second transmission is never completed.
I figured out a workaround (which leaves me with even more questions) The USB_DeviceHidInterruptIn() interrupt handler calls the generic callback function udi_generic_callback() with the argument / case kUSB_DeviceHidEventSendResponse signaling the successful transmission. When I reset the interruptInPipeBusy flag manually here, everything works flawlessly. But what I don't understand is the difference it makes: USB_DeviceHidInterruptIn() clears the busy flag anyway before jumping into udi_generic_callback() immediately.
Maybe someone can point me into some direction here. The workaround works so far but I'm concerned that this is not a reliable solution.
Edit: I'm using MCUXpresso IDE v11.4.1 and the code generation for the USB interface.
