UART problem on L452RE

[Jonas Chr]

Posted on June 30, 2017 at 13:43

Hello guys,

I am still working on a LoRa node on the basis of a Nucleo board. It seems as nobody knows how the LoRa middelware can be ported, to use for example a SX1272 shield 

https://community.st.com/0D50X00009XkXhMSAV

 . Now I go with the LoRa Soc called Microchip RN2483, which is a very easy to use with ASCII commands via the UART interface. When I try to send ASCII messages to the SoC there ist mostly bit 5 varying and some others are lost. That means, when I just send the same message and look on the stream, every message is different. I have looked on the bits with an oscilloscope, so this might be verified 😉

It seems like there is a problem with the MSI clock, so UART has too much jitter. Does anyone have the same problem and solved it, or any suggestions, what might be wrong?

What I tried and does not help:

1. Used different L452RE boards.

2. I wrote working code on the L152RE board, where messages are send correctly. Put just the sending code on the L4.

3. Put an extern 8 MHz oscillator with two 22 pF on it and configured clock with CubeMX. Maybe I have to spend some more days, to vary setting on that.

Thanks in advance

Jonas

#uart-tx #uartl452re #usart-transmission-jitter #uart-error

[Rob.Riggs]

Posted on June 30, 2017 at 16:46

Which UART are you using?

What bad rate are you attempting to use?

Which clock do you have driving the UART?

Rob

[Jonas Chr]

Posted on June 30, 2017 at 18:37

I already tried UART 1 and 2, in asynchronous mode.

The Baudrate is due to the SoC 57600.

I tried every clock MSI, HSI, HSE (with external 8MHz). But i did it without understanding, or havin that much background of clocks 😉

Jonas

[Tesla DeLorean]

Posted on July 01, 2017 at 03:42

asynchronous serial is pretty tolerant to bit timing error, certainly +/- a few percent.

[Rob.Riggs]

Posted on July 01, 2017 at 05:31

The default HSI value set by STM32CubeMX is incorrect for the L452 part and will keep it from communicating. You need to manually set the following in place of the default '16' that it chooses.

RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;

But if you've tried HSE and MSI, then those should work (assuming that means you are using PCLK1 or PCLK2).

Try setting the above calibration value and then setting the USART clock mux to HSI.

[Tesla DeLorean]

Posted on July 01, 2017 at 20:14

Gross and persistent error in the bit clock, where for example HSI is 2x different from reality, should be apparent on a scope.

The HAL LoRa code has a number of blocking routines which will cause data loss on one or more USART. This stems from a misapplication of interrupts (callbacks), priority, software tickers, and use of blocking code in interrupt context. ♯ WrittenByGeniuses

[Rob.Riggs]

Posted on July 01, 2017 at 21:18

The default value set by the cube for L452 HSI puts it off by about 12.5%.  Enough to break some stuff, not 'blindingly obvious' when looking at it in the scope.  It's amazing how problems with bad code tend to compound.