strange USART behaviour

[STM32_Newbbe]

I have a custom board using STM32L4R5ZIT6-P

generic Serial is redirected to USART3 using setTx() and setRx() functions
The output is garbled, characters missing, wrong characters, ...

When I activate USB CDC generic Serial and define a new HardwareSerial for USART3, the output is fine on both serials.

leaving the generic serial as is and only defining a new HardwareSerial for USART3 also produces garbled output

It is the very same hardware, and only adding USB Serial makes output of USART3 correct.

I also added a HardwareSerial USART1, which is also garbled unless I activate USB serial. Then all serial output is fine


When I try these steps on a Nucleo-L4R5ZI (no -P, don't know if that matters??) all is fine.


I really don't have the slightest idea what is going on...

Anyone can eyplain this behaviour?
since it does not happen on a Nucleo-board, maybe it is hardware related?

[fpiSTM]

Are you sure you used USART3? (Which pins?)
You could read the Errata Sheet, they are some point around UART, ex: Data corruption due to noisy receive line.

[STM32_Newbbe]

Hi fpiSTM,

quite sure, thats why I asked over there on the stm32duino github site

I use HardwareSerial StLinkSerial(PC_11_ALT1, PC_10_ALT1);

nevertheless, it also happens on UART4 on those same pins and on USART1 on PA_10 and PA_9

I will have a look at the errata-sheet of the device, thanks!

[dannyf]

if you get the same behaviors on multiple uarts, the code is probably more likely the source of your problem.

[fpiSTM]

Not necessarily as it works fine on nucleo board with same mcu.

[ag123]

for uart, your *baud rates* and line discipline (e.g. 8N1) matters.
for usb (CDC) serial, it doesn't matter, there is no baud rates, it is straight 12 Mbps USB full speeds based on the specs.

so if you are using uart and the other side is not at the same baud rates, all data will be garbled.
for uart, you need to be sure both sides receive and send is at the same baud rates.
autobauding is for 'experts' and I think these days that is a lost art.
the idea is that you detect bit patterns for 'right or wrong' bauds and correct your baud rates based on the bit patterns observed.
when it matches, the pattern e.g. bytes e.g. 0x5a5a should be received correctly

[STM32_Newbbe]

Seems that a not completely wrong clock configuration was the cause of trouble...
Right enough to get everything working somehow but wrong enough to cause the bespoke behaviour

seems I'm learning it the hard way