Posted on September 14, 2016 at 09:47
Hello,
I think I found a bug in the STM32F4 USB controller which is not addressed correctly by the cube library v1.13 and which is not documentend as well.
I'm developing on the STM32F437IIH and I use the USB OTG_FS. The problem occurrs only with at least 2 USB endpoints. Endpoint 1 (IN and OUT used) and endpoint 2 (only IN used) are used in bulk mode.
The problem occurrs if I'm writing on Endpoint 2 in the funtion HAL_PCD_IRQHandler ->PCD_WriteEmptyTxFifo ->USB_WritePacket from a low priority interrupt.
The important routine here is:
for
(i = 0U; i < count32b; i++, src += 4U)
{
USBx_DFIFO(ch_ep_num) = *((__packed uint32_t *)src);
}
If during writing to this data fifo a second higher priority interrupt is interrupting this routine and a register access is happening in the higher priority interrupt (i.e. inUSB_EPStartXfer to start writing on USB EP 1) then the state machine for the EP2 gets confused and this leads to the transmission of the so far written USB data in the fifo and a CRC error. After 3 erroneous transmissions the controller stops transmitting data on the USB for this endpoint. Because there is an array to distinguish between different endoints I would expect that I can access the data fifo for different endpoints independently. But this doesn't seem to work.
This routine would cause such a behaviour during an interrupt.
USBx_INEP(ep->num)->DIEPTSIZ &= ~(USB_OTG_DIEPTSIZ_XFRSIZ);
My solution to this problem would be to implement a lock bit or function before and after the data FIFO write routine which must be read before an access to a USB register. I tested my solution and it worked for me as long as I avoided to access a register of the USB controller during writing to the EP2.
Is there anybody who had similiar problems? How can I get in contact with the cube developers to discuss and report this bug?
