cancel
Showing results for 
Search instead for 
Did you mean: 

printf redirection no longer working after bootloader jump

iTTy
Associate III

Hi there,

I'm experimenting to develop my own bootloader on a NUCLEO-H755ZI-Q board using CubeIDE environment.

I prepared 2 "standard" projecs dedicated to the bootloader and to the application respectively.

On the Bootloader side, I redirected the printf output to the USART3 for debugging and it works fine.

Doing the same on the application side, printf is no longer working after jump from bootloader (no messages at all).

I already tried the HAL_UART_Transmit function and the peripheral seems work properly.

I already tried the HAL_UART_Transmit function and the peripheral seems work properly.

I verified syscall.c file is present... so what is missing?

1 ACCEPTED SOLUTION

Accepted Solutions
iTTy
Associate III

Hi @STea  and @Tesla DeLorean ,

I tried overwriting _write function as suggested by @STea  as follow in the main:

 

int _write(int file, char *ptr, int len)
{
	HAL_UART_Transmit(&huart3, (uint8_t *) ptr, len, HAL_MAX_DELAY);
	return len;
}

 

 but no result!

 

Edit:

So,

I fixed the issue simply by adding "\r\n" at the endo of every message!

It seems that printf buffers strings and print them when it receive a new line sequence....

View solution in original post

6 REPLIES 6

>> so what is missing?

Don't know, you'll have to debug, check clocks, RCC, that the baud rate relates to the bus/pll settings you have in effect.

Would suggest setting up all the MCU, AHB, APB clocks on the loader side, and then not change them on the app side.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
STea
ST Employee

Hello @iTTy ,

i suggest to make sure that the configuration of the clocks and uart3 instance is set correctly on the app side as recommended by @Tesla DeLorean . if it is the case i suggest you overload the __wirte function in syscall.c 

int _write(int fd, char * ptr, int len)
{
  HAL_UART_Transmit(&huart2, (uint8_t *) ptr, len, HAL_MAX_DELAY);
  return len;
}

changing &huart2 to &huart3 .

hope this solves your request .

BR 

Hichem

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
iTTy
Associate III

Hi @STea  and @Tesla DeLorean ,

I tried overwriting _write function as suggested by @STea  as follow in the main:

 

int _write(int file, char *ptr, int len)
{
	HAL_UART_Transmit(&huart3, (uint8_t *) ptr, len, HAL_MAX_DELAY);
	return len;
}

 

 but no result!

 

Edit:

So,

I fixed the issue simply by adding "\r\n" at the endo of every message!

It seems that printf buffers strings and print them when it receive a new line sequence....

STea
ST Employee

Hello @iTTy 

can you send me a copy of the main.c file so i can verify it with you again ?

also did you try to flush the uart buffer with fflush(0); after the printf call 

exemple :printf("hello world");fflush(0);

BR 

STea

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
iTTy
Associate III

Hi @STea ,

I attach the main file of the M7 project we are speaking about.

Environment context:

Mplab CubeIDE Version: 1.12.1 Build: 16088_20230420_1057 (UTC)

Standard (default) project created for a NUCLEO-H755ZI-Q with CubeMX version 6.5.0 with firmware package for STM32H7 version 1.10.0

Application context:

This is an application that will be launched by a bootloader (loader only work on M7 core without waking-up the M4 one; M7 loader jumps to the M7 application that release also the M4application).

I verified the issue: removing the "\r\n" sequence in the strings logged throughh the printf, nothing is sended to the terminal.

Regarding your last question: no, I don't tried fflush(0);....

 

Hope it is usefull!

 

iTTy

Hello @iTTy ,

adding fflush (0); resolves the problem also and printf on its own will work accordingly in run mode but when used in debug mode a fush off the UART buffer is needed here is the code example i have tried .

BR

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.