cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 nucleo won't work in USB OTG FS

Marina Brener
Associate III
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:

  1. SYS – Time bases : TIM1
  2. USB DEVICE – class for FS IP: CDC
  3. USB_OTG_FS - device only, VBUS – disabled
  4. The clock is configured from RC48 to USB
  5. Last cube version – 4.23

Found 2 problems:

  1. 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).
  2. 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
11 REPLIES 11
jamann
Associate II
Posted on November 07, 2017 at 10:58

Yes , working without a problem. 

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!

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

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
Posted on May 09, 2018 at 23:19

Yeaaaah, this was the issue for me as well:

Having VBUS pin configured but not doing this 

HAL_PWREx_EnableUSBVoltageDetector() call - USB will not do anything (except one interrupt to reset USB device). Maybe obvious in device mode with VBUS monitor.

Thank you.

BTW:

yes, all data on DTCM cannot work (DMA has no access). I placed all my data on RAM_D1. Even caches enabled and not doing cache maintenance it works fine: USB is enumerated and my audio recording device works on PC. Cool.
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.

CChen.11
Associate

Blocked by this bug for couple days until I found this thread. Great job guys!

Volker Bremauer
Associate III

Thank's so much, had the same problem.

😀

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.

Not sure, about which USB VCP we are talking:

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