STM32F3 processes an invalid USB Setup Packet in PCD_EP_ISR_Handler with ep->xfer_count very large

Posted on June 24, 2016 at 09:13

So I have done some more investigation to this problem. I wrote a function check() that compares the pData field of PCD_HandleTypeDef hpcd_USB_FS; to the address of USBD_HandleTypeDef hUsbDeviceFS;, if it detects that they are different it enters an infinite while so that the program state can be debugged. I then called this function at multiple places through the call stack that led to the hard fault.

Here is the call stack that results in the pData being corrupted.

#0 ?? check () (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\usbd_conf.c:65)

#1 ?? 0x0800c3a6 in PCD_ReadPMA (USBx=0x40005c00, pbUsrBuf=0x200053a4 ''\231Ë\025�?�o_E©¡ºÇrŠŠæõ%\021ôØu\235\061ª¡¸ò.A}÷«ªeê\033¤«’\025TeÄA%a§K $¯¹£(¦\235ñõº3Æy\027¥Š:’\r\217m\006\005E?Ç)�?éT«Žïö\tʼê=\035<VÙJ*ªßo^7�G×\024Ÿ¯»®Ê¯®ŠQ©V\037Wq8×\033ª¸»\037«(4EE-�?E‘6õ.´\r®Š¨+î\003½a$�?e\024w z6*Gu52+ÿ<\026wû§\210ygÕ�Uh?�?šîdú\016ò²²LÈ={ßó÷�?Š»ªêŠBj<Ewháqad•:0¶ªŽr&’uTTÚ\006ª*\210\027\024VÕR\026uEê¾s\215\''\''ê†2wÆ�?q�\021�?¢ï¨À\006«»è�?\033‘I`õ7\025. ¢�?Aʪ‡Gqt\027�\034\025Î˺ Š\f_õTñŠºü³\002ª¯õ\017Ùß•\004|Å«8ê)ª¸ªº\035s\034t�\02 (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\hal\stm32f3xx_hal_pcd_ex.c:216)

#2 0x800a5fc PCD_EP_ISR_Handler(hpcd=0x20004c40 <hpcd_USB_FS>) (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\hal\stm32f3xx_hal_pcd.c:411)

#3 0x800ab66 HAL_PCD_IRQHandler(hpcd=0x20004c40 <hpcd_USB_FS>) (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\hal\stm32f3xx_hal_pcd.c:586)

#4 0x80118ca USB_LP_IRQHandler() (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\stm32f3xx_it.c:256)

#5 0xffffffe8 ?? () (??:??)

For clarity, let me outline what happens. I program the STM32F302 and run the program. Then I plug in the USB cable to the STM32F302. Windows / the computer enumerates the device and so on perfectly correctly, and the STM32 Audio device appears correctly in Device Manager. I have the STM32 audio device set as the default speaker so that windows will send audio data to it. I then click the Windows volume control slider so that windows plays that sound so you can hear how loud the volume is. This data gets sent over the USB. Near the end of this audio data being sent is where the problem happens.

PCD_EP_ISR_Handler is called, and enters the part that processes a setup packet, i.e if ((wEPVal & USB_EP_SETUP) != 0){.... Then PCD_ReadPMA is called, however, it seems the problem is that ep->xfer_count is a large number, I have seen values of 70 and 901. This seems too large for a Setup packet. I think that this could be the last of the audio data that the function is incorrectly interpreting as a setup packet.

Anyway, PCD_ReadPMA is then called with a pointer to the Setup buffer on PCD_HandleTypeDef, and pData is the next item after the Setup buffer so it is obviously over written and bad things then happen.

Any ideas on where to go from here? I feel that this is not really my problem: This happens on the code straight out of STM32CubeF3 and STM32CubeMX. Surely its something to do with the data transfer being incorrectly parsed as a setup packet when its something else?

Possibly this should be moved to the STM32F software and firmware forum with the title: STM32F3 PCD_EP_ISR_Handler incorrectly parses setup packet with ep->xfer_count too large?

Another question: On PCD_HandleTypeDef, there is uint32_t Setup[12], where the setup packets are copied. Why 12?

Posted on June 27, 2016 at 08:06

No one? Not even clive1 or tsuneo?

I have been investigating different uC's to find the most appropriate one for my application, and so far have attempted to implement it on the STM32F302CB, the STM32F407VG and the STM32F446RE.

I only encounter this problem on the STM32F302CB, which gives me the impression that the problem is either to do with the STM32CUBE HAL firmware for the F3, or the USB peripheral on the STM32F302CB.

Posted on July 09, 2016 at 01:16

I'm having the same problem (on an STM32f042). The pdev is changed in the endpoint stall routine, as I found through stepping through the code.

I'm doing pretty much exactly the same, trying to get cubeMX code to run. Can play audio exactly once, but not always hardfaulting. Sometimes nothing goes wrong, but I can't restart the audio.

Posted on July 10, 2016 at 19:05

So, I'm in no way pretending this is a fix, but rather a kludge albeit a working one:

in stm32f0xx_hal_pcd.c, in thePCD_EP_ISR_Handle, in the branch

if
((wEPVal & USB_EP_SETUP) != 0)

I detect the condition beforePCD_ReadPMA overwrites the data and send it off to the audio buffer handler:

if
(ep->xfer_count > ep->maxpacket) 
// payload is actually last audio data from isochronous transport
{
// treat as audio packet
HAL_PCD_EP_Receive(hpcd, ep->num, ep->xfer_buff, ep->xfer_len);
}

this works for me, although I would rather fix the ISR itself.