STM32L412 Nucluo64 - garbage data sent from UART

[simo zz]

Hello,

I am working with the evaluation board STM32L412 Nucluo64, but I noticed that the MCU sends only garbage from UART.

The code I am using has been used many times in other projects and should work fine (it's just a matter of calling LL_UART_TransmitData8 and wait for transfer complete).

Just tested on a STM32L4 Nucleo (STM32L432KC), same setup for both boards and works fine.

Do someone has an idea of what could be wrong ?

Thanks.

s.

[Vangelis Fortounas]

Hello

STM32L412 NUCLEO uses 8 MHZ Clock from STLink as HSE

STM32L432KC NUCLEO uses 25 MHZ XTAL osc

[Tesla DeLorean · Accepted solution]

Are you sure it uses a 25 MHz XTAL? Should use 8 MHz from ST-LINK or 32.768 KHz from LSE XTAL

Check HSE_VALUE define, and if you're using the MSI or HSI clock sources.

Availability and quality of baud rates will depend on available source clock.

[simo zz]

Hello @Vangelis Fortounas​ ,

I think I don't understand at all your reply.

Nucleo64 jumper SB64 is open by default

 

The schematic correctly represents the real hardware connection.

HSI clock @16 MHz can be used with the PLL and getting a wide range of sys clock frequencies, smaller or greater than 25 MHz.

Using LL drivers, once set up the oscillator, the baudrate divider is automatically calculated into the function

LL_USART_SetBaudRate

called from

LL_USART_Init

What should be the difference from one clock frequency to another if both can achieve a correct divider for baudrate = 115200 ?

Thanks.

s.

[simo zz]

MSI clock seems to work fine.

Thanks fot the hint.

s.

[Vangelis Fortounas]

Hello, I was completely wrong about clocks. ( checked wrong schematics)

[Vangelis Fortounas]

Hello .About the clocks , i was wrong(checked wrong schematics).

> What should be the difference from one clock frequency to another if both can achieve a correct divider for baudrate = 115200 ?

The difference is in the the Freq drift over the whole temperature range.

The most accurate clock source has the less probability to produce Frame Errors