Posted on December 15, 2015 at 14:14
Hi,
STM32Cube_FW_F3_V1.4.0\Drivers\STM32F3xx_HAL_Driver\Src\stm32f3xx_hal_pcd.c
When a device doesn't respond to the host because his fifo is empty on bulk in transfer (normal operation in USBTMC protocol), the host sends several commands on ep0 to abort the current transfer.
This procedure is ending by clear endpoint command.
This command, implemented in HAL_PCD_EP_ClrStall function, sets USB_EP_TX_VALID flag without setting a USB_EP_TX_NAK flag.
The consequence is a bulk in transfer with the content of the transmit buffer.
(it shouldn't).
To avoid this case, I must set USB_EP_TX_NAK flag.
So this hardware flag is only accessible in HAL_PCD level.
PCD_SET_EP_TX_STATUS(hpcd->Instance, ep->num, USB_EP_TX_NAK);
I've added implementation of HAL_PCD_EP_Flush function ( see my code below ) to access this flag.
/**
* @brief Flush an endpoint
* @param hpcd: PCD handle
* @param ep_addr: endpoint address
* @retval HAL status
*/
HAL_StatusTypeDef HAL_PCD_EP_Flush(PCD_HandleTypeDef *hpcd, uint8_t ep_addr)
{
PCD_EPTypeDef *ep;
__HAL_LOCK(hpcd);
if ((ep_addr & 0x80) == 0x80)
{
ep = &hpcd->IN_ep[ep_addr & 0x7F];
ep->num = ep_addr & 0x7F;
ep->xfer_len = 0;
ep->xfer_count = 0;
PCD_SET_EP_TX_STATUS(hpcd->Instance, ep->num, USB_EP_TX_NAK);
}
__HAL_UNLOCK(hpcd);
return HAL_OK;
}
With this code, called when the clear endpoint command occurs, the device doesn't send unexpected data.
This solution works for my application, but I am not sure that my implementation of the flush function is correct.
By the way, in the HAL_PCD_EP_Open function, the NAK is not sets when we use double buffer, is it normal ?
#stm32cube #usb #bug
