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

[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

[CC_ROB]

HSI

[Pavel A.]

Yes so there's a problem with clocks. Need to have external oscillator for USB?

-- pa

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

[Bob S]

Again, the USB buffers are NOT on the stack. See my other post.

Regarding "caring about" the USB specs - The USB spec allows only a small tolerance in clock rates. if the clock driving the USB interface is off, the interface just won't work - similar to UARTS and baud rate clock differences.

[CC_ROB]

 Hello,

After trying the different proposals I am still stopped by the same problem .

 A priori the problem is not due to:

 - an overflow of the heap or the stack because the increase of their allocation did not solve anything

   It should be noted that my program is minimun and does not have recursive user functions

   which could cause the stack to overflow. Simply commissioning test of the CDC and the management of an LED

   Note that the USB Tx and USB Rx buffers of 2048 octes each are not on the stack and the flash is far from saturated.

  -a HARDWARE problem because I was able to load and execute normally other Hex files using USB .

 Moreover, the version 2.13 retrogression did not solve my problem .

 Other investigations:

 Being an amateur model airplane I tried to load a program of the application CLEANFLIGHT using a STM32F4

 This is OMNIBUSF4.HEX

 Loading in my map was done normally as expected with the DFU BOOT0> BOOTLOADER32 procedure

 Once loaded this program could normally use the STMicro VCP COM9 virtual port without any abnormality appearing in the device manager.

 (CLI online order via the VCP)

 I then loaded / executed my program AC6_DIYMORE_CDC.hex thanks to the same procedure.

 At the execution the initial anomaly appeared again and the COM9 STMicro VCP port disappeared in the device manager

 I conclude that the problem is probably due to an anomaly in the USB / CDC libraries provided by ST Micro or in the code generated by STM32CubeMX.

 I enclose the VCP files used by CLEANFLIGHT available on Github. Maybe they will be useful for debugging ....