Peripheral in conflicts with others

SMusc.1 · ‎2025-06-04

Hello everyone, I have the following question: when, as in the attached image, you see a peripheral like the USART1 in yellow (in conflict with other peripherals), is it still possible to use it? I ask this information because I am looking for a NUCLEO card that best meets my specifications and I want to avoid buying a card for which I can not use the peripherals I need to the fullest.

Andrew Neil · ‎2025-06-04

With any interface on any board, you need to check that things on that board won't interfere with what you intend to do.

Common things which could interfere:

Switches (buttons)
LEDs
ST-Link VCOM (Virtual COM port)
USB
Ethernet
Displays
etc, etc, ...

The way to check is in the board's User Manual and the Schematics - which can be found on the Product Page

The attraction of Nucleo boards is that they tend to have minimal "extras" - so you get maximum choice of what pins are free to use.

But, rather than just saying "I want to use USART1", a better approach may be to say "I want to use a USART" - and then look for which USART(s) is/are free ...

This is not specific to STM32 or even ST - the same arises with any microcontroller

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

View solution in original post

mƎALLEm · ‎2025-06-04

Hello,

The Yellow color (AFAIK) means you can use partially the peripheral / in certain mode with that "conflict".

Red color you cannot use it at all with that "conflict".

You need to pass the mice cursor over the colored background and see what message is showing and what conflict it presents.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Andrew Neil · ‎2025-06-04

@mƎALLEm wrote:
Red color you cannot use it at all.

Can't be used simultaneously - but, depending on the application, it might be possible to reconfigure at run time so that one is used at a time as required ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Ozone · ‎2025-06-04

IN addition to the comments already posted, it looks like the IDE config tool tells you the selection of UART pins conflict with another, here probably USB.

Many peripherals (like UART) have several GPIO routing options which you can choose alternatively (or even simultaneously). In this case, review the data sheet for respectiva "alternate GPIO functions" and check for another option.

More complex peripherals like USB, ethernet or external busses (parallel memory, LCD) use to have few or no alternatives.

mƎALLEm · ‎2025-06-04

@Andrew Neil wrote:

@mƎALLEm wrote:

Red color you cannot use it at all.

Can't be used simultaneously - but, depending on the application, it might be possible to reconfigure at run time so that one is used at a time as required ...

Indeed but that requires the user needs to reconfigure the peripheral each time he switches from a peripheral to another. But in some cases even it's possible in software that's not possible from hardware stand point to due to the hardware constraints of the application itself i.e. the external components that induce some conflicts..

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

LCE · ‎2025-06-04

UA(S)RT is a good example:

it is yellow, because you might not be able to use all IOs for synchronous operation, but still the common async. 2-pin version.

That is IMO the best use case for CubeMX: not for generating (more than basic init) source code, but to find out which peripherals might block each other because of the multiple alternate functions on the GPIOs.

SMusc.1 · ‎2025-06-04

thanks everyone. One last question. If I disable the USB_OTG_FS device to keep the USART1 device fully operational, what problems could I run into?

Andrew Neil · ‎2025-06-04

If it's on a Nucleo board, make sure that there aren't components (eg, related to USB) fitted to those pins which would interfere with UART operation.

Or just reconfigure UART1 to use different pins.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

mƎALLEm · ‎2025-06-04

@SMusc.1 wrote:

thanks everyone. One last question. If I disable the USB_OTG_FS device to keep the USART1 device fully operational, what problems could I run into?

As I answered @Andrew Neil , this is not only a question of software but also a question of hardware, you need to check if the USB external components don't interfere with USART signals that you will use.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

SMusc.1 · ‎2025-06-04

Configuring UART1 on different pins is fine, but I didn't understand the first answer. Could you be more specific or give me some more detailed examples? For the board I use: nucleo-u575zi-q, for now I'm only interested in working on timers, ADC, USART. Can I therefore safely disable the USB-related pins?