stm32 usb cdc Device Descriptor Request Failed

[txmsszd]

Posted on June 16, 2016 at 19:19

hi,I am tring to use usb virtual port to transmit data to pc.

MCU：STM32F373 100pinscubemx: usb device fs checkedusb:communication device classPC: windows 10heap size: 0x200stack size :0x400when i plug usb cable to pc,it can not be recognised.In device manager,it shows Device Descriptor Request Failed. ST VCP driver installed. BTW, when I debug it, it could goes into USB_LP_IRQHandler after MX_USB_DEVICE_Init() excuted.thanks.

[pieter239955_st]

Posted on October 20, 2016 at 10:25

Did you manage to fix it, i have the same problem and i can't figure it out. 

[ricardomadera]

Posted on December 11, 2016 at 00:05

I fixed this by changing my usbd_conf.c file to disable vbus sensing

  hpcd_USB_OTG_FS.Init.vbus_sensing_enable = DISABLE;

[Jerry Hancock]

Posted on December 11, 2016 at 01:22

I've tried this as well as 100 other tips to no avail on several boards.  I have my STM32F407 disco and STM32F469 working but can't get my STM32F429 or the STM32F746 working.  I have spent hours and hours on this problem.  For all the boars that are out there and the percentage of boards that need to talk to a PC thru USB, your would think there would be 1) better examples; 2) Examples that work; 3) consistency across examples that work.  For instance, I can take the same Cube parameters and setting on the F407 and F469 and they work, and when I say work, I mean they plug into the PC USB and get enumerated as a CDC VCP port.  If you are lucky, you might get the invalid device descriptor error.  Generally, the biggest problem with that error is the clock which has to be set to 8Mhz with HSE_VALUE=8000000 and PLL_M to 8 , PLL_N to 336 and PLL_Q to 7.  This gives the correct clock for the FS devices but doesn't work even with the external PHY devices for some reason.  I've found where the external PHY clock doesn't always get turned on, but this doesn't fix my problem. Why do some boards get enumerated when VBUS is disabled where others do not?   Why do clock settings fix some boards? This is borderline crazy and I have been working with just about every computer known to man since 1976 and this one kicks my butt.  The other issue I have found is that if I use the GCC CDT compiler and startup code, my F429 will enumerate but the same code on the openstm  compiler won't work.  Something is very subtly wrong here with alignment, etc. that I can't find.  

So if your board won't enumerate, here's the hints all in one place:

1) Use HSE_VALUE = 8000000 or 25000000 for the F746 which has a 25Mhz crystal with either PLL_M = 8 for the 8Mhz and PLL_M=25 for the other.  Use PLL_Q = 7 and PLL_N = 336.  This should give you a 48Mhz USB clock.

2) Make sure you stack is and heap are like 0x2000 though this never fixed anything for me.

r

3) Remember that in order to attach to a PC you need to be in device mode otherwise the STM board is expecting devices to attach to it.  I think you can have the board in both modes but never got it working.  This point I'm not really sure of but it makes sense to me.  It won't enumerate if it is waiting for devices as a Host.

4) Check to ensure you are using the correct mode for the USB connector.  Some are FS and some are HS and some are HS in FS mode.  

5) Some boards use an external PHY which means the clocking shouldn't matter.  I stick with the clock settings in (1) above until it works.

6) Make sure your PC drivers are installed.  If you question the drivers, use one of Tilen's precompiled codes on stm32f4-discovery.com site.  By the way, he has a ton of knowledge and has shared it all.

7) Make sure your cable is good.  I was traveling and didn't have a spare and spent a week in a hotel fighting a cable problem I didn't know I had until I got home.

8) I've had the best luck with HAL.

9) Some people have had good luck turning off VBUS sensing.

10) One person in particular wrote about not trying to send prior to having initialization done.  But if you think about it, his board must have been enumerated by the PC already to get to that point.

Lastly, before starting a project with any of these boards, make sure the board exposes the features you need.  I spent a lot of time on a F429 before finding out that one of the DAC lines is used for the display.

So I am about 50% there.  Two of the 4 boards work as enumerated CDC VCP devices.  One of the remaining boards works fine as an HID.  I can't get the F7 board to connect for nothing.

Jerry

[aaron239955_stm1_st]

Posted on December 11, 2016 at 02:01

>>10) One person in particular wrote about not trying to send prior to having initialization done.  But if you think about it, >>his board must have been enumerated by the PC already to get to that point.

This has been the most consistent problem that I have seen and either a 1 second delay on startup, or ensuring that you either wait on user input or do other stuff makes it work.

