Simplest possible CubeMX USB app fails to enumerate

Gavin Baker · ‎2017-10-19

Posted on October 20, 2017 at 07:13

I have a brand-new STM32F303 Nucleo144 and cannot get any CubeMX generated apps to work with USB. The app builds and runs fine, and I can see printf output via SWO, but the device never evenbegins enumeration. The following procedure was used to develop a minimal reproducible example:

Start new project in CubeMX

Select Board Selector, Type of Board: Nucelo144, MCU Series: STM32F3, Board NUCLEO-F303ZE

Under RCC, select HSE = Bypass Clock Source

Under USB, select Device(FS)

Under USB_DEVICE, Class for FS IP: Human Interface Class

Select Clock Configuration tab, allow autoconfiguration, ensure USB clock is correctly set to 48MHz

Go to Project Settings, changeMinimum Heap Size to 0x400, Minimum Stack Size to 0x800

Choose toolchain to be Makefile (using GCC-ARM for Windows)

Save file, Generate Source

Edit main.c to insert some trivial test code (such as the `USBD_HID_SendReport` sample in the 'STM32 USB in 10 Minutes' video)

Run make, verify build success

Using ST-Link Utility, flash bin file onto device

Observe the tragic lack ofUSB enumeration (evenno 'Unknown Device')

Plugging and unplugging the device's user USB port does nothing on the PC - not even showing an unknown device. Device Manager does not attempt a refresh (which is visually quite noticeable) when you plug in the device. So the failure is at a very early stage, perhaps not even beginning to enumerate. This leads me to suspect perhaps a clock or interrupt issue.

I have tried many fixes, including the following changes, and nothing helps at all:

Set heap and stack to much higher values

Set explicit priorities for SysTick and USB in NVCC (higher and lower)

Set HSE to crystal (rather than bypass, which it should be according to the docs)

Switch to using CDC and MSC classes

Use or disable FreeRTOS

Comment out SysTick handler

I also tried starting from scratch and following along with the official STM tutorial as shown in this video:

https://www.youtube.com/watch?v=XRocqTfUxbo

But that didn't work either. Thinking perhaps there was some faulty hardware, I tried another board. Still nothing. I've tried nearly every suggestion I could find in the forums.

TheUSB HAL code that ships with theSDK is not actually generated by CubeMX (and doesn't have gcc Makefiles) so it's not really that useful.

So is there a minimalist USB example that is actually generated from CubeMX that actually works?

Thanks -

:: Gavin

https://community.st.com/tags#/?tags=stm32%20cubemx

‌

https://community.st.com/tags#/?tags=usb

‌

#stm32-cubemx #usb

Note: this post was migrated and contained many threaded conversations, some content may be missing.

Ben K · ‎2017-12-21

Posted on December 21, 2017 at 18:08

As long as the USB peripheral of the device has the DPPU bit in the BCDR register, external pull-up resistor isn't necessary. The F0 line has this, so your problem is rooted somewhere else.

Gowree K · ‎2018-01-09

Posted on January 09, 2018 at 15:24

Ben,

I have taken USB CDC sample code from stm32cubef0 and modified for STM32F070RB and tried in NUCLEO-F070RB. Now i am seeing USB enumeration and it is coming under ports. When i flash same code on development board, USB enumeration is not happening. When we cross verified schematics with nucleo booard, we are not seeing any difference for USB section. is there any bootloader difference will be there from controller what we get from STM and nucleo board? or any other extra configuration needed in code specific to development board

Ben K · ‎2018-01-09

Posted on January 09, 2018 at 17:28

Does the dev board have the same type of MCU on it as the Nucleo?

There is a quite simple way to check if the physical USB connection is correct: pull BOOT0 high so the device enters system memory boot mode. This mode provides a USB DFU interface which should be detected by the PC.

Generally these steps should be followed to detect trivial errors in USB setup:

1. The Reset interrupt is not generated by the USB upon connection (with D+ pullup active)

→ physical line problem

2. The Setup interrupt is not generated

→

USB clocking issue

3. The device doesn't enter configured state, stays in addressed

→

either device software or PC side driver issue (e.g. invalid descriptor)

Gowree K · ‎2018-01-09

Posted on January 09, 2018 at 18:13

Dev board is having same MCU as Nucleo board.

Do we need pullup for this controller?

Without enabling pullup, same code is working fine in Nucleo board.

Software level do we need to have any changes in code from nucleo board to dev board.

Ben K · ‎2018-01-10

Posted on January 10, 2018 at 10:23

Do we need pullup for this controller?

I have answered this

https://community.st.com/0D50X00009XkXRtSAN

.

Software level do we need to have any changes in code from nucleo board to dev board.

Since the pins are mapped identically, you only need to adjust your system clock settings.For USB you better be using HSE clock source (since HSI48 isn't available in F070), make sure the PLL output is 48 MHz.

Gowree K · ‎2018-01-10

Posted on January 10, 2018 at 16:05

Do we need external oscillator?

I have used below code to generate PLL as 48MHz.

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6;

RCC_OscInitStruct.PLL.PREDIV = RCC_PREDIV_DIV1;

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

/**Initializes the CPU, AHB and APB busses clocks

*/

RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

|RCC_CLOCKTYPE_PCLK1;

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_USB;

PeriphClkInit.UsbClockSelection = RCC_USBCLKSOURCE_PLL;

if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

But the same code is working fine in F070 nucleo board. That is the reason i am not able to differentiate issue.

pototschnig · ‎2023-09-24

6 years later, CubeMX still does the same mistake for L1