STM32H5 support

[bitgamma]

Related area

Port

Hardware specification

STM32H5

Is your feature request related to a problem?

Is support for STM32H5 planned in future? Couldn't find any discussion in regards and would like to use TinyUSB in a project using that MCU

Describe the solution you'd like

Support for STM32H5, at least in device mode

I have checked existing issues, dicussion and documentation

• [X] I confirm I have checked existing issues, dicussion and documentation.

[BitLoose]

I read that TinyUSB has support for H7-MCUs, so H5 shouldn't be a technical issue. Does anyone have this working on the H7 yet? Maybe there is a code example that could be ported to H5?

[bitgamma]

From what I have seen in the datasheet, it looks like the USB peripheral from the H5 might be the same as that in the G0 family (at least register names seem to match) but I haven't looked in the details yet

[KlemenDEV]

Related: https://github.com/hathach/tinyusb/discussions/2275

Seems packet buffer is same size as G0 too (https://www.st.com/resource/en/application_note/an4879-introduction-to-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf)

[KlemenDEV]

From what I have seen in the datasheet, it looks like the USB peripheral from the H5 might be the same as that in the G0 family (at least register names seem to match) but I haven't looked in the details yet

I have tried replacing G0 with H5 HAL just for a test and also changed:

• manually edited dcd_stm32_fsdev_pvt_st.h to point to stm32h5xx
• changed USB_UCPD1_2_IRQn to USB_DRD_FS_IRQn in dcd_stm32_fsdev.c
• defined "STM32G0" to omit the "USB->BTABLE"

Just by doing these changes, the code compiles and MCU runs. Windows 11 beeps when the USB device (tested on custom STM32H563 board, USB is verified to work in bootloader DFU mode using BOOT0) is inserted. Used msc_cdc_freertos example

However, the following screen is shown:

Here is a snippet from the device manager:

I am quite new to the USB world so I don't know what to look for or what to check next but I am willing to try, help, and test.

---

Using debugger, I can see "tud_descriptor_device_cb" being called, but not "tud_descriptor_configuration_cb" or "tud_descriptor_string_cb"

[KlemenDEV]

Here are logs in log level 3:

and at the end:

[Lotharyx]

Deleted previous comment; managed to make the same changes Klemen describes to get to a buildable codebase. I'll report back as things develop...

[KlemenDEV]

Update: my changes work, the issue described above is due to #1018 as I use Keil (most callbacks don't work out of the box here it seems)

[Lotharyx]

I think I reached the same "built and run" state as Klemen, but nothing happens when I connect the USB cable to the host PC (Windows 10). The tud_descriptor_device_cb callback is not hit. In my case it's a Nucleo board (still H563 chip) that has a Type-C connector for that port. Klemen, does your board use Type-C?

I've started a new discussion here in case I'm pulling this one too far off its original path.

[KlemenDEV]

No, I do not use USB C

[Dolphindalt]

I've reached the same "build and run" state as Klemen on the Nucleo-H563ZI. No USB enumeration. It is a type C. Might be the same board Lotharyx used.

Edit: I solved my issue by adding __HAL_RCC_USB_CLK_ENABLE(); to the main. My Nucleo-H563ZI enumerates over USB C no problem now.

Also, please see #2373 for a working PR with STM32H5.

[sckid1108]

Hey gang, I got STM32H503 with TinyUSB working by removing MX_ICACHE_Init() from main.c (there might be a timing error - see https://community.st.com/t5/stm32-mcus/how-to-use-stmicroelectronics-classic-usb-device-middleware-with/ta-p/599274?lightbox-message-images-613409=61313i4F7537BE778740F2)

Also I had to change the code in "dcd_stm32_fsdev_pvt_st.h" Lines 217 and to 230 USB_DRD_BASE -> USB_DRD_FS_BASE

stm32h5xx_it.c

/**

• @brief This function handles USB FS global interrupt. / void USB_DRD_FS_IRQHandler(void) { / USER CODE BEGIN USB_DRD_FS_IRQn 0 */

/* USER CODE END USB_DRD_FS_IRQn 0 / //HAL_PCD_IRQHandler(&hpcd_USB_DRD_FS); / USER CODE BEGIN USB_DRD_FS_IRQn 1 / tud_int_handler(0); / USER CODE END USB_DRD_FS_IRQn 1 */ }

[Lotharyx]

Hmm. USB_DRD_FS_BASE is not a defined symbol for me, but USB_DRD_FS is (and appears to be a register base address).

However, changing that as well as commenting out MX_ICACHE_Init() didn't help my situation. A breakpoint in USB_DRD_FS_IRQHandler is also never hit, and my computer doesn't react to plugging/unplugging the USB cable.

[sckid1108]

1. stm32h5xx_it.c /**

• @brief This function handles USB FS global interrupt. / void USB_DRD_FS_IRQHandler(void) { / USER CODE BEGIN USB_DRD_FS_IRQn 0 */

/* USER CODE END USB_DRD_FS_IRQn 0 / //HAL_PCD_IRQHandler(&hpcd_USB_DRD_FS); <-- COMMENTED OUT / USER CODE BEGIN USB_DRD_FS_IRQn 1 / tud_int_handler(0); / USER CODE END USB_DRD_FS_IRQn 1 */ }

