NUCLEO-H7S3L8 STM32H7RS usbotg_hs <err> usb_dc_stm32: USB pinctrl setup failed (-22) (zephyr 3.6.0) #76305

Sambsc19 · 2024-07-25T21:08:01Z

Sambsc19
Jul 25, 2024

I am trying to get usbotg_hs working on the nucleo-h7s3l8. Other peripherals are working well. Blinky sample timing is correct (gpio's), UART comm's work, but something is wrong in my usb config or the usb_dc_stm32.c driver.

I am running zephyr 3.6.0 and have added the stm32h7rs series and soc's to my 3.6.0 repo (old HW model).

I've created the board for the nucleo-h7s3l8. I've added the hal and pinctrl files for the stm32h7rs

I am testing using the USD_CDC_ACM sample which works on my NUCLEO-U575ZI configured for usbotg_fs.

I am observing USB driver logs via UART and have the following error:

[00:00:00.000,000] usb_dc_stm32: usb_dc_ep_check_cap: ep 0, mps 64, type 0
[00:00:00.000,000] usb_dc_stm32: usb_dc_ep_check_cap: ep 81, mps 16, type 3
[00:00:00.000,000] usb_dc_stm32: usb_dc_ep_check_cap: ep 82, mps 512, type 2
[00:00:00.000,000] usb_dc_stm32: usb_dc_ep_check_cap: ep 1, mps 512, type 2
*** Booting nRF Connect SDK v3.6.0 ***
[00:00:00.001,000] usb_dc_stm32: usb_dc_set_status_callback:
[00:00:00.001,000] usb_dc_stm32: usb_dc_attach:
[00:00:00.001,000] usb_dc_stm32: usb_dc_stm32_init: Pinctrl signals configuration
[00:00:00.001,000] usb_dc_stm32: USB pinctrl setup failed (-22)
[00:00:00.001,000] cdc_acm_echo: Failed to enable USB

I have attached the board files "sam_nucleo_h7s3l8_dk", SOC files "stm32h7rs", dts files "h7rs", and the application "usb_cdc_acm".

I believe the stm32h7s3.dtsi file configuration matches the mcu data sheet STM32_CLOCK_BUS_AHB1 0x40020000:

#include <mem.h>
#include <st/h7rs/stm32h7r3.dtsi>

/*
 * STM32H7S3 line contains the same peripherals as STM32H7R3.
 */
/ {
	soc {
		compatible = "st,stm32h7s3", "st,stm32h7rs", "simple-bus";

		usbphyc: usbphyc@40017c00 {
			compatible = "st,stm32-usbphyc";
			reg = <0x40017c00 0x400>;
			#phy-cells = <0>;
			status = "okay";
		};

		usbotg_hs: usb@40040000 {
			compatible = "st,stm32-otghs";
			reg = <0x40040000 0x40000>;
			interrupts = <74 0>, <75 0>, <76 0>, <77 0>;
			interrupt-names = "ep1_out", "ep1_in", "wkup", "otghs";
			num-bidir-endpoints = <9>;
			ram-size = <4096>;
			maximum-speed = "high-speed";
			// clocks = <&rcc STM32_CLOCK_BUS_AHB1 0x02000000>,
			// 	 <&rcc STM32_SRC_HSE STM32_SRC_PLL1_Q>;

			clocks = <&rcc STM32_CLOCK_BUS_AHB1 0x40020000>;

			phys = <&usbphyc>;
			status = "okay";
		};

	// otghs_fs_phy: otghs_fs_phy {
	// 	compatible = "usb-nop-xceiv";
	// 	#phy-cells = <0>;
	// };
};

I am using app.overlay

/ {
	chosen {
		zephyr,console = &cdc_acm_uart0;
	};
};

zephyr_udc0: &usbotg_hs {
	pinctrl-0 = <&usb_otg_hs_dm_pm5 &usb_otg_hs_dp_pm6>;
	pinctrl-names = "default";
	status = "okay";
};

&zephyr_udc0  {
	cdc_acm_uart0: cdc_acm_uart0 {
			compatible = "zephyr,cdc-acm-uart";
            label = "CDC_ACM_0";
	};

	/*cdc_acm_uart1 {
			compatible = "zephyr,cdc-acm-uart";
	};*/
};

I Believe the clock is correct as previously it the driver init had error that clock was not 48Mhz. Here are the relevant board dts configs (also attached):

 /dts-v1/;
 #include <st/h7rs/stm32h7s3X8.dtsi>
 #include <st/h7/stm32h7s3l8hx-pinctrl.dtsi>
 #include "arduino_r3_connector.dtsi"
 #include <zephyr/dt-bindings/input/input-event-codes.h>
 
 / {
	 model = "STMicroelectronics STM32H7S3L8 DISCOVERY KIT board";
	 compatible = "st,stm32h7s3l8-dk";
 
	 chosen {
		 zephyr,console = &uart4;
		 zephyr,shell-uart = &uart4;
		 zephyr,uart-mcumgr = &uart4;
		 zephyr,bt-uart = &uart4;
		 zephyr,flash = &flash0;
		 zephyr,sram = &sram0;
	 };
 
	 leds {
		 compatible = "gpio-leds";
		 green_led: led_1 {
			 gpios = <&gpiod 10 GPIO_ACTIVE_LOW>;
			 label = "User LD1";
		 };
		 orange_led: led_2 {
			 gpios = <&gpiod 13 GPIO_ACTIVE_LOW>;
			 label = "User LD2";
		 };
		 red_led: led_3 {
			 gpios = <&gpiom 2 GPIO_ACTIVE_LOW>;
			 label = "User LD3";
		 };
		 blue_led: led_4 {
			 gpios = <&gpiom 3 GPIO_ACTIVE_LOW>;
			 label = "User LD4";
		 };
	 };
 
	 gpio_keys {
		 compatible = "gpio-keys";
		 user_button: button {
			 label = "User";
			 gpios = <&gpioc 13 GPIO_ACTIVE_LOW>;
			 zephyr,code = <INPUT_KEY_0>;
		 };
	 };
 
	 aliases {
		 led0 = &orange_led;
		 sw0 = &user_button;
		 uart-0 = &usart3;
	 };
 };
 
 &clk_hsi48 {
	 status = "okay";
 };

//  &clk_hsi {
// 	status = "okay";
// 	hsi-div = <2>;
// };

// &clk_csi {
// 	status = "okay";
// };
 
 &clk_lse {
	 status = "okay";
 };

 &perck {
	clocks = <&rcc STM32_SRC_HSI48 CKPER_SEL(0)>;//STM32_SRC_HSE STM32_SRC_HSI48
	status = "okay";
};
 
 &clk_hse {
	 clock-frequency = <DT_FREQ_M(24)>;
	 //hse-bypass; /* X3 is a 24MHz oscillator on PH0 */
	 status = "okay";
 };
 
// &pll {
// 	div-m = <12>;
// 	mul-n = <250>;
// 	div-p = <2>;
// 	div-q = <2>;
// 	div-r = <2>;
// 	div-s = <2>;
// 	div-t = <2>;
// 	clocks = <&clk_hse>;
// 	status = "okay";
// };

&pll {
	div-m = <2>;
	mul-n = <40>;
	div-p = <10>;
	div-q = <2>;
	div-r = <2>;
	div-s = <2>;
	div-t = <2>;
	clocks = <&clk_hse>;
	status = "okay";
};

&rcc {
	clocks = <&pll>;
	// clock-frequency = <DT_FREQ_M(250)>;
	clock-frequency = <DT_FREQ_M(48)>;
	dcpre = <1>;
	hpre = <1>;
	ppre1 = <2>;
	ppre2 = <2>;
	ppre4 = <2>;
	ppre5 = <2>;
};
 
 &usart3 {
	 status = "okay";
	 current-speed = <115200>;
	 pinctrl-0 = <&usart3_tx_pc10 &usart3_rx_pc11>;
	 pinctrl-names = "default";
 };
 
 &uart4 {
	 pinctrl-0 = <&uart4_tx_pd1 &uart4_rx_pd0>;
	 pinctrl-names = "default";
	 current-speed = <115200>;
	 status = "okay";
 };
 
 &uart7 {
	 pinctrl-0 = <&uart7_tx_pe8 &uart7_rx_pe7>;
	 pinctrl-names = "default";
	 current-speed = <115200>;
	 status = "okay";
 };
 
 &timers2 {
	 st,prescaler = <10000>;
	 status = "okay";
 
	 pwm2: pwm {
		 status = "okay";
		 pinctrl-0 = <&tim2_ch4_pa3>;
		 pinctrl-names = "default";
	 };
 };
 
 &timers3 {
	 st,prescaler = <10000>;
	 status = "okay";
 
	 pwm3: pwm {
		 status = "okay";
		 pinctrl-0 = <&tim3_ch2_pb5>;
		 pinctrl-names = "default";
	 };
 };

If there is anything incorrect there please let me know. Due to the logs above i believe that there is an issue with the SOC/SERIES in the usb_dc_stm32.c driver file. I have attached the driver file which i have already modified to add some #if defined(CONFIG_SOC_SERIES_STM32H7RSX).

Any help or precedence appreciated,
SAM.

usbotg_inquiry.zip

FRASTM · 2024-07-29T12:04:19Z

FRASTM
Jul 29, 2024
Collaborator

The OTG HS node has one global interrupt line 91 and clock domain of the AHB1 register is required for OTGHS and USBPHYC
interrupts = <91 0>;
Then with the USB OTG HS and USBPHYC are enabled. The HSE clock source is the default clock source for the USBREFCKSEL,
clocks = <&rcc STM32_CLOCK_BUS_AHB1 0x06000000>;

2 replies

FRASTM Jul 29, 2024
Collaborator

However that's not enough, since the
samples/subsys/usb/cdc_acm/ running on the stm32h7s78_dk does not detect the cable plugging in USB1 connector

*** Booting Zephyr OS build v3.7.0-rc2-466-gc37192bc9431 ***
[00:00:00.010,000] <inf> cdc_acm_echo: Wait for DTR

(building the next stack with usbd_next_prj.conf exceeds the 64KB flash)

I put a branch for the stm32h7s78 disco : https://github.com/FRASTM/zephyr/tree/stm32h7rs_otg_hs

Sambsc19 Nov 15, 2024
Author

Hi @FRASTM, Thanks very much for the reply. I haven't had time to work on this project in a while. I was able to build the cdc_acm sample as above on my nucleo-h7s3l8. I understand that "building the next stack with usbd_next_prj.conf exceeds the 64KB flash".

I intend to use the SPI flash onboard the nucleo-h7s3l8 (mx66uw1g45) as program space.

My mcuboot repo is at: https://github.com/Sambsc19/mcuboot/tree/frastm_main

My zephyr repo is at: https://github.com/Sambsc19/zephyr/tree/merge_xip_frastm

When I build zephyr\samples\application_development\code_relocation_nocopy everything works. logs:

*** Booting Zephyr OS build v3.7.0-332-gae4fbf386ac5 ***
Address of main function 0x8000685
Address of function_in_ext_flash 0x7001
Address of var_ext_sram_data 0x240000e0 (10)
Address of function_in_sram 0x24000001
Address of var_sram_data 0x240000e4 (10)
Hello World! nucleo_h7s3l8

When I build zephyr\samples\boards\stm32\hello_world_xip using:

west build -p auto -b nucleo_h7s3l8 zephyr/samples/boards/stm32/hello_world_xip --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_FLASH_BASE_ADDRESS=0x70000000

I have:

warning: MCUBOOT_UPDATE_FOOTER_SIZE (defined at subsys/dfu/Kconfig:54) was assigned the value
'0x2000' but got the value ''. Check these unsatisfied dependencies: MCUBOOT_IMG_MANAGER (=n),
IMG_MANAGER (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUBOOT_UPDATE_FOOTER_SIZE and/or look up
MCUBOOT_UPDATE_FOOTER_SIZE in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.

I have logs:

*** Booting MCUboot v2.1.0-123-g4ca09a92cfe6 ***
*** Using Zephyr OS build v3.7.0-332-gae4fbf386ac5 ***
I: Starting Direct-XIP bootloader
W: Failed reading image headers.
E: Unable to find bootable image

I have attached

build logs: "xip_build_logs.txt"
internal flash memory binary (to 0x10000) 0x8000000: "intflash.bin"
external flash memory binary (to 0x10000) 0x70000000: "extflash.bin"

From the internal and external memory read (exported from stm32cubeprogrammer) It seems both internal and external flash have been written to.

I had GPT analyse the binary and the response was as follows:

"Analysis of the Binary File
The analysis reveals the following key details from the first 256 bytes (header) of the binary file:

Magic Number: 0x96f3b83d

This is the expected magic number for an MCUboot-compatible image. It indicates that the image header format is correct and recognizable by MCUboot.
Image Load Address: 0x0

The load address is 0x0, which may indicate an issue. This field should typically point to the memory address where the image is meant to execute.
Image Size: 1024 bytes

This indicates the reported size of the image. Ensure this aligns with the actual binary size and expected partition size.
Raw Header (first 32 bytes for context):

Copy code
3d b8 f3 96 00 00 00 00 00 04 00 00 da 3e 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Observations and Recommendations
Magic Number Validation:

The magic number is correct, indicating that the image format is likely valid.
Potential Issue with Load Address:

A load address of 0x0 might be incorrect. For XIP (Execute in Place) images, the load address should correspond to the location in external flash where the image is stored (e.g., 0x70000000).
Flashing Verification:

The image header being present suggests that the binary was partially written correctly, but there could still be alignment or offset issues."

**I also tried to build directly with your mcuboot and zephyr branches for the stm32h750b_dk with:
west build -p auto -b stm32h750b_dk samples/boards/stm32/hello_world_xip/ --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_FLASH_BASE_ADDRESS=0x90000000

and I had the same footer warning

Please let me know how to resolve this. Also, Will i be able to move forward with my CDC-ACM project using the next stack once I am XIP from SPI flash?**

I can't well enough express my appreciation for your dedication and the availability of your expertise. I certainly am willing to return the favour. My skill set is quite broad ranging from PCB design, firmware, scripting, CAD, CAM, IoT, Mechanical, Installations, and more. I Invite you to PM me.

mcuboot_XIP.zip

FRASTM · 2024-11-18T15:30:14Z

FRASTM
Nov 18, 2024
Collaborator

Let me have a look to your code.
At first, The magic nb is as expected. The extflash.bin is supposed to be downloaded at 0x7000.0000 (with stm32cube programmer) ?
At address + offset 0x400 = 0x7000.0400 you should find your application (linked for this address mapping).

0 replies

Sambsc19 · 2024-11-18T19:30:36Z

Sambsc19
Nov 18, 2024
Author

extflash.bin and intflash.bin were exported from stm32cubeprogrammer. I flashed with stm32cubeprogrammer GUI.

build\mcuboot\zephyr\zephyr.bin @ 0x8000000
build\hello_world_xip\zephyr\zephyr.signed.bin @ 0x70000000

for mcuboot i have overlay zephyr,code-partition = &boot_partition;

for app i have overlay zephyr,code-partition = &slot1_partition;

with DTS:

chosen {
		zephyr,console = &uart4;
		zephyr,shell-uart = &uart4;
		zephyr,flash = &flash0;
		zephyr,sram = &sram0;
		zephyr,flash-controller = &mx66uw1g45;
};

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;
		/* Set the partitions with first MB to make use of the whole Bank1 */
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 DT_SIZE_K(64)>;
		};
		/* Dummy slot0 out of the internal flash area just for sysbuild */
	    slot0_partition: partition@10000 {
	   		 label = "image-0";
	   		 reg = <0x00010000 DT_SIZE_M(32)>;
	    };
	};
};