There is nothing that says your port has to be enumerated before you try to send something to it and I think that the low level drivers do not take this into account.  For example, if the first thing you do in your program, after the init code (which ends with the USB init call) is print a message on the console to the user to tell them what to input, it will fail on many (not all) boards and configurations.  Placing a 1S delay before any USB activity almost always gives it enough time to finish low level init so that the race does not mess up the enumeration and subsequent communication.

This is the case even if the board is not plugged into the USB port when it is powered up, or the program starts working.  As long as it has enough time to finish its internal startup, it will connect later, even if your program had started sending messages.

[Jerry Hancock]

Posted on December 11, 2016 at 03:49

On the boards that are working, I can init and send immediately and the boards enumerate correctly.  You might miss the first several transmissions, but I've never had an issue with sending immediately causing a failure to enumerate on the host, not that it couldn't.

I've tried all type of delays to no avail.  My point is that it shouldn't be this tough.  In all cases, I've generated the code using Cubemx with no transmission at all.  If the board enumerates on the PC, then I continued testing.  I can't get the F7 board to enumerate at all.  I have been successful using the Usart that is connected to the stlink on this board but cant get the board to connect in any mode.  You would think having HS and FS connectors one of them would work.  I'm starting to think there is a problem with the openstm compiler but can;t figure out what it could be.

[Jerry Hancock]

Posted on December 11, 2016 at 05:09

to be complete, someone mentioned trying this before or after the init():

 __HAL_RCC_USB_OTG_HS_CLK_ENABLE();

or

__HAL_RCC_USB_OTG_FS_CLK_ENABLE();

as they mentioned it might not be called. This would be to enable the external PHY clock.

[Mon2]

Posted on December 11, 2016 at 05:49

Hi Jerry. Many thanks for your posts. We are about to jump into this topic with rolled up sleeves next week and did a bit of playing on Friday. Took the STM32F072 DISCOVERY board (features 2 x USB connectors) -> ran the CubeMx Wizard tool and within 30 seconds, had an automatic generated CDC interface enumerated by this target board. The DISCOVERY board enumerated fine on the tested Windows 7 64 bit box using the ST device driver. We did not attempt any data xfers with the evalboard but only wanted to confirm how much of the auto-generated code was functional.

While we do not have plans to use the same target CPU as yours, perhaps you can test out the wizard tool using the STM32F072 target ? We do have assorted USB 2.0 and 3.1 bus analyzers in-house so will do some investigating. Is there a low cost Nucleo board for your target CPU ? Your project demands the F4 target ?

Edit

Jerry - see the post that you do have CDC VCP working but not on the desired target.

Is this the tool you are using for testing ?

http://www.st.com/en/evaluation-tools/32f429idiscovery.html

 

I think we have the same in the lab. Will confirm on Monday for some testing against the Wizard - waiting on some parts (USB breakout boards) to arrive from Digikey and hope they do on time

[aaron239955_stm1_st]

Posted on December 11, 2016 at 14:37

What is an 'openstm' compiler?  do you mean the SW4STM32 compiler?  that is just plain GCC.

[Radek RIPA]

Posted on December 11, 2016 at 16:42

Hello,

The USB library from CubeHAL is using the HEAP for the usb structures allocation.

It is possible that due small heap the stack is not able to allocate the memory and the fails during enumeration. 

Usually in device manager visible vith explanation mark and in details marked with Code 10.

Can you please test this with heap set to bigger value(0x1000 as example)?

Best regards

Radek

[Jerry Hancock]

Posted on December 11, 2016 at 19:30

I set heap and stack to 0x2000 all the time but this never fixed anything. I have it working on two boards, stm32f407 and stm32f469 discovery boards.  Using the original eclipse based GCC toolchain, I was able to get the 407 and 429 boards working.  The same code that runs on the 429 will compile and not run using the Ac6  eclipse (openstm) toolchain.  There is a problem that I can't find.  It has to do wit the startup code I believed but go figure, because I changed that the other day as well and it still doesn't work.  I changed the stack and heap without luck, checked the symbols, etc.  The stmf469 board comes right up with the same cubemx settings.  The STMF746 board I can't get enumerated using the simple cubemx generated code.  I've tried every combination of HS and FS because that board has two user USB connectors.  It just sits there. Clock is correct. There's nothing wrong with the board I don't think as I've had this same problem with the 429 board. 

The point is that we should have very simple demos for this functionality.   Think about the typical application for these boards; hooked to a PC with something on the display. Spending two weeks trying to get a board to connect to a PC is a waste of time. I've been able to get the stlink exposed usart working on the 746 board.  It works fine in HID class mode (moving the cursor demo).  I am switching back to this board because the touchscreen on my stm32f469 board has a wavy nonlinear horizontal detection return.  I'll probably buy another 469 board and develop with it.