STM32G070KBT - Use SPI1 and USART2 (RX Pin Only) At The Same Time

[jwormsley]

I have a project using STM32G070KBT and I laid out the board after making an assumption that may turn out not to be true. I am using all three UARTs, but for two of them, I only need the RX pins. I am also using SPI1 to access an SD card (the board will monitor RX/TX comms and log them to card, the full port is for debug). I use PA1 and PA2 for SCK and MOSI. But PA2 is also the TX for USART2. CubeMX will not let me turn on both USART2 and SPI1 with this pin combination.

Obviously, the right fix is to move MOSI from PA2 to PB5, but the boards have already been built, and cut/patching them would be quite a chore.

Is it possible to enable USART2 but only initialize the RX pin, leaving PA2 to be used by SPI1? I suppose I will have to either forego CubeMxIDE's initialization and do it myself, or have CubeMX initialize SPI1 using PB5, then reinit with PA2 in my user code. Any chance this will work?

Thanks,

Jeff

[waclawek.jan]

> CubeMX will not let me turn on both USART2 and SPI1 with this pin combination.

 > Obviously, the right fix is to move MOSI from PA2 to PB

No. Obviously, the right fix is to ditch CubeMX.

Cube/CubeMX - as inevitably any library and associated clicky do - implements only a fraction of possible functionality, the "most common" functionality. As soon as you depart from "usual", it will get into your way.

JW

PS.

> have CubeMX initialize SPI1 using PB5, then reinit with PA2 in my user code.

> Any chance this will work?

Why not?

[S.Ma]

The chip gives your pin granularity, if say you only need SPI SCK out there, you can. Actually, you can just hack HAL as after HAL init, you can "override" any setup done, so besides a minor config transient change that you can cleanup in the end, you don't need to waste time to get validation of your setup.

Also, some USART allows you to swap RX/TX on related pins (thisi feature is departed from the AF Table, it's within some newest USART cell)

You still need to think application level behaviour:

• Are you sure that there is no electrical conflict between SD Card and the other end of the TX line vs MCU TX ?
• I guess this means that when you write to SD, what the TX's listener will decode ?