&xspi2 {
   pinctrl-0 = <&xspim_p2_clk_pn6 &xspim_p2_ncs1_pn1
				&xspim_p2_io0_pn2 &xspim_p2_io1_pn3
				&xspim_p2_io2_pn4 &xspim_p2_io3_pn5
				&xspim_p2_io4_pn8 &xspim_p2_io5_pn9
				&xspim_p2_io6_pn10 &xspim_p2_io7_pn11
				&xspim_p2_dqs0_pn0>;
   pinctrl-names = "default";
   status = "okay";
   mx66uw1g45: xspi-nor-flash@70000000 {
	   compatible = "st,stm32-xspi-nor";
	   reg = <0x70000000 DT_SIZE_M(128)>; /* 1 Gbits */
	   ospi-max-frequency = <DT_FREQ_M(50)>;
	   spi-bus-width = <XSPI_OCTO_MODE>;
	   data-rate = <XSPI_DTR_TRANSFER>;
	   status = "okay";
	   // erase-block-size = <4096>;  // Example value
	   // write-block-size = <4>;
	   partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;
		slot1_partition: partition@0 {
			label = "image-1";
			reg = <0x00000000 DT_SIZE_K(1024)>;  // 1 MB for image-1
		};
		scratch_partition: partition@100000 {
			label = "image-scratch";
			reg = <0x00100000 DT_SIZE_K(64)>;  // 64 KB for scratch
		};
		storage_partition: partition@110000 {
			label = "storage";
			reg = <0x00110000 DT_SIZE_K(64)>;  // 64 KB for storage
		};
	};

   };
};

