Help with STM32F4 and platformIO

[chintal]

I'm trying out tinyusb with an STM32F407VE on a chinese clone of the Black STM32 F4VE board. I'm using the following from code generated by ST's STMCubeMX :

• STM32F4xx_HAL_Driver, with the include path modified so that stm32f4xx_hal.h is on it.
• CMSIS/Device/ST/STM32F4xx, with the include path modified so that stm32f4xx.h is on it.
• The linker files, startup files, system files, and the hal_config.

I'm not using any of the other code generated by the CubeMX and reimplementing whatever is needed. What I have now is a baremetal scaffold with no RTOS involved.

I'm using platformIO and have cloned the tinyUSB repository into lib/tinyusb. From the cdc_dual example, I've copied tusb_config.h and usb_descriptors.c into the project and modified them slightly. I've added lib/tinyusb/src to the include path (I have not added the hw and lib folders)

I find that the tusb_init function stalls at an assert, specifically, this line in check_dwc2():

  uint32_t const gsnpsid = dwc2->gsnpsid & GSNPSID_ID_MASK;
  TU_ASSERT(gsnpsid == DWC2_OTG_ID || gsnpsid == DWC2_FS_IOT_ID || gsnpsid == DWC2_HS_IOT_ID);

I have since noticed that the cdc_dual example might have issues with this MCU from #299, so I've tried to remove the second CDC interface by modifying the usb_descriptors.c and tusb_config.h.

Any advice getting this to work would be much appreciated. All I want to do is get the USB FS interface on the MCU to provide a VCP to a host computer, and ideally I'd like to do it with as little of the bloat the CubeMX generated code involves.

It would also be helpful if someone could tell me which parts of the hardware tinyUSB will manage by itself. Specifically, the GPIOs will need to configured and the clock should be enabled - where does this happen? I looked at the examples for the STM32F4 boards and the code did not seem to be there - UART and GPIO clocks are enabled but none of the USB resources seemed to be touched, so I presume the initialization is somewhere inside tinyUSB.

[chintal]

I've worked it out.

For anyone looking in the future, tinyusb itself does not seem to do any low level initialization for the STM32F7. The ST HAL function HAL_PCD_Init() was needed to get the USB into a state in which it enumerates, which it now does for me. I have not checked if USBCDC actually works.

Note that unless you're using the whole of the STM32CubeMX generated project, you will also need the HAL_PCB_MspInit and DeInit functions with CubeMX generates in stm32f4xx_hal_msp.c or similar. These are relatively simple functions, though, and not difficult to write your own. They need to init / deinit :

• Clock to the USB peripheral
• GPIOs for Alternate Function
• NVIC for the USB interrupt

Also, the OTG_FS peripheral on the STM32F407 does not support enough endpoints to run the cdc_dual_ports example. Even with the low level init done for 4 endpoints (datasheet maximum), reducing the descriptor and config to one CDC interface was needed to avoid another stall at an assert : TU_ASSERT(epnum < ep_count).

I expect the math is something like 2 endpoints each way are needed for one CDC interface, plus EP0, so I expect there are 2 or 3 unused endpoints which are not enough for a full CDC interface.

Thanks.

[HiFiPhile]

Glad you figured it out, I was thinking the same thing, you can find board specific init files here:
https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32f4