Posted on February 16, 2017 at 15:05Hi,
I am using an STM32F7556NG microcontroller, connecting it to a host PC via USB, with the STM32 acting as a virtual COM port. Since the December 2016 release of the HAL, I have noticed a few strange things in the code which make me believe they are linked to the problem I am having, which is that if DMA is enabled, appears to send garbage to the host PC when the device descriptor is requested.
The main oddity that I noticed, is that in function USB_EP0StartXfer in stm327xx_ll_usb.c, if the endpoint is an IN endpoint and of non-zero length, the following code is exercise:
USBx_INEP(ep->num)->DIEPCTL |= (USB_OTG_DIEPCTL_CNAK | USB_OTG_DIEPCTL_EPNA)
if (dma == 1) {
USBx_INEP(ep->num)DIEPDMA = (uint32_t)(ep->dma_addr)
}
So this seems to enable the endpoint for a transaction BEFORE setting the DMA address, which would result in garbage being sent to the USB host. Comparing this to the April 2016 release of the HAL, the endpoint is enabled AFTER setting the DMA address. By doing this, the device descriptor is successfully received by the host.
Another oddity I have found in the new HAL release, is that in the function PCD_WriteEmptyTxFifo in stm32f7xx_hal_pcd.c, the variable 'len' is of type int32_t, whereas in the April 2016 HAL release it is uint32_t. I'm not sure why a length variable should be a signed integer, given that it should never be less than 0.
Any help with this issue would be greatly appreciated.
#usb-pd #usb-cdc #stm32-usb-dma