2. main.c make sure to call MX_USB_PCD_Init();

3. usb.c (see attached)

/* USER CODE BEGIN Header / /*

---

• @file usb.c
• @brief This file provides code for the configuration

•      of the USB instances.
  

---

• @attention
• Copyright (c) 2024 STMicroelectronics.
• All rights reserved.
• This software is licensed under terms that can be found in the LICENSE file
• in the root directory of this software component.
• If no LICENSE file comes with this software, it is provided AS-IS.

---

/ / USER CODE END Header / / Includes ------------------------------------------------------------------*/ #include "usb.h"

/* USER CODE BEGIN 0 */

/* USER CODE END 0 */

PCD_HandleTypeDef hpcd_USB_DRD_FS;

/* USB init function */

void MX_USB_PCD_Init(void) {

/* USER CODE BEGIN USB_Init 0 */

/* USER CODE END USB_Init 0 */

/* USER CODE BEGIN USB_Init 1 */

/* USER CODE END USB_Init 1 / hpcd_USB_DRD_FS.Instance = USB_DRD_FS; hpcd_USB_DRD_FS.Init.dev_endpoints = 8; hpcd_USB_DRD_FS.Init.speed = USBD_FS_SPEED; hpcd_USB_DRD_FS.Init.phy_itface = PCD_PHY_EMBEDDED; hpcd_USB_DRD_FS.Init.Sof_enable = DISABLE; hpcd_USB_DRD_FS.Init.low_power_enable = DISABLE; hpcd_USB_DRD_FS.Init.lpm_enable = DISABLE; hpcd_USB_DRD_FS.Init.battery_charging_enable = DISABLE; hpcd_USB_DRD_FS.Init.vbus_sensing_enable = DISABLE; hpcd_USB_DRD_FS.Init.bulk_doublebuffer_enable = DISABLE; hpcd_USB_DRD_FS.Init.iso_singlebuffer_enable = DISABLE; if (HAL_PCD_Init(&hpcd_USB_DRD_FS) != HAL_OK) { Error_Handler(); } / USER CODE BEGIN USB_Init 2 */

/* USER CODE END USB_Init 2 */

}

void HAL_PCD_MspInit(PCD_HandleTypeDef* pcdHandle) {

GPIO_InitTypeDef GPIO_InitStruct = {0}; RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0}; if(pcdHandle->Instance==USB_DRD_FS) { /* USER CODE BEGIN USB_DRD_FS_MspInit 0 */

/* USER CODE END USB_DRD_FS_MspInit 0 */

/** Initializes the peripherals clock */ PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USB; PeriphClkInitStruct.UsbClockSelection = RCC_USBCLKSOURCE_HSI48; if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK) { Error_Handler(); }

__HAL_RCC_GPIOA_CLK_ENABLE();
/**USB GPIO Configuration
PA11     ------> USB_DM
PA12     ------> USB_DP
*/
GPIO_InitStruct.Pin = GPIO_PIN_11|GPIO_PIN_12;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF10_USB;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

/* USB_DRD_FS clock enable */
__HAL_RCC_USB_CLK_ENABLE();

/* USB_DRD_FS interrupt Init */
HAL_NVIC_SetPriority(USB_DRD_FS_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(USB_DRD_FS_IRQn);

/* USER CODE BEGIN USB_DRD_FS_MspInit 1 */

/* USER CODE END USB_DRD_FS_MspInit 1 */ } }

