Invoking class drivers from application callbacks

[Syncena]

I'm using TinyUSB on an LPC55S69 (actually an NXP MCU-Link) in a multi-threaded application using FreeRTOS.

The concurrency.md document has the following paragraph:

> The USB core does not execute application callbacks while in an interrupt context. Calls to application code are from within the USB core task context. Note that the application core will call class drivers from within their own task.

Does this mean that calling class driver functions, such as tud_cdc_n_read(), from within an application callback (so running in the context of the USB core task) is verboten?

I'm trying to figure out why I'm seeing odd behaviour where the host application sends a packet to the CDC device, but it is not seen by firmware on the device until the host application re-sends the packet a few seconds later, at which point both arrive back-to-back. The problem is intermittent, but easily reproducible.

The same application code behaves perfectly running on a SAMD51 device, again with TinyUSB. The only difference is the underlying USB hardware and TinyUSB driver (dcd_lpc_ip3511.c versus dcd_samd.c).

[hathach]

Does this mean that calling class driver functions, such as tud_cdc_n_read(), from within an application callback (so running in the context of the USB core task) is verboten?

No, If you are using freeRTOS, the stack already use rtos mutex API to prevent conflict.

I'm trying to figure out why I'm seeing odd behaviour where the host application sends a packet to the CDC device, but it is not seen by firmware on the device until the host application re-sends the packet a few seconds later, at which point both arrive back-to-back. The problem is intermittent, but easily reproducible.

Try to enable tinyusb log with CFG_TUSB_DEBUG = 3, you will need to retarget printf to fast output such as rtt to prevent interference. They are both implemented in the stock example within this repo. If the issue is reproducible with those stock example and supported board. You could open an issue for this.

[Syncena]

This is looking more and more like an issue on the host side. My desktop Mac running MacOS 10.14.6 exhibits the problem, whereas a MacBook running MacOS 11.4 does not.

I've instrumented both my code and TinyUSB, and verified the hardware registers and USB SRAM contents right at the point where the host should have sent some data. Everything says the device's USB endpoint is ready to receive but is still awaiting data from the host.

I'd need a USB HS sniffer at this point to determine if the host is attempting to send the data but the device is responding with NAK (which I doubt).

My money is on the MacOS 10.14.6 driver being confused. If this is the case, then the TinyUSB CDC examples may also show the problem. I'll give them a try and report back.

[hathach]

yeah, an usb analyzer would be very useful. Though if it is host issue, you may get some log from kernel using dmesg.

[Syncena]

So this did indeed turn out to be a host-side issue. Confirmed by a very helpful acquaintance and his USB analyser.

Some combinations of MacOS and Mac hardware seem to be affected. In my case, MacOS 10.14.6 and a late 2012 MacMini. Anecdotal evidence suggests more recent hardware running the same MacOS is unaffected.

[hathach]

I have no idea why host os behaves like that. Maybe it requires additional info ? Thanks for confirmation.