MCU STM32L562: With initialising the UART using HAL_UART_Init() the UART-communication is not working. Calculating the BRR like shown in the reference manual gives a working BRR-Value. Is the HAL_UART_Init() not intended for setting the BRR ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 5:35 AM
The Project was migrated from STM32L4 to STM32L5. The Baudrate setting with HAL_UART_Init() works fine with L4 MCU. With L5 MCU it returns with an HAL_UART_ERROR_NONE too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 6:06 AM
It should set BRR based on the current clocking options. Here it would typically unpack the RCC and PLL settings for clocks and buses.
You could debug or validate it is checking all the right bit​s, and using the right values.
The define for HSE_VALUE can be particularly problematic if wrong.
New STM32 also have more complex peripheral clock sourcing options, check those are being unpacked properly. Library source is available and can be inspected.​
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 6:52 AM
HAL_UART_ERROR_NONE = 0 = HAL_OK.
This indicates there is no error.
What issue are you running into? HAL_UART_Init does indeed calculate BRR based on your current clock settings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 8:02 AM
Thanks for the quick and good comments,
@TDK
The issue is that the UART just did not recognize the incomming Data with a BRR setting of 0x42 (Set by HAL_UART_Init() Call)
Using the Formulaes I got a BRR=0x73 and the UART recognizes incoming Data correct. In this case the BRR ist overwritten after
call of HAL_UART_Init().
@Community member​
HSE_VALUE seems to be the problem. I found a wrong define for this. The problem is not solved yet, but I think I'm on good way.
I was not aware that the calculations could depend on a user define.
Best regards
PKM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 8:15 AM
Well it is how the software knows what external hardware you've added, it doesn't know if you built a system with an 8 MHz clock or a 24 MHz one. It knows what the HSI / MSI are.
Typically in stm32l5xx_hal_conf.h
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-29 8:49 AM
If the HAL function would get as passing parameter the incoming USART clock frequency in Hz would make backtracking simpler.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-30 1:39 AM
Hi,
Problem is solved.
The wrong Definition of the "HSE_VALU"E was as mentionend by clive1 in "stm32l5xx_hal_conf.h", but the file "system_stm32l5xx.c" had to be changed in the same way.
Thanks very much.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-30 5:40 AM
PLL settings would need to reflect board/design
HSE_VALUE you be used here too, but the math/best-fit is more difficult due to the limited options and integers
Up vote any posts that you find helpful, it shows what's working..
