stm32h7: issue with CONFIG_UART_ASYNC_API=y

[manoj153]

As per the title, I am on an STM32H723 mcu, uart_tx and uart_rx is working fine on application code

setting CONFIG_UART_STM32=y and disabling the async allow the shell to be functional.

What are steps i could possibly do to get the shell work on async_uart?

[erwango]

@manoj153 When setting CONFIG_UART_ASYNC_API, you need to provide a valid configuration for dma channels, do you have that ?

[erwango]

For instance look at: tests/drivers/uart/uart_async_api/boards/nucleo_g071rb.overlay
(this has to be updated for your need based on information from dma bindings)

[manoj153]

yes, I do have them, my uart_rx is working in the async method, which gives an indication it works?

and my logging works on that UART with the DMA setting applied on DT

[manoj153]

additional info about this bug:
With:
CONFIG_UART_ASYNC_API=y

1. Logging works
2. Enabling shell-related cfgs breaks the uart functionality eg: CONFIG_SHELL=y but no error printed, system boots up, print zephyr version and all other user-threads runs, so it seems like something messed the particular UART and caused it not functional anymore. Anyone who understands the shell subsys might able to answer the root cause of this behavior

[erwango]

@manoj153 This could be because SHELL subsys selects UART_INTERRUPT_DRIVEN. Maybe you can have a check in that direction ?

[manoj153]

@erwango okay yes it does select UART_INTERRUPT_DRIVEN, how can I force it to at least use the polling API instead?

[erwango]

@erwango okay yes it does select UART_INTERRUPT_DRIVEN, how can I force it to at least use the polling API instead?

@manoj153 I don't think this something doable. At minimum it would require some shell driver rework.
So I think the assumption should be that shell requires UART_INTERRUPT_DRIVEN.
The question would be: is there a way to get it work with UART_ASYNC_API on top?

Let's ask the shell codeowners: @jakub-uC @nordic-krch.

[manoj153]

I am also thinking if INTERUPT and ASYNC can work at the same time?, that means interrupt uart call API works smoothly

[manoj153]

@erwango, what is the possibility of enabling UART mode per peripheral,

what I am trying to say is that each UART peripheral can be set as ASYNC or INTERRUPT. Is this something achievable?

[erwango]

@manoj153 Indeed, we should be able to have both enabled and use ASYNC on one instance and INTERRUPT on other.
Are you able to demonstrate that this is not working this way?
If yes, is the limitation coming from API or STM32 driver ?

[manoj153]

Yes its not working in this way I can assure that.

Limitations root-cause I have a feeling it's the driver from STM32.

[manoj153]

I have the starting point now, it's because of the way async or interrupt is handled, they are not handled per instance

zephyr/drivers/serial/uart_stm32.c

Lines 1408 to 1421 in ebfe9be

	#if defined(CONFIG_UART_INTERRUPT_DRIVEN) || defined(CONFIG_UART_ASYNC_API)
	config->uconf.irq_config_func(dev);
	#endif
	#ifdef CONFIG_PM_DEVICE
	data->pm_state = DEVICE_PM_ACTIVE_STATE;
	#endif /* CONFIG_PM_DEVICE */
	#ifdef CONFIG_UART_ASYNC_API
	return uart_stm32_async_init(dev);
	#else
	return 0;
	#endif
	}

I am going to think, how we're going to solve this as a whole. Is this a feature request and I shall open a new issue?
@erwango

[erwango]

@manoj153 Let's open a new issue mentioning that UART_INTERRUPT_DRIVEN and UART_ASYNC_API can't be used at same time on different instances

[erwango]

and we can close this one.

[nordic-krch]

just a comment from my side. On nordic drivers it is a per instance choice (e.g. instance 0 can work with async while instance 1 with interrupt driven).

[erwango]

just a comment from my side. On nordic drivers it is a per instance choice (e.g. instance 0 can work with async while instance 1 with interrupt driven).

Yes, I expect to be the case as well on STM32. I know this works that way on SPI.
If not the case on UART, this is a real bug.

[manoj153]

okay closing this and proceeding with a proper issue relating to serial driver