STM32G030 USART and HAL_Delay strange behavior

[maurosmartins]

Hello all, 

I've recently received a dev board for STM32G030F6 microcontroller and I wanted to make a simple USART test before continuing. 

I've started the project using STM32 CUBE MX initializing serial port and clock, also, I've retargeted printf as follows:

int __io_putchar(int ch){
 HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, 0xFFFF);
 return ch;
}

the main is just the initializations and a while(1) loop as follows:

while (1){
 printf("Hello World\r");
 HAL_Delay(1000);
}

When I start a debug session (using st link v2 or J-link edu, tried  both) without the "HAL_Delay" I correctly see the message on the serial port.

On the other hand, If the HAL_Delay is present everything seems ok but no output on the serial port, or sometimes it will output like a burst. 

 

Does anyone have an idea of what can be happening? 

Looking forward your reply, 

Best regards, Mauro. 

[Andrew Neil]

---

@maurosmartins wrote:

If the HAL_Delay is present everything seems ok but no output on the serial port, or sometimes it will output like a burst. 

---

How are you observing that?

Are you sure it's not an artefact of whatever you're using to see the output?

Does it make any difference if you change to

printf( "Hello World\r\n" );

ie, CRLF at the end - instead of just CR

Or maybe just LF instead of just CR?

[maurosmartins]

Hello Andrew, 

thank you for your prompt reply.

Indeed it made difference, using the "\r\n" or only "\n" worked properly!

Does this behavior relate to the printf function? I've been using only "\r" for a long time on the "PIC" microcontroller project that I'm now migrating to the G030.

Thanks, Mauro.

 

 

 

 

 

[Andrew Neil]

---

@maurosmartins wrote:

Does this behavior relate to the printf function?

---

Maybe; try putting a breakpoint in your __io_putchar() - to see when it gets called ...

It could also be down to whatever you're using to observe the data - hence the question of how you are observing it.

[TDK]

> Does this behavior relate to the printf function? I've been using only "\r" for a long time on the "PIC" microcontroller project that I'm now migrating to the G030.

Probably more to do with your terminal software. A "\r" character usually means go to the start of the current line. A "\n" means go to the next line. Buffering by the terminal program can also play a role--sometimes the software will wait until it sees a newline to print things.

[Pavel A.]

This likely is because of line buffering on stdout. CR is not a line separator. LF is.