Posted on November 07, 2017 at 10:49Hello,I am working on a STM32H743 â€“ NUCLEO 144 and need to use OTG_FS device only option in CDC mode.I generated a project using the stm32cubeMX and have defined: SYS â€“ Time bases : TIM1USB DEVICE â€“ class for FS IP: CDCUSB_OTG_FS - device only, VBUS â€“ disabledThe clock is configured from RC48 to USBLast cube version â€“ 4.23Found 2 problems: The device wonâ€™t enumerate as a serial com port and I cannot see it as unknown device as well (I am talking about CN13).The interrupt OTG_FS_Handler, never fires. So nobody raises HAL_PCD_IRQHandler.As a test, same steps (using the cube) were applied on STM32L496 â€“ nucleo, the L4 board enumerates and works properly as usb OTG.Did someone encountered these problems on STM32H7?What am I missing?Amann.Joerg, I saw your question about the stm32H743 USB, did you manage to run the OTG FS CDC mode?Thanks for the help!null

Marina Brener

Associate III

Question

STM32H743 nucleo won't work in USB OTG FS

Forum|Forum|8 years ago
November 7, 2017
5 replies
5890 views

Posted on November 07, 2017 at 10:49

Hello,

I am working on a STM32H743 â€“ NUCLEO 144 and need to use OTG_FS device only option in CDC mode.

I generated a project using the stm32cubeMX and have defined:

SYS â€“ Time bases : TIM1
USB DEVICE â€“ class for FS IP: CDC
USB_OTG_FS - device only, VBUS â€“ disabled
The clock is configured from RC48 to USB
Last cube version â€“ 4.23

Found 2 problems:

The device wonâ€™t enumerate as a serial com port and I cannot see it as unknown device as well (I am talking about CN13).
The interrupt OTG_FS_Handler, never fires. So nobody raises HAL_PCD_IRQHandler.

As a test, same steps (using the cube) were applied on STM32L496 â€“ nucleo, the L4 board enumerates and works properly as usb OTG.

Did someone encountered these problems on STM32H7?

What am I missing?

Amann.Joerg

, I saw your question about the stm32H743 USB, did you manage to run the OTG FS CDC mode?

Thanks for the help!

null

This topic has been closed for replies.

jamann

Associate II

Posted on November 07, 2017 at 10:58

Yes , working without a problem.

Marina BrenerAuthor

Associate III

Posted on November 07, 2017 at 17:02

Thanks for the fast response, glad to hear that it is working for you!

I downloaded your project for reference, the device is still not enumerated.

I saw you defined a HSE clock, did you add an external crystal source to the nucleo board? Any additional changes you made?

Also, I saw a functions called

HAL_PWREx_EnableUSBReg(), HAL_PWREx_EnableUSBVoltageDetector() in this file stm32h7xx_hal_pwr_ex.h.

D

id anybody use them?

Thanks a lot!

I

Imen.D

ST Technical Moderator

Posted on November 16, 2017 at 15:45

Hello

marina.brener

,

Please add HAL_PWREx_EnableUSBVoltageDetector function call to usb_device.c file. This may resolve your problem.

Best Regards

Imen

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks

KVija

Associate II

Hi All,

Thanks for all your inputs. i have fixed this issue and place in the attachment, Find the fixes in readme file.

STM32H743_USBCDC.7z

AAnt.1

Associate II

Hi @KVija your code work! Thank for it !

I decided to change speed of bitrate for data that transferd, but could,n to see that in code .

Show me, please, place in your code, where i could change bitrate for VCP from 115200 to maximal, like 921300.

Best regards.

Torsten Jaekel

Associate III

Not sure, about which USB VCP we are talking:

The VCP on the ST-LINK debug/power port, which comes from the external chip, via regular UART to the STM MCU: here, it is for instance a UART1 - you have to change the bit rate on the UART1 configuration.
If you ask about the 'native' USB VCP, using the USB stack, with the USB enumerator etc.: actually, you do not need really to change anything, it is 'agnostic' to the bit rate (change it in your host terminal application, e.g. TeraTerm). The USB descriptors do not contain a specification for the bit rate, format (number of bits, parity). Instead, it is a control message coming via USB after the enumeration (see code piece below.

For a "full", native USB VCP (e.g. via the USR USB port):

 case CDC_SET_LINE_CODING:
 linecoding.bitrate = (uint32_t)(pbuf[0] | (pbuf[1] << 8) |\
 (pbuf[2] << 16) | (pbuf[3] << 24));
 linecoding.format = pbuf[4];
 linecoding.paritytype = pbuf[5];
 linecoding.datatype = pbuf[6];
 
 /* Add your code here */
 break;
 
 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;
 
 /* Add your code here */
 break;

You have just to remember what was requested, in order to return it. Or, you could to something with the info. But the data transfer, the VCP bit rate is actually any possible via the type of USB (FS, HS).

If it is the VCP on Debug/Power port - it goes via a real UART, from/to external chip and you had to change your UARTx configuration.