search

hathach / tinyusb

An open source cross-platform USB stack for embedded system
https://www.tinyusb.org
MIT License
4.85k stars 1.03k forks source link

STM32H5 support #2203

Closed bitgamma closed 5 months ago

bitgamma commented 1 year ago

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

BitLoose commented 1 year ago

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 commented 1 year ago

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 commented 11 months ago

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

image

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 commented 11 months ago

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:

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:

image

Here is a snippet from the device manager:

image

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 commented 11 months ago

Here are logs in log level 3:

image

and at the end:

image

Lotharyx commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

No, I do not use USB C

Dolphindalt commented 9 months ago

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 commented 8 months ago

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

/**

Lotharyx commented 7 months ago

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 commented 7 months ago

1) stm32h5xx_it.c /**

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

3) usb.c (see attached)

/ USER CODE BEGIN Header / /**

/ 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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 5 months ago

h563 and h503 are both supported, this can be closed