cancel
Showing results for 
Search instead for 
Did you mean: 

Nucleo-L433RC-P garbage from USARTs - why?

kiwironnie
Associate III

Using STM32CubeIDE to create a USART test project with default code generated, the USART is outputting garbage e.g. �)���?�+Ѵ# on a terminal (USB to PC).

Yet using exactly the same default code generation process and same simple test code on two other Nucleo boards Nucleo-L432 and Nucleo-L073RZ a "hello world" test string is printing fine.

Have tried various configuration changes, to clocks etc on the L433RC to no avail.

Have checked the output with a logic analyzer, which shows the same garbage. Have played with baud rates, word length etc to no avail.

Exactly the same problem with USART2 and with USART1. Strangly, carriage return and line feed are being output correctly as 0D and 0A (which is a pretty good indicator that baud rate etc is ok). The garbage ASCII is generally the same hex output but sometimes varies.

The main test programme is very simple. Default setup code generated by STM32CubeIDE plus the following:

#include <stdio.h>

#include <string.h>

char message[] = "Hello World\r\n";

HAL_UART_Transmit(&huart2, (uint8_t*) message, strlen(message), 10000);

HAL_Delay(1000);

Other functions on the board seem to be fine, e.g. comparators, DAC output etc. Going nuts! Is there anything else that might be worth trying?

1 ACCEPTED SOLUTION

Accepted Solutions

There have been issues with Cube-generated code setting incorrectly the HSI trim (https://community.st.com/s/question/0D50X00009XkfHp/erroneous-hsi-default-trim-value-in-datasheetcubemx https://community.st.com/s/question/0D50X00009XkfyS/stm32l452ceu6-hsi-problem posts were mingled by the botched migration between forum softwares, recently https://community.st.com/s/question/0D50X0000BYocRMSQZ/stm32h7-64mhz-hsi-is-off-by-4 ).

I personally wouldn't rely on an internal RC oscillator for UART at all, but YMMV. And I don't use Cube.

JW

View solution in original post

17 REPLIES 17
S.Ma
Principal

Are you using the usb to usart function of stlink? Start debug by sending a brief rom pattern and use oscilloscope.

kiwironnie
Associate III

Darn, it was the baud rate. The USART configuration is set for 115200 but the actual rate from logic analyser turns out to be 128000. Must be a clock issue, perhaps an STMCubeIDE setup bug of some sort for that mcu as the clock was left on STMCubeIDE default configuration. To set a baud rate of 115200 the baud rate in STM23CubeIDE needs to be set to 102400 (12800 difference). A pre-scaler calculation bug maybe. Will need to investigate further.

What is the primary clock source?

Read out and check/post the related RCC registers content.

JW

kiwironnie
Associate III

Hi Jan

Thanks for your reply. The default clock state primary source is HSI . PLL is applied to run all peripherals at 80MHz. Not yet checked the RCC register contents to confirm it has been written correctly. The USARTs use PCLK1 and PCLK2 as default. If the primary clock source is changed to MSI (peripherals at 4MHz) the baud rate problem goes away. With HSI primary, PLL off, the problem remains. Will need to check the register as you suggest as it appears that the values being generated there could be wrong don't you think?

RMcCa
Senior II

I had this problem when switching from the hsi to an external clock at the same frequency. It was a bit of head scratcher as the clocks were all the same but the com port no longer worked. I fixed the problem by calculating the baud rate register value myself. I later found the cause of the problem was a #define in the hal code, one of the many reasons i don't use it anymore.

There have been issues with Cube-generated code setting incorrectly the HSI trim (https://community.st.com/s/question/0D50X00009XkfHp/erroneous-hsi-default-trim-value-in-datasheetcubemx https://community.st.com/s/question/0D50X00009XkfyS/stm32l452ceu6-hsi-problem posts were mingled by the botched migration between forum softwares, recently https://community.st.com/s/question/0D50X0000BYocRMSQZ/stm32h7-64mhz-hsi-is-off-by-4 ).

I personally wouldn't rely on an internal RC oscillator for UART at all, but YMMV. And I don't use Cube.

JW

S.Ma
Principal

If we can set the baud rate and put the usart frequency in hz as passing parameter, then things get more under user control. using hsi only depends on baudrate and hsi tolerances, this can be calculated.

Thanks again Jan. Brilliant.

Your second reference  https://community.st.com/s/question/0D50X0000BYocRMSQZ/stm32h7-64mhz-hsi-is-off-by-4 provided the answer in this case.

In stm32l4xx_hal_rcc.h line 208:

#if defined(RCC_ICSCR_HSITRIM_6)

#define RCC_HSICALIBRATION_DEFAULT 0x40U /*!< Default HSI calibration trimming value 64 on devices other than STM32L47x/STM32L48x */

#else

#define RCC_HSICALIBRATION_DEFAULT 0x10U /*!< Default HSI calibration trimming value 16 on STM32L47x/STM32L48x devices */

#endif /* RCC_ICSCR_HSITRIM_6 */

0x40U is incorrect and corresponds to the amount by which the baud rate was out. It should be 0x10U i.e. with RCC_ICSCR_HSITRTRIM6 undefined

Then in stm32l433xx.h line 9380:

#define RCC_ICSCR_HSITRIM_6 (0x40UL << RCC_ICSCR_HSITRIM_Pos) /*!< 0x40000000 */

This code is generated by STM32CubeIDE so my solution was to include #define RCC_HSICALIBRATION_DEFAULT 0x10U in the user code just before SystemClock_Config(); in main().

Now the USARTs work.

kiwironnie
Associate III

Thanks guys.

Generally disappointing that this code generation bug has clearly been around for at least 2 years without an STM fix.

Understandable why the generation tools and indeed HAL are not used by many.