26ab78a710
See https://github.com/libopencm3/libopencm3/issues/873 Commentary describing this patch originally by zyp: ``` After looking further into it, I've concluded that my preliminary analysis looks correct. The problem is that setting CNAK before the SETUP complete event is received causes a race condition. The SETUP callback is called when the SETUP packet event is received, which means that setting CNAK from the callback is too early. Originally the problem was that CNAK was set by ep_read() which is called by the callback. #672 solved this by moving CNAK out of ep_read() and calling it after the SETUP complete event is received instead. The regression by #785 is caused by the introduction of flow control calls into the SETUP callback. They also set CNAK. To solve this properly, I propose changing the event handling code to only call the SETUP callback after the SETUP complete event is received. Unfortunately, this implies that the callback can't call ep_read() itself anymore, because the packet has to be read out of the FIFO before the SETUP complete event arrives. This implies a change of the API between the hardware drivers and _usbd_control_setup(). ``` L1 (st_usbfs) works and passes tests as before change F4 (dwc_otg_fs) works and now passes tests. (yay) LM4f still compiles, and has had the same style of implementation as st_usbfs, however has not been tested on any hardware. |
||
---|---|---|
.. | ||
cm3 | ||
dispatch | ||
efm32 | ||
ethernet | ||
lm3s | ||
lm4f | ||
lpc13xx | ||
lpc17xx | ||
lpc43xx | ||
msp432/e4 | ||
sam | ||
stm32 | ||
usb | ||
vf6xx | ||
Makefile.include | ||
cortex-m-generic.ld |