mimxrt: Fix USB CDC handling so it works reliably.

[dpgeorge]

On i.MX the SysTick IRQ cannot wake the CPU from a WFI so the CPU was
blocked on WFI waiting for USB data in mp_hal_stdin_rx_chr() even though it
had already arrived (because it may arrive just after calling the check
tud_cdc_available()).  This commit fixes this problem by using SEV/WFE to
indicate that there has been a USB event.

The mp_hal_stdout_tx_strn() function is also fixed so that it doesn't
overflow the USB buffers.

[dpgeorge]

@hathach FYI this fixes our i.MX port to make it 100% reliable with USB CDC transfers (as far as my tests show). It still calls tud_task() within the IRQ handler, which seems ok.

[hathach]

Thanks @dpgeorge for the update, to be honest I don’t know MP enough to comment on the changes. But I am glad you figured it out.
For the race condition between entering wfi and usb event occurred, I have a similar PR for this in circuitpython adafruit#2956 . The solution is disable irqs then use tud_task_event_ready() to check if there is any pending events before executing wfi. In this case since tud_task() is called within isr and event is served right away. Scenario is bit different, though I just mentioned it here for reference since they share some similarities.

PS: feel free to tag me in the future if there is issue related to tinyusb 😃

[dpgeorge]

The solution is disable irqs then use tud_task_event_ready() to check if there is any pending events before executing wfi.

Yes, we do use that pattern in some places in the stm32 port. But IMO using SEV/WFE is a better way to handle atomic events.

[hathach]

Glad you fixed it all. I just create an issue as reminder to implement an isr safe version where several osal calls such as mutex can be bypassed and better testing. Will update the development there, and let you know when its PR is ready.

hathach/tinyusb#651