USBH_ParseDevDesc always gets ''skipped'' when enumerating?

[StephanMair]

Posted on June 03, 2014 at 04:42

Edit: My goodness the ST is user friendly as always, paste this article into a text editor or something to view. It ate my first submission and I have to write allover in MS word again. Now it had ate all my line feeds. My goodness ST, can you be a bit more thoughtful and user friendly?

Hello

, my custom made dev board can not enumerate a device properly. I’m running a USB HOST program, trying to enumerate an HID device, more specifically, a keyboard.

Before I getting into the â€œskipping functionâ€� problem, allow me to clarify a little bit my problem with the program, which I hope to give you a better picture of what’s really going on.

My program got stuck at the 

HOST_CTRL_XFER

 state, more specifically, when it goes into the 

USBH_HandleControl

 function which dictates the USB control transfer state machine, it always goes into the 

CTRL_SETUP_WAIT

 state then break out.

Now it seems it’s stuck in 

HOST_CTRL_XFER

 state forever, unable to get out.

And yes, the keyboard can be properly detected.

Then it comes the very peculiar part: a function gets skipped consistently.

The function is 

USBH_ParseDevDesc

 function. The program runs right into this function, then it does not execute this func at all, just skip it. This function is inside the 

USBH_Get_DevDesc

 function, which is a part of the enumeration process.

The whole process goes like this:

 main process -> 

device detected ->

begin enumeration ->

enter the enumeration state machine process ->

execute 

USBH_Get_DevDesc

 function which intends to get the device description -> 

judge if descriptions were correctly received using 

USBH_GetDescriptor

 function and several lines of â€œifâ€� codes -> if successful*, execute 

USBH_ParseDevDesc

 command which parse device information. And this is the part where the program runs right into this line, but does not execute this very function at all.

This is all very odd. I mean if the whole program doesn’t reach that line at all then it’s perfectly normal the fucntion isn’t being executed. But this? 

I’m out of ideas. Can anyone give me any suggestions or at least, which direction to look?

*Also, based on the comment in the program, I made the guess that when the program reaches 

USBH_ParseDevDesc

 function, STM32 must have already received descriptors from the keyboard, it isn’t something that I’m sure off, I didn’t use any equipment to verify whether such transaction was successful or had taken place at all, but the comment made by ST’s programmers said it must have been. 

[tsuneo]

Posted on June 04, 2014 at 18:07

> The function is USBH_ParseDevDesc function. This function is inside the USBH_Get_DevDesc function

I'm not sure, which one you are referring to, STM32_USB-Host-Device_Lib_V2.1.0 or STM32Cube_FW_F4_V1.1.0 Anyway, Both libraries have (almost) the same code.

\STM32_USB-Host-Device_Lib_V2.1.0\Libraries\STM32_USB_HOST_Library\Core\src\usbh_stdreq.c
USBH_Status USBH_Get_DevDesc(USB_OTG_CORE_HANDLE *pdev,
USBH_HOST *phost,
uint8_t length)
{
USBH_Status status;
if((status = USBH_GetDescriptor(pdev,
phost,
USB_REQ_RECIPIENT_DEVICE | USB_REQ_TYPE_STANDARD, 
USB_DESC_DEVICE,
pdev->host.Rx_Buffer,
length)) == USBH_OK)
{
/* Commands successfully sent and Response Received */ 
USBH_ParseDevDesc(&phost->device_prop.Dev_Desc, pdev->host.Rx_Buffer, length);
}
return status; 
}

\STM32Cube_FW_F4_V1.1.0\Middlewares\ST\STM32_USB_Host_Library\Core\Src\usbh_ctlreq.c
USBH_StatusTypeDef USBH_Get_DevDesc(USBH_HandleTypeDef *phost, uint8_t length)
{
USBH_StatusTypeDef status;
if((status = USBH_GetDescriptor(phost,
USB_REQ_RECIPIENT_DEVICE | USB_REQ_TYPE_STANDARD, 
USB_DESC_DEVICE,
phost->device.Data,
length)) == USBH_OK)
{
/* Commands successfully sent and Response Received */ 
USBH_ParseDevDesc(&phost->device.DevDesc, phost->device.Data, length);
}
return status; 
}

> The program runs right into this function, then it does not execute this func at all, just skip it. Maybe, USBH_GetDescriptor() fails. Because of code optimization, you would see odd transition. Disable code optimization to see smooth step execution on the code. This Get_Descriptor is the first Request just after device connection. It likely suggests hardware problem, such as - USB connector: D+/D- lines are swapped - OSC/PLL: Crystal frequency, unstable oscillation Tsuneo

[StephanMair]

Posted on June 06, 2014 at 04:09

Thank you Tsuneo for your very informative replies.

First, the code wasn't optimized at all, so I think we can skip that part. 2ndly, you are quite right in suggesting that USBH_GetDescriptor() failed, it is very likely to be the case, however, your further suggestion may not be the scenario, and I understand you implied that could be more possibilities: - USB connector: D+/D- lines are swapped I'm pretty sure the connection was correct, I've checked it several times. I'll check it again, just to be sure. - OSC/PLL: Crystal frequency, unstable oscillation It may not be the case either, since the crystal for the STM32 of my board is working just fine, I've checked that too, unless you were referring to some other crystal. Also, could it be possible that some other peripheral is interfering with the USB? Rest assured that my program runs on another board just fine, my board is using SPI2 as well, and I don't believe there would be some kind of conflict/interference. But I'm not sure. On the other hand, I set a breakpoint in my program (among the codes I posted in my first post), it took notably longer time for the program to reach the breakpoint when running on my board than that board I mentioned. I'm pretty sure it's a hardware problem, and it really is confusing. So, to conclude, some problem remians: 1.Any other possibilities other than you'd suggested in your previous post? 2.Could there be some sort of interference? 3. Last but not least, since I don't use OTG mode, can I leave USB_OVC/OTG_FS_SOF alone? Not connect it to anything at all? What does this SOF pin do anyway? Thank you once again for your reply.