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 100pins

cubemx: usb device fs checked

usb:communication device class

PC: windows 10

heap size: 0x200

stack size :0x400

when 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.

[Jerry Hancock]

Posted on December 14, 2016 at 07:14

I think I am out of ideas.  I've been staring at the HID code that works and the CDC code that doesn't and other than the class, I can't find any difference.  I have since found WinUSB hitch would allow me to use this board in HID mode.  I would have to change my communications routines, no big deal, but it should work.  I have the HID code working and it numerate correctly.

i can't see the board entering any interrupt routines in the debugger in CDC mode.  Tomorrow I am going to see if I can get it to stop in HID mode in an interrupt.

I ordered two F7 nucleo boards today to see if they share the same problem.

any other ideas?  Is there anyone from ST on the board that can try creating a device CDC on the 746 discovery with cubeF7?  I realize this project isn't that large, maybe a 1000 chips, but it is big for me!

thanks

[Mon2]

Posted on December 14, 2016 at 11:12

 ,

 ,

Hi Jerry. You have more patience than I.

1) Have you contacted ST using the Technical support ticket system on this topic ? We found them to be quite responsive.

2) To view your case and to expand our knowledge, ordered the STM32F746G-DISCO board from Mouser. This kit should arrive today. We have the Beagle 5000 V2 Ultimate (baby cakes !!) tool and will have happy to place under test using the HID and CDC code generated by the CubeMx tool. No promises on a resolution but can at least log the traffic for these 2 projects and post later today or tomorrow. Today we must first confirm if the USB ROM DFU bootloader is operational on the STM32F070F6P6 to move forward. Then can log these projects.

To confirm, HID works using CN13 on the STM32F746G-DISCO but fails if using CDC code - both auto-generated by the latest CubeMx tool ?

What is the wiring of the USB cable from CN13 to your PC ?

Since the CDC device will not be a host but a device, you will want to remove the Vbus connection for the USB cable to the PC. This is so the evalkit does not send +5 volts to the PC. CN13 is an OTG port so it is intended to act as a host and respectively, power downstream USB widgets. Suppose if you are 100% sure that the load switch @ U16 remains off, you will be also fine. Check the status of pin 4 ( ♯ ENABLE) on U16. This pin 4 should remain HIGH for HID and CDC examples else can be an issue.

Does LD6 turn on (over current) for any of these examples ?

====

Edit:

Or are you using CN12 which is mated with the Microchip USB 2.0 PHY (U15) ?

Same comments apply for the Vbus on CN12. HID works on this CN12 connector but fails with CDC project ?

Review the ENABLE pin 4 on U17 (Vbus load switch is Active High) which should remain LOW to keep this part disabled. Does LD3 turn on to denote a FAULT condition ?

[Jerry Hancock]

Posted on December 14, 2016 at 18:30

No faults or over current.  Somehow, I think, the interrupts aren't being generated.  Also, note dual core CDC is supported.  There is an example for it that I am going to test but I think it works in host mode.

[Mon2]

Posted on December 14, 2016 at 11:41

Oh oh.

According to AN4731 STM32CubeF7 examples document - the CDC examples are not compatible with the STM32F7 DISCO boards. See Table 1. On this note, the HID examples ARE compatible with the STM32F7 DISCO boards.

Your pending STM32F7 Nucleo boards are also not marked as compatible with the CubeMx generated code for USB CDC but HID examples will work.

[Jerry Hancock]

Posted on December 14, 2016 at 16:36

Bhatia,

I thought that table listed what was provided in the libraries, didn't think it would apply to the 746 cubemx generated code.  What could possibly be preventing it from working?  I've tried with/without vbus sensing, etc.

I am going to download the diagrams for both boards (eval and 746) to see what the heck the electrical difference could be.  And yes, i've tried it in HS, HS in FS and FS only modes on all the connectors.  It looks like an interrupt isn't being generated at all for any USB CDC functions.   I put break points all over and they never get hit for CDC but HID they do. I don't understand how that can happen.  It's just firmware that we have almost complete control over, how can they prevent a software protocol stack from working?

Alternatively as I mentioned, I can download the 1GB WinUSB kit and code it in HID bulk mode I guess when I get back to my office.   I need this thing to transfer as fast as possible anyway. Traveling this week and the 1GB download would take forever at a hotel.

And thanks for the help, by the way.

Jerry

[Jerry Hancock]

Posted on December 18, 2016 at 03:56

I bought two more boards, 32F746 and 32F767 Nucleo boards.  Both worked without a hitch in USB OTG DEVICE  CDC modes.  Neither were listed as being supported on the table above.  So right now, the only board I can't get working is the 746 Disco, the board I want to work!  I spent a bunch more hours on it this week and got it generating interrupts when I pulled the cable from the connector.  I finally gave up and just recoded it to use the Stlink exposed uart, which works fine.  I don't know how fast it will go though, but for now it works.

Strange.

Jerry

[Henrik Sandaker Palm]

Posted on January 05, 2017 at 11:29

Jerry,

Thanks for having the patience to both experiment and write about this. It's a very interesting read, especially since information on this particular subject is scarce.

I'm struggling with CDC VCP on STM32F042, which has crystal-less USB, getting the 'device descriptor request failed' error in Windows device manager. I won't ramble about it in your post but when I find out what's wrong I will also post here to help summarize CDC-errors and who knows, it might apply to F7 mcus too.

[es131245]

Posted on March 16, 2017 at 18:31

If you change variable name from hpcd to hpcd_USB_FS you solve problem with stucking in USB_LP_IRQHandler function but USBstill not working