void HAL_PCD_MspDeInit(PCD_HandleTypeDef* pcdHandle) {

if(pcdHandle->Instance==USB_DRD_FS) { /* USER CODE BEGIN USB_DRD_FS_MspDeInit 0 */

/* USER CODE END USB_DRD_FS_MspDeInit 0 / / Peripheral clock disable */ __HAL_RCC_USB_CLK_DISABLE();

/**USB GPIO Configuration
PA11     ------> USB_DM
PA12     ------> USB_DP
*/
HAL_GPIO_DeInit(GPIOA, GPIO_PIN_11|GPIO_PIN_12);

/* USB_DRD_FS interrupt Deinit */
HAL_NVIC_DisableIRQ(USB_DRD_FS_IRQn);

/* USER CODE BEGIN USB_DRD_FS_MspDeInit 1 */

/* USER CODE END USB_DRD_FS_MspDeInit 1 */ } }

/* USER CODE BEGIN 1 */

/* USER CODE END 1 */

[sckid1108]

Hmm. USB_DRD_FS_BASE is not a defined symbol for me, but USB_DRD_FS is (and appears to be a register base address).

However, changing that as well as commenting out MX_ICACHE_Init() didn't help my situation. A breakpoint in USB_DRD_FS_IRQHandler is also never hit, and my computer doesn't react to plugging/unplugging the USB cable.

Contact me directly if you want me to walk you through getting this running It was a PITA

[Lotharyx]

That's an extremely generous offer. I am going to make an attempt to roll my own USB CDC implementation and eschew tinyusb; if that goes nowhere, I'll be in touch...

[sckid1108]

Yes sir, I do think that tinyusb will work for you and happy to help. I know how frustrating this can be 🙂 M

---

From: Brian @.> Sent: Wednesday, January 24, 2024 12:30 PM To: hathach/tinyusb @.> Cc: Michael Margolese @.>; Comment @.> Subject: Re: [hathach/tinyusb] STM32H5 support (Issue #2203)

That's an extremely generous offer. I am going to make an attempt to roll my own USB CDC implementation and eschew tinyusb; if that goes nowhere, I'll be in touch...

— Reply to this email directly, view it on GitHubhttps://github.com/hathach/tinyusb/issues/2203#issuecomment-1908866481, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AYMHAORNICMX4NQRCKOIO6TYQFVMZAVCNFSM6AAAAAA3COES7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYHA3DMNBYGE. You are receiving this because you commented.Message ID: @.***>

[Lotharyx]

Hi M, I'm not sure how to contact you directly. I followed the link from your profile and filled out the "contact us" form on that site. Is there a better way?

[Lotharyx]

Well, here I am again. It's been a while; the work to try to get this working was shelved for a while. Now it's back on my plate.

What I've done most recently is do a git reset --hard and git pull on my checkout of tinyusb. That seems to have brought in a lot of changes that look like they're meant to provide STM32H5xx support.

I've gone through some example code that @sckid1108 very kindly provided, looking for differences between his and mine, and reconciled as many as I could find.

Now I'm back to square one-and-a-half, it seems; Windows 10 eventually notices that a USB device was plugged in, but then pops up the error that @KlemenDEV screenshotted way back up the thread, along with the Device Manager stating "Device Descriptor Request Failed". (Side note: I have to "Disable" and "Enable" the unknown device entry in Device Manager after unplugging the USB cable to get Windows to realize it's gone.)

The culprit continues to appear to be that the USB FS interrupt isn't firing; a breakpoint in the handler is never hit.

Adding __HAL_RCC_USB_CLK_ENABLE() (as suggested by @Dolphindalt) to my code made no difference. I also traced through parts of tusb_init and observed where it was making the call to enable the interrupt, so it did not seem necessary for me to add my own call to enable it. Frustratingly, the Cube IDE UI keeps freezing up when I try to view the NVIC registers during debugging, so I don't have any insight into whether those have sane values or not.

What do I need to look at to see why those interrupts aren't being generated?

[hathach]

H563 is already supported, tested with stock example on H563 Nucleo. If it does not work for you specify your H5 variant also which board you are tested with.

[hathach]

h563 and h503 are both supported, this can be closed