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

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

[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

[Jerry Hancock]

Posted on December 11, 2016 at 19:34

The 32F429 discovery as listed above works in FS in HS mode using Tilen's code from stm32f4-discovery.net.  It doesn't work using the cubemx generated hal code.

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

[Jerry Hancock]

Posted on December 11, 2016 at 19:38

Also don't buy these boards on ebay as they are way over priced.  Cheapest is Mouser in the US.

[Jerry Hancock]

Posted on December 11, 2016 at 20:11

For the STM32F429 board, as I found this morning, the cubemx settings that work are as follows:

1) clear all pinouts

2) RCC - select crystal/ceramic resonator

3) select usb, HS, internal FS Phy, device only, to set HS in FS mode

4) In Middlewares, select USB_device , class for HS IP, Communications device Class

In Clock, and I don't know if this matters, set the cystal to 8Mhz, PLL_M to 8, N to 336, Q to 7 with HCLK 168 and this should set the 48Mhz clock coming off Q to 48.  Since we are using the FS Phy, this shouldn't matter but play with it on your own.

Generate code, with stack 0x4000 and heap 0x2000 compile with openstm and I get an enumerated device.  Could have sworn I did this before about 10,000 times and it didn't work.  Try trimming stack and heap down after it works.  Try bumping the clock up to 180Mhz after it works since the external Phy should have its own clock but I haven't checked the schematic.

Or use the tried and try DLP devices that work every time!

Now if only I could get the F7 working.

Jerry

[Teemu Ikonen]

Posted on September 18, 2017 at 17:55

I can confirm that this works for me on STM32F407 / STM32F4-Discovery. 

My setup

Pins / MiddleWares

USB_Device / Class for FS IP = Communication Device Class..

RCC / HSE = Crystal/Ceramic

USB_OTG_FS / Mode=Device_Only

SYS / Timebase Source = SysTick

(USB_OTG_HS  Disabled)

Clocks

 

As above (PLL_M 8, N 336, P 2, Q 7)

For me the key was setting the 8Mhz and PLL_M=8. CubeMX had for some reason defaulted to 25Mhz / PPL_M=25 that I did not notice.

/Teemu

[Jerry Hancock]

Posted on December 12, 2016 at 00:10

Just to be complete, this morning I made three projects.  HS, HS in FS, FS.  In each I set the heap at 0x2000 and stack 0x4000.   I used clock at 25MHz (remember the crystal on the F7 board is 25Mhz) with M=25, N=336 and Q=7.  This gave me the proper 48Mhz clock. None of the projects caused any reaction on the attached PC. 

I am going back to the schematics to see what is going on since in HS mode it should be enabling the external Phy.  The funny thing is that in HID mode it works so I don't think there is an electrical problem. I've been trying to avoid getting the logic decoder and scopes out.  I don't have a USB analyzer (yet).

I would like to see a sample project from ST that worked with this board.  CDC VCP in device mode.

Thanks.

Jerry

[Mon2]

Posted on December 12, 2016 at 00:33

Jerry - have you seen this post ?

https://github.com/pellepl/verisure1512/tree/master/ext-libs/STM32Cube_FW_F7_V1.2.0/Projects/STM32756G_EVAL/Applications/USB_Device/CDC_Standalone

 

- This application runs on STM32F756xx/STM32F746xx devices.

  - This application has been tested with STMicroelectronics STM327x6G-EVAL RevB     evaluation boards and can be easily tailored to any other supported device      and development board.

/**

* @brief System Clock Configuration

* The system Clock is configured as follow :

* System Clock source = PLL (HSE)

* SYSCLK(Hz) = 216000000

* HCLK(Hz) = 216000000

* AHB Prescaler = 1

* APB1 Prescaler = 4

* APB2 Prescaler = 2

* HSE Frequency(Hz) = 25000000

* PLL_M = 25

* PLL_N = 432

* PLL_P = 2

* PLLSAI_N = 384

* PLLSAI_P = 8

* VDD(V) = 3.3

* Main regulator output voltage = Scale1 mode

* Flash Latency(WS) = 7

* @param None

* @retval None

*/

Would you have the same target evaluation board for testing ?

[Jerry Hancock]

Posted on December 12, 2016 at 01:48

I don't have the eval board for testing.  I have the 746 disco.  I think this is the same code that distributes with the STM7 firmware.  I remember looking at it and wondering why there wasn't an equivalent in the 746 disco library.  I'm looking at it now and will post if it works.  I remember trying to compile that code and realizing that the board support firmware was different or something.

I found a note saying your should run the board from external 5v if you are using OTG.  I just went thru the trouble to confirm this didn't help.

Also, the clock settings above should work because in HS as HS on the 746 disco, it uses the microchip USB PHY so the clock shouldn't matter.  I put my scope on the PHY clock, it is 24Mhz as it should be and the NRESET, I assume is not_reset, is high, which would enable it.  It's interesting that they have the flash latency up at 7.  I'll give that a shot but I am at 5 with a slower clock.

Thank you, everyone, for the help.

Jerry

[Jerry Hancock]

Posted on December 12, 2016 at 20:22

I am still futzing with this problem on the F7.  I've traced them (working/non-working) side by side.  The F7 never goes into the OTG_FS_IRQHandler routine that I can see. I put a breakpoint on it, if that is possible.  I had one interrupt that could have been spurious but otherwise nothing.  I see there is a 'weak' symbol override created by cube, I tried taking that out to see if it made a dif, didn't, so I am still stuck.  

I'm going back to make sure the interrupts stay enabled.