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?

17 REPLIES 17

Thanks. It was a #define as you indicate, see below.

TDK
Guru

It's a bummer that the hardware has different defaults. Although there's really no excuse for CubeMX not checking the chip family and revision at runtime. In this case, it could even be done at compile time.

Hmm, actually the L433 reference manual says 0x40 is the default, which agrees with the code. Are you saying the RM is wrong as well? Is the value at reset actually 0x10?

0693W000003BtmdQAC.png

If you feel a post has answered your question, please click "Accept as Solution".

Appreciate your response. See bug in code generation above.

But RM0934 indeed says HSI TRIM is 6 bits... I personally would double-check the reset value, or, better, avoid writing to that register altogether.

JW

Apparently this is wrong. Having checked the HSI output frequency with an oscilloscope an HSI trim value of 0x10 is required to set the clock to almost exactly 16MHz (no PLL), the required value. Whereas at 0x40 the frequency is around 17MHz! A trim value of 0x00 is significantly under 16MHz.

And what's the reset value of the trim? What is the HSI frequency without touching the trim (i.e. no call to any function touching RCC)? How do you measure the click frequency?

What are the take Device ID/revision values? How is the chip marked? I'd this an ES (Engineering Sample)?

JW

NKhan.7
Associate

Looks like a CubeID's but for STM32L432KC as well. I've been manually changing the value after genereating code. But I like your approach of the #define better.

 #define RCC_HSICALIBRATION_DEFAULT 0x10U 

kiwironnie
Associate III

Glad the workaround was of help. It would have been good to have done a bit more investigation, as per Jan's questions, but time is the enemy. Cheers Ron.