cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F746VGT6 bootloader jump fail to auto detect USART baudrate

Nchen.1
Associate III

Hi,

I'm having some strange issues trying to update F7 MCU via USART with stm32loader.

The MCU jumps to bootloader from software and enter DFU mode, the USART is detected, however, the auto baudrate detects 1200 bps instead of 115200.

I've made some tests, and if I reset the system before USB init (in order to jump to bootloader) it detects the baudrate most of the times (not all of the times).

Following AN2606 document, STM32F74xxx known limitations, I've tried to decrease the baudrate to 9600, but it still detects 1200.

Manually setting BOOT0 to high (using a button) works perfectly, but I need it to work using software.

Regards,

Nitzan

1 ACCEPTED SOLUTION

Accepted Solutions
Nchen.1
Associate III

Thanks for the help, problem solved

Bootloader jump was called from a function which was after the beginning of the code instead of the beginning of SystemInit().

This made the undefined behavior on bootloader.

View solution in original post

9 REPLIES 9
TDK
Guru

Are you sure the line isn't being toggled during reset? Put a logic analyzer on it and verify.

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

Which line are you referring to? The USART line or the BOOT0 line?

USART_RX

Edit:

If you verify the signal is correct, then there must be something different about your configuration at the time you jump to the bootloader compared to the as-reset state. Setting a magic value in SRAM, resetting the chip, and jumping to the bootloader immediately if you detect that value (before any initialization) can avoid this issue.

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

Best to construct a method which resets and then immediately enters the system boot loader, from your own Reset_Handler, and before you've reconfigured, pins, clocks, PLL, peripherals, interrupts, etc.

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

Signal was verified, I see the Rx line receive 0x7F in the selected baud rate and ACK transmitted on 1200 baud rate (measured with oscilloscope)

The magic number method you’ve mentioned is what I currently use, but yet the bootloader usart auto baud rate detection seems detect wrong values

I’m using this method and yet, the bootloader usart configuration for auto baud rate detection seems to be the issue. I see an ACK transmitted in 1200 baud rate instead of 9600

is there any register that could affect the baud rate detection for the boot loader?

TDK
Guru

It doesn't check out that jumping to the bootloader directly after reset causes it to behave differently that jumping to it via BOOT0 pin. The chip is in the same state, and the processor behaves deterministically. Recheck your assumptions.

> is there any register that could affect the baud rate detection for the boot loader?

Even if there was, registers are reset upon reset.

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

Is there any reset function than calling NVIC_Reset? Perhaps the reset process itself isn’t accurate and not everything is reset?

Nchen.1
Associate III

Thanks for the help, problem solved

Bootloader jump was called from a function which was after the beginning of the code instead of the beginning of SystemInit().

This made the undefined behavior on bootloader.