STM32F407VGTx / CDC / Error Driver

[CC_ROB]

Hello,

I test the CDC with my STM32F407VgTx in an up-to-date environment:

 Windows 10 / STM32CubeMx v5.20 / SW4STM32 / System WorkBench for STM32/ST-LINK V2

The VCP v 1.50 driver for windows 10 has been installed normally and declared active.

The source of the CDC program used is:

\ STM32Cube_FW_F4_V1.24.0 \ STM32Cube_FW_F4_V1.24.0 \ Middleware \ ST \ STM32_USB_Device_Library \ Class \ CDC

When running the program, when init the USB, I get Windows Error 43.

 Unknown USB Device (descriptor request failure).

Can you help me solve this problem?

In advance thank you

Robert

[Imen.D]

Hello,

Try this FAQ: USB device not recognized: to increase the heap size, or configure the USB library to use static allocation.

Hope this helps you.

Regards,

Imen

[CC_ROB]

Hello,

Thank you for the quick reply.

The proposed solutions have not corrected the problem.

I also tried on Windows 7: same problem ...

Regards,

Robert

[Pavel A.]

Try to enable debug prints in the USB library (or set breakpoints) and see what's going. Do you receive requests to read descriptors?

-- pa

[ckoec]

I also have a problem with the usb library (same versions of both cubeMX and the hal library).

The symptom is a harfault happening a few seconds after starting the code in the debugger. Increasing the heap size doesn't change anything.

What is bothering me is that a code that used to work fine with version 1.23 of the library does not work anymore.

Reverting stm32f4xx_ll_usb.c, stm32f4xx_hal_pcd.c, stm32f4xx_hal_pcd_ex.c and their associated .h files to version 1.23 solves the problem.

Does anybody else has this probem ?

Christian

[CC_ROB]

Hello ckoechli1,

    

    Thank you for your reply.

    

    Although the anomaly I see is not exactly the same as the one you mentioned

    I would like to try to compile with version 1.23

    

    Do you know if there is an archive somewhere to recover it ?

Rob

[ckoec]

Hello Rob,

You can download it directly in CubeMX using the help->manage embedded software packages

Then you need to change the firmware location at the bottom of the project manager tab.

I assume that CubeMX still thinks that you are using version 1.24 of the Hal library because I got a compile error with an option of the timer that I wasn't using anyway (and commented out).

It's not a clean solution anyway.

You can also try to only downgrade the 6 files that I mentioned in my earlier post.

I also tried to change the stack size and it didn't solve the problem (I don't understand why ST chose to use the stack to store a buffer).

The problem has to be clock related because I don't have a quartz on my board. I know that it is required by the USB specs but USB is only used for debugging purposes in my case so I don't care about the USB specs.

Hope it helps,

Christian

[Vangelis Fortounas]

Hi

I use the last version 1.24 and works ok.

inside usbd_cdc_if.c the allocation of TX and RX buffer is on Stack and is 2048+2048= 0x00001000

So the Stack must be above 0x1400 (0x400 is the default stack alloc.)

As for the Heap allocation, follow the guide from ST.

Are you use 25 MHZ crystal for HSE?

[Pavel A.]

> inside usbd_cdc_if.c the allocation of TX and RX buffer is on Stack

Are you sure?

-- pa

[Vangelis Fortounas]

Hi

Yes , this is a higher layer buffer allocated by user.

I put a Photo for this in the previous post. Very easy to check.

This buffer is different than in the first answer posted.

I know it seems irrelevant with this case but the uint8_t UserTxBufferFS[APP_TX_DATA_SIZE]; is on stack and as global, allocated first.

So Stack continues growing down and conflicts with upper heap space.

[Bob S]

No, those are NOT on the stack. Those are global variables and are statically allocated by the compiler/linker. A "global" variable cannot be "on the stack", because data on the stack is not permanent, it disappears when the function exits. You can have a global pointer point to data on the stack, but that is a recipe for a world of hurt.

[CC_ROB]

Hello,

Thanks to Pavel and Vangelis for their help

That's where I am:

I still have the driver problem initially described.

I increased the size of the stack beyond 1400..3000 without result.

I use 26MHz crystal and I have modified Clock Init

The anomaly fires when MX_USB_DEVICE_Init () is executed

 and the following functions (see CONNECT.PNG)

at the execution of USBx_DEVICE-> DCTL & = ~ USB_OTG_DCTL_SDIS the program manager

"Device Descriptor Request Failed" Appears

I added Trace tools in the console (see DBG_Trace.c / DBG_Trace.h)

 but I do not know how to debug the Driver and trap requests for descriptors proposed by Pavel.

[CC_ROB]

Connect picture

[CC_ROB]

DBG_Trace Utilities

[Vangelis Fortounas]

hi

I tried last version drivers with 16 Mhz sysclck from HSI (as yours) and enumerates ok.

I suspect that USB clock isn't 48 Mhz ( In posted IOC file the XTAL freq is 25 MHZ and you use 26 MHz.)

[CC_ROB]

Thank you evangelis.

With my 26Mhz crystalI have a 48Mhz USB clock

(It is possible to type 26 in the HSI line of configurator)

With the 16MHz HSE clock it is impossible to have the 48 MHz USB clock with the STM32CubeMx configurator.

If you have succeeded otherwise can you send me the code, I would like to see if it works at my place ...

In advance, thank you

Robert