It's possible to make work USB-OTG and USART1 in the same device (STM32MP157CAC)?

[areify]

Hi everyone.

I have an already-designed PCB with an STM32MP157 on it. In order to communicate with an external device, I am using USART1. At the same time, I'm using an USB OTG port to connect my device to my PC.

My problem is that USART1 is working with pins PA10 (AF7: USART1 RX), PA12 (AF7: USART1 DE) and PB6 (AF7: USART1 TX). It seems that PA10 is also set up as OTG HS pin:

usbotg_hs_pins_a: usbotg_hs-0 {
				pins {
					pinmux = <STM32_PINMUX('A', 10, ANALOG)>; /* OTG_ID */
				};
			};

(in stm32mp157-pinctrl.dtsi).

I am not sure at all but I think this pin is not referenced at any device tree file in the whole DTS. However, if I disable usb-otg device, USART1 starts working.

But I don't want to do that.

So after reading the usb-otg driver documentation I discovered the following parameter:

dr_mode: shall be one of "host", "peripheral" and "otg"

So I set up my otg as "peripheral" and now my usb otg works when I connect the external device to my USART1. But USART1 still not works.

What am I missing? I also tried deleting node usbotg_hs_pins_a in pinctrl and property pinctrl-0 in usbotg_hs.

My device tree topology is next: I am using a .dts file which includes stm32mp157a-dk1.dts. And I've redefined usbotg_hs node as:

&usbotg_hs {
        /delete-property/ extcon;
	dr_mode = "peripheral";
};

Thank you in advance.

[areify]

@PatrickF​ Just to know... it would exist any solution to this avoiding to update the ecosystem? This is a consolidated and long-timed development and it would be 'traumatic' to change the ecosystem. Thank you in advance.

[PatrickF · Accepted solution]

Hi,

Ecosystem v1.0.0 is really outdated (we are using v3.0.0 as of today). At least you should switch to v1.2.0, this might not break your existing development (anyway v1.2.0 is still no more supported by ST deliveries, so, any community patches not in this version should be added by your own).

For information, wiki archive for ecosystem v1.2.0 is here : https://wiki.st.com/stm32mpu-ecosystem-v1/wiki/Main_Page

I'm not a SW expert, so I can just give you few HW hints on your issue.

Enabling OTG_ID (which sound be the case for you) is using OTG_GCCFG.IDEN bit =1. This enable will take precedence over any GPIO AFMUX setting on PA10 (USART1 RX in your case) which explain why you did not receive UART data.

OTG_ID pin control is disabled with OTG_GCCFG.IDEN=0.

Regards,

[PatrickF]

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'