[Wojciech Dera]

Posted on March 27, 2017 at 16:22

I FOUND SOLUTION PEOPLE!!!!

USB HS IS WORKING AND SENDING VIA USB MESSAGES TO REALTERM

I spend all weekend on that but finally

:)

First:

You need to have working VP Drivers froms ST

Second:

1. Create new project in SMTCube. New Project>Board Selector>STM32F46-Disco

2. In Pinout section: RCC>HSE> Crystal/Ceramic Resonator

3. USB_OTG_HS >External Phy > Device Only

4. Clock Configuration Section: HCLK to 216 MHz

5.1 Configuration section: MiddleWares> USB_DEVICE> Class For HS IP> Communication Device Class (Virtual Port Com)

5.2 Open USB_HS Settings in Connectivity and change speed to: Device Full Speed 12MBit/s

6. Generate Project (for me to MDK-ARM V5 Keil)

7. Open Project and try to Build for first time

8. If ok, try to Load to the STM32f7 disco board.

(connect USB HS from board to PC. It should be workind. You should hear the connecting Windows sound.

9. Open Windows Device Menager in COM and LPT Section

10. There should be new STMicroelectronics Virtual Com Port (COMx) with '!' mark. That mean err code 10.

RESET STM Board.

Then:

11. Open main.c file

12. Open usbd_cdc.h file (or search for): change 

CDC_DATA_HS_MAX_PACKET_SIZE

to 64

13. 

Open usbd_def.h file (or search for): change 

USB_HS_MAX_PACKET_SIZE to 64

14. 

Open usbd_cdc_if

.c file (or search for): 

APP_RX_DATA_SIZE to 64

APP_TX_DATA_SIZE to 64

15. RESET STM32f7 Board. You should hear Windows connecting Sound and then in Windows Device menager should be new workind 

STMicroelectronics Virtual Com Port (COMx)

Then Try send something to RealTerm:

16. In main.c add 

#include 'usbd_cdc_if.h' // Plik bedacy interfejsem uzytkownika do kontrolera USB

17. Add some variables

/* Private variables ---------------------------------------------------------*/

uint8_t DataToSend[40]; // Tablica zawierajaca dane do wyslania

uint32_t MessageCounter = 0; // Licznik wyslanych wiadomosci

uint8_t MessageLength = 0; // Zawiera dlugosc wysylanej wiadomosci

18. in main loop add:

HAL_Delay(1000); // important

MessageLength = sprintf((char*)DataToSend, '%s%s', 'WOJTEK IS THE BEST','\r');

CDC_Transmit_HS(DataToSend, MessageLength);

HAL_Delay(1000);

19. Compile and send to STM32f7 Board. Reset Board

20. ITS WORKING!!!!

:)

I hope it will work with your boards! 

If this work click thump up

:)

Pozdrawiam

Wojciech PL

[es131245]

Posted on March 28, 2017 at 13:52

First of all cube projects does work with heap 400 and right connection.

Just check if you have internal USB PHY

[Wanho Noh]

Posted on April 06, 2017 at 04:54

Hi,

Please try this method.

I generated source code with STM32 Cube MX. (

F/W Package Version

STM32Cube FW_F4 V1.14.0

)

Add the following from there.

usbd_cdc_if.c

USBD_CDC_LineCodingTypeDef LineCoding =

 {

        115200, /* baud rate*/

        0x00,   /* stop bits-1*/

        0x00,   /* parity - none*/

        0x08    /* nb. of bits 8*/

 };

CDC_Control_HS ()

    Case CDC_GET_LINE_CODING:

          pbuf[0] = (uint8_t)(LineCoding.bitrate);

          pbuf[1] = (uint8_t)(LineCoding.bitrate >> 8);

          pbuf[2] = (uint8_t)(LineCoding.bitrate >> 16);

          pbuf[3] = (uint8_t)(LineCoding.bitrate >> 24);

          pbuf[4] = LineCoding.format;

          pbuf[5] = LineCoding.paritytype;

          pbuf[6] = LineCoding.datatype;

and change Stack/Heap Size to 0x1500 or higher.

I hope it helps.

[Bill Lewis]

Posted on April 20, 2017 at 22:18

Mine worked only after I plugged directly into the PC without a powered hub.

Correction:  It worked because I unplugged the Ethernet cable.

So there's some sort of conflict between ETH RMII and USB FS.

Update:  The problem was insufficient stack/heap space, and the order of the

initialization calls affected it.

[Ole Ho]

Posted on May 06, 2017 at 16:51

Hello, got the very same problem which killed a few past days.

My uc is STM32F407VGT on the developer board 'discovery'. VCP worked properly, but HID device throwed such errors of inconnectivity: 'Device descriptor request failed' - code 43 in windows.

Resulting problem: CubeMX corrupted settings of RCC. When you use automatic tool in clock configuration settings through the dialog of choosing another clock source(when it picks HSE with PLLs instead of HSI), it sets 'input frequency' at 25 MHz while the correct value for this board is 8 MHz. I honestly don't know how the rest of the project worked (may be not very good, but no desire to compare  at all).

So double-check RCC settings, generated by Cube.

Hope it will help someone.

[softport .]

Posted on January 27, 2018 at 05:22

This turned out to be the solution to my 'Device descriptor request failed' problem as well.

One more thing I would like to add which was also a problem: I had upgraded the software package for STM32F4 (to V1.19), and CubeMX asked if I wanted to migrate the project to the new package, I clicked yes. The usb CDC did not work until I restarted the project from scratch, with the new STM32F4 package.