STM32CubeMx warning when using 4 UARTs

[jerome2]

Dear all

I'm using STM32G070KBT in my product, as it has 4 UARTs.

I want to use the 4 UARTs in asynchronous mode, no HW control, UARTs 1 and 2 use RX/TX, while UARTs 3 and 4 use only RX.

When defining all those UARTs in STM32CubeMx, I've some warnings that I do not understand.

USART1 : PA9 and PA10

USART2 : PA2 and PA3

USART3 : PA5 and PB9

USART4 : PA0 and PA1

- First warning is on USART2, Asynchronous mode conflicts with UART4 asynchronous mode, I cannot see in datasheet and other docs a limitation about using those 2 UARTs in async mode, this waring is yellow flagged.

Another red flagged warning for this UART2 is observed in front of HW control, even if it is configured as disabled.

Second warning is on USART3, While HW control is disabled, I still see a conflict with another GPIO PA6 used for another purpose. Why do I observe a conflict here when HW flow control is disabled ?

Thanks for any help.

[Pavel A.]

You can ignore these warnings as long as the Cube allows you to configure the UARTs with features that you need.

[Ghofrane GSOURI]

Hello @jerome2​ 

First let me thank you for posting.

Actually the first warning is generated by CubeMX as a precaution( due to the fact that both UARTs are using the same pins or that they share some other resource that is required for asynchronous operation), and that it doesn't actually prevent you from using UART2 and UART4 in asynchronous mode.

The second warning you're seeing, regarding USART3, may be related to a conflict between the pins that you've configured for USART3 and another peripheral or functionality that is using the same pin. Since you've disabled hardware flow control for USART3, it is unlikely that the conflict is related to flow control, but it may be related to other functionality of the pin, such as being used as an input or output.

It might be useful to double-check the pin configuration for each UART and make sure that the pins that you've selected for each UART are not being used for any other purpose or conflicting with any other peripherals.

Thx

Ghofrane

[jerome2]

Thanks for your answers.

If I disable HW flow control for an UART, I assume the GPIOs that were dedicated to HW control become "Free" and could be used as a normals GPIOs in or out ? I do not understand why STM32CubeMx mentions a conflict in that situation, when HW flow control is disabled.

Also, my plan is to use UARTs 3 & 4 with RX only. It seems I still have to define TX pins for those UARTs, even if I configure them as RX only, does this mean I cannot use TX unused UART pins for other purpose (normal GPIOs for instance) ?

Thanks again

Jerome

[Ghofrane GSOURI]

Hello again @jerome2​ 

When you disable the hardware flow control for an UART, the pins that were being used for that purpose should become available for use as general-purpose input/output (GPIO) pins

Regarding the warnings in STM32CubeMX, the software may still generate warnings about potential conflicts even when hardware flow control is disabled because it doesn't know what the future intentions of the user with those pins are, and thus can't assume that they will be available for use as general-purpose I/O pins.

Regarding the use of UARTs 3 and 4 in RX-only mode, you still need to define the TX pin even if you don't use it, this is because the UART peripheral needs to be configured with both a RX and TX pin even if you only plan to use one of them.

Thx

Ghofrane

[gbm]

The above is not exactly true. You may configure UART for only TX or only RX, it's just the CubeMX is too dumb for such a simple thing. You may easily achieve this by writing your code by hand instead of geting it generated by CubeMX.

[waclawek.jan]

> CubeMX is too dumb for such a simple thing

With a bit of exaggeration, and putting it deliberately in a provocative way, it's not CubeMX which is dumb, but the expectations placed towards it are.

​There is almost infinite number of usage cases and Cube/CubeMX inevitably implements one a miniscule fraction of it, whatever the authors deem to be "usual". However simple a particular option may seem, if it's not "usual" there's no reason (read: no budget) to implement it.

Main problem is that users these days are educat​ed (formally or otherwise) to expect configurators and "libraries", rather than documentation and examples; without being told the above principal fallacy of the former. When they figure that out themselves is usually to late and they resort to salvaging the work already done, resulting in less than optimal solutions, to put it politely.

JW​