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

[chrischrisWhereDidThisNameCome]

Posted on June 23, 2016 at 18:01

Hi all,

I have a STM32F302CBT6, and have created a USB Audio Device (speaker) project for it using STM32CubeF3 version 1.5.Basically, the project initially works. If I for example, set the STM32 as the default audio device and then click the Windows volume control it plays that sound to the STM32, and data are received in the USBD_AUDIO_DataOut etc.However, this only works the first time. The program ends up in the Hard Fault handler. The call stack shows:&sharp0 ?? HardFault_Handler () (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\stm32f3xx_it.c:75)&sharp2 0x801335c USBD_ParseSetupRequest(req=0x208, pdata=0x20004f20 <hpcd_USB_FS+884> ''C'') (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\usb\usbd_ctlreq.c:701)&sharp3 0x8012804 USBD_LL_SetupStage(pdev=0x0, psetup=0x20004f20 <hpcd_USB_FS+884> ''C'') (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\usb\usbd_core.c:266)&sharp4 0x8011a3c HAL_PCD_SetupStageCallback(hpcd=0x20004bac <hpcd_USB_FS>) (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\usbd_conf.c:130)&sharp5 0x800a5ea PCD_EP_ISR_Handler(hpcd=0x20004bac <hpcd_USB_FS>) (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\hal\stm32f3xx_hal_pcd.c:401)&sharp6 0x800ab26 HAL_PCD_IRQHandler(hpcd=0x20004bac <hpcd_USB_FS>) (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\hal\stm32f3xx_hal_pcd.c:566)&sharp7 0x801182a USB_LP_IRQHandler() (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\stm32f3xx_it.c:254)&sharp9 ?? main () (C:\SoftwareProject\Arm\STM32F3\STM32F302_USB_Speaker\src\main.c:109)At &sharp3 you can see there is a problem: pdev should not be 0x0. Somehow it changed. Note that it must have had a valid value for all of the previous setup requests to work, and for the first audio data out to work.Any Ideas? This problem occurs with the minimal code straigh out of STM32Cube, which I will try to attach. EDIT: Project code is attached. Its a minimal project that exhibits this problem, straight out of STM32Cube. I think the only things I changed in STM32Cube was the audio sampling frequency from 22100 to 48000 Hz.Just as a caveat: If I set a breakpoint at USBD_ParseSetupRequest (anywhere in that function) pdev is not modified and the program continues to run correctly #stm32f3 #hardfault #bug #usb

[chrischrisWhereDidThisNameCome]

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?

[chrischrisWhereDidThisNameCome]

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.

[remco2]

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.

[remco2]

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.

[chrischrisWhereDidThisNameCome]

Posted on October 05, 2016 at 14:17

Hi stoutjesdijk.remco, sorry only saw your reply now, not sure what happened with the email alerts. Thanks for that information, I will look into that endpoint stall routine sometime. I ended up going with the STM32L476 though, it just seemed better suited to audio, for example the SAI's have no errata etc