Posted on January 05, 2017 at 01:58
I have the same issue it seems, It is very serious. Debugged this for quite a while until i found this post here.
I amalso getting bad transfers on EP2 (and possibly any of the higher EP1 above 1) and have it traced down to exactly this function to be called with the correct data being supplied. 16 Byte Buffer is defined but only 2 reach the PC and it is totally wrong data. Sometimes the Beagle 5000 reports bad CRC as well. EP1 is all ok.
Here is what I see in the USB Analyzer:
This is what is called:
USBx_DFIFO(ch_ep_num) = *((__packed uint32_t *)src);�?And here is the Route Call Stack just before the sent:
And Finally here is the Buffer to Send:
For the Report descriptor it is fine, it works on many commercial products we did.
So based on the above suspicion in the original post i changed to this :
__disable_irq(); USBx_DFIFO(ch_ep_num) = *((__packed uint32_t *)src); __enable_irq();�?�?�?�?But it does not help, still the same:
If I try the same thing via EP3 it also fails:
But if I specify EP1 in my send routine (illegally, of course just for test) :
At this point I have serious doubts, it is not the user code, but either it is something not setup correctly in the LIB when opening the higher EP (I did have to set the TxFifo Manually) or it is something in the USB Engine itself that goes wrong.
This is what i use to setup the EPs:
static uint8_t USBD_CUSTOM_HID_Init (USBD_HandleTypeDef *pdev, uint8_t cfgidx)
{
uint8_t ret = 0;
USBD_CUSTOM_HID_HandleTypeDef *hhid;
/* Open EP IN */
USBD_LL_OpenEP(pdev,
CUSTOM_HID_EPIN_ADDR,
USBD_EP_TYPE_INTR,
0x40);
USBD_LL_OpenEP(pdev,
0x82,
USBD_EP_TYPE_INTR,
0x10);
USBD_LL_OpenEP(pdev,
0x83,
USBD_EP_TYPE_INTR,
0x40);
/* Open EP OUT */
USBD_LL_OpenEP(pdev,
0x03,
USBD_EP_TYPE_INTR,
0x40);
pdev->pClassData = USBD_malloc(sizeof (USBD_CUSTOM_HID_HandleTypeDef));
if(pdev->pClassData == NULL)
{
ret = 1;
}
else
{
extern PCD_HandleTypeDef hpcd_USB_OTG_FS;
hhid = (USBD_CUSTOM_HID_HandleTypeDef*) pdev->pClassData;
((USBD_CUSTOM_HID_ItfTypeDef *)pdev->pUserData)->Init();
// Prepare Out endpoint to receive 1st packet
USBD_LL_PrepareReceive(pdev, 0x03, hhid->Report_buf,
EP3_PKT_SIZE);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 2, 0x10);
HAL_PCDEx_SetTxFiFo(&hpcd_USB_OTG_FS, 3, 0x40);
}�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?
Posted on January 05, 2017 at 17:19
I have now found a workaround to this issue:
I am pretty sure it is an issue with the IC and the Library. If anybody else is facing this problem, I have already used my customer channel to report and there is a workaround document from ST which I don't have as of now, but basically they said it will be worked around in the next Update of the Cube.
If anybody else needs a quick fix the problem is the allocation of the FiFoTxBuffer. The library allocates to much buffer (2x) and interferes with the next EP due to this somehow. I do not know if this is a design issue (as ST claims) or just a bug that there isn't that much Fifo and corrupts other EP registers in the chip. In my case in order not to edit the library I have reduced the TxBuffer accordingly.
