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.

[maurosmartins]

Hello again, 

just checked with the scope. When using just the "\r" there is no data output, as mentioned before, after sometime  a burst of data is sent also seen in the Serial2USB converter. 

I suspect that using the \n forces data to be sent immediately while without it data is being buffered. As soon the buffer fills it is transmitted all at once.

Mauro. 

[Andrew Neil]

Have you tried a breakpoint in __io_putchar() ?

I implemented printf() support as _write(int file, char *ptr, int len) and noted that printf() caused a single call with the whole string, whereas fprintf(stderr, ...) sent character-by-character ...

int _write(int file, char *ptr, int len)
{
  UART_HandleTypeDef *phUart;
  HAL_StatusTypeDef   result;

  phUart = ( STDOUT_FILENO == file ) ? &STDOUT_UART_HANDLE : &STDERR_UART_HANDLE;

  result = HAL_UART_Transmit( phUart, (uint8_t*)ptr, len, 0xFFFF );

  if (HAL_OK == result)
  {
	  return len;
  }
  else
  {
	  return  EIO;
  }
}

[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.

[maurosmartins]

Hi again,

---

@Andrew Neil wrote:

Have you tried a breakpoint in __io_putchar() ?

---

When using \n the program stops at the "__io_putchar" breakpoint for every char. 

When using \r, the program behaves as described previously, no stop at the breakpoint for sometime and afterwards many stops for all the "buffered" chars.

In the meanwhile I've found this thread that also addresses this.

Best regards, Mauro

[Pavel A.]

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