search

hathach / tinyusb

An open source cross-platform USB stack for embedded system
https://www.tinyusb.org
MIT License
5.07k stars 1.07k forks source link

Should IN token when FIFO empty mask be enabled ? #331

Open hathach opened 4 years ago

hathach commented 4 years ago

DCD Synopsys on stm32f4/f7 and esp32s2 this mark is not enabled but the interrupt fired anyway. Enabled it at first cause issue with setup (possibly due to data not ready).

Original discussion:

while troubleshooting esp32s2, I notice that this Received IN token when FIFO is empty (USB_INTKNTXFEMPMSK_M) mask is not enabled at the global endpoint IN. I tried to enable it and it breaks the whole driver, same thing happens with stm32 (USB_OTG_DIEPMSK_ITTXFEMSK). https://github.com/hathach/tinyusb/blob/master/src/portable/st/synopsys/dcd_synopsys.c#L111 May be it got triggered when data is not ready or something

However, I am curious how we got the interrupt when it is not enabled as current code !!! According to STM32 Interrupt tree, the mask is needed !!! Maybe I misread the datasheet due to long hour of debugging, If you still remember the detail, please help to explain it. If it is indeed needed we can enable the mask and fixed the issue with it (data not ready or endpoint not enabled I guess).

image

Originally posted by @hathach in https://github.com/hathach/tinyusb/pull/319

cr1901 commented 4 years ago

I believe what is happening is that the Synopsys core will continue to update the value of the "IN token when FIFO is empty" flag, even when the interrupt is masked disabled.

But since the actual interrupt is disabled, we never see this flag during interrupt processing. And we never clear it either :). So if the mask is set to be enabled, we get an infinite interrupt loop on interrupt return? :P

hathach commented 4 years ago

ah, I just realize we also enable SOF, maybe SOF event (and/or other) cause the driver to check and perform transmit packet as well.

PS: SOF is not used at all by stack, maybe needed in the future, but I am tempting to have way to disable it, since it interrupt mcu at 1ms for nothing now.