0 replies

Sambsc19 · 2024-11-18T19:44:40Z

Sambsc19
Nov 18, 2024
Author

from the build log in the zip these warnings stand out:

CMake Warning at CMakeLists.txt:427 (message):
Unable to determine erase size of slot1 partition, cannot calculate minimum
sector usage

C:/Partition_Environments/Pythons/zephyrproject/build/hello_world_xip/zephyr/zephyr.dts:769.24-805.5: Warning (spi_bus_bridge): /soc/xspi@5200a000: node name for SPI buses should be 'spi'
: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'

warning: MCUBOOT_UPDATE_FOOTER_SIZE (defined at subsys/dfu/Kconfig:54) was assigned the value
'0x2000' but got the value ''. Check these unsatisfied dependencies: MCUBOOT_IMG_MANAGER (=n),
IMG_MANAGER (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUBOOT_UPDATE_FOOTER_SIZE and/or look up
MCUBOOT_UPDATE_FOOTER_SIZE in the menuconfig/guiconfig interface. The Application Development
Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual
might be helpful too.

0 replies

FRASTM · 2024-11-19T08:17:17Z

FRASTM
Nov 19, 2024
Collaborator

I also had to add
CONFIG_BOOT_MAX_IMG_SECTORS_AUTO=n
in the ../bootloader/mcuboot/boot/zephyr/boards/nucleo_h7s3l8.conf

*** Booting MCUboot v2.1.0-rc1-124-g9b2a54584e5f ***
*** Using Zephyr OS build v4.0.0-rc3-6-g8860437c7423 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x0
I: Jumping to the first image slot
*** Booting Zephyr OS build v4.0.0-rc3-6-g8860437c7423 ***
Hello World! from external flash  nucleo_h7s3l8

2 replies

Sambsc19 Nov 20, 2024
Author

@FRASTM can you confirm what branch's you are using? I can see from your logs there is a difference to mine. "Starting bootloader" on yours "Starting Direct-XIP bootloader" on mine.

*** Booting MCUboot v2.1.0-123-g4ca09a92cfe6 ***
*** Using Zephyr OS build v3.7.0-332-gae4fbf386ac5 ***
I: Starting Direct-XIP bootloader

FRASTM Nov 20, 2024
Collaborator

@FRASTM can you confirm what branch's you are using? I can see from your logs there is a difference to mine. "Starting bootloader" on yours "Starting Direct-XIP bootloader" on mine.

*** Booting MCUboot v2.1.0-123-g4ca09a92cfe6 *** *** Using Zephyr OS build v3.7.0-332-gae4fbf386ac5 *** I: Starting Direct-XIP bootloader

I have prepared for that:

one branch for the mcuboot: https://github.com/FRASTM/mcuboot/tree/xip_h7s3
one branch for zephyr : https://github.com/FRASTM/zephyr/tree/xip_h7s3
I have build the application with sysbuild :
west build -p auto -b nucleo_h7s3l8 samples/boards/st/hello_world_xip --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_FLASH_BASE_ADDRESS=0x70000000west build -p auto -b nucleo_h7s3l8 samples/boards/st/hello_world_xip --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_FLASH_BASE_ADDRESS=0x70000000
then, I flashed mcuboot at address 0x8000000 and signed hello_world_xip application at 0x70000000 (where i can read the magic nb)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NUCLEO-H7S3L8 STM32H7RS usbotg_hs <err> usb_dc_stm32: USB pinctrl setup failed (-22) (zephyr 3.6.0) #76305

{{title}}

Replies: 5 comments 4 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

NUCLEO-H7S3L8 STM32H7RS usbotg_hs <err> usb_dc_stm32: USB pinctrl setup failed (-22) (zephyr 3.6.0) #76305

Sambsc19 Jul 25, 2024

Replies: 5 comments · 4 replies

FRASTM Jul 29, 2024 Collaborator

FRASTM Jul 29, 2024 Collaborator

Sambsc19 Nov 15, 2024 Author

FRASTM Nov 18, 2024 Collaborator

Sambsc19 Nov 18, 2024 Author

Sambsc19 Nov 18, 2024 Author

FRASTM Nov 19, 2024 Collaborator

Sambsc19 Nov 20, 2024 Author

FRASTM Nov 20, 2024 Collaborator

Sambsc19
Jul 25, 2024

Replies: 5 comments 4 replies

FRASTM
Jul 29, 2024
Collaborator

FRASTM Jul 29, 2024
Collaborator

Sambsc19 Nov 15, 2024
Author

FRASTM
Nov 18, 2024
Collaborator

Sambsc19
Nov 18, 2024
Author

Sambsc19
Nov 18, 2024
Author

FRASTM
Nov 19, 2024
Collaborator

Sambsc19 Nov 20, 2024
Author

FRASTM Nov 20, 2024
Collaborator