STM32F103 - Bootloader Init Problem

[sauer]

Posted on July 10, 2015 at 10:12

Hi,

now i run into an other problem with the bootloader on the Nucleo Boards STM32F103 chip. Im building an Android Library to update the STM32 Firmware over Bluetooth (RS232) and add from time to time each processor. I successfully implemented F401 and F429 already and their bootloader react as expected But if i try to init the F103 the same way like the F401 or the F429 i got no responses like described in application note. Is this a bug in the bootloader or is this an issue of my .. whatever? 😉 Here i do a simple overview of the commands or bytes i send: Nucleo Board STM32F103RB Bootloader Bootloader ID: 0x22 Usually, as described in AN: Send: 0x7f (Init Command) Recv: 0x79 (ACK) Send: 0x00 0xFF (GET Command) Recv: 0x79 (ACK) + Answer from GET Command + 0x79 (ACK) But it only works like this: Send: 0x7f (Init Command) Recv: 0x79 (ACK) Send: 0x7f (Init) Recv: 0x1f (NACK, means connection closed unsuccessfully last time) Send: 0x00 0xFF (GET Command) Recv: 0x79 (ACK) + Answer from GET Command + 0x79 (ACK) -------------------------------------------------------------------- Nucleo Board STM32F401RE Bootloader works as expected Bootloader ID: 0x31 Send: 0x7f (Init) Recv: 0x79 (ACK) Send: 0x00 0xFF (GET Command) Recv: 0x79 (ACK) + Answer from GET Command + 0x79 (ACK) -------------------------------------------------------------------- STM32F4 Discovery Board STM32F429ZI Bootloader works as expected Bootloader ID: 0x31 (No Option Bytes in GVRP) Send: 0x7f (Init) Recv: 0x79 (ACK) Send: 0x00 0xFF (GET Command) Recv: 0x79 (ACK) + Answer from GET Command + 0x79 (ACK) #stm32 #uart #bootloader

[nesrine]

Posted on July 10, 2015 at 13:15

You said:

“But it only works like this:Send: 0x7f (Init Command)Recv: 0x79 (ACK)Send: 0x7f (Init)Recv: 0x1f (NACK, means connection closed unsuccessfully last time)Send: 0x00 0xFF (GET Command)Recv: 0x79 (ACK) + Answer from GET Command + 0x79 (ACK)�?Can you please keep it clearer? You sent the Init command 2 times? Right?

[Tesla DeLorean]

Posted on July 10, 2015 at 17:01

Well technically the loader doesn't ''receive'' the 0x7F, it times the pattern, and chirps back at the computed baud rate. This needs to be the FIRST thing the loader sees/hears on the wire. It's not technically a command, it's a one shot deal, and sending just one character during normal command interaction is likely to confuse things rather than help.

The loaders on the different chips support slightly different commands. It's important to be using EVEN PARITY when communicating with the loader.

[sauer]

Posted on July 10, 2015 at 22:43

Hi,

ok i try to explain it further. I got 3 different Chips on Eval Boards to test on. 1. Nucleo F401RE 2. Nucleo F103RB 3. STM32F4-DISCOVERY STM32F429ZI i connect 3 Bluetooth Modules (HC-05) on each board. The bluetooth modules are correctly configured and especially the uart settings are set to 115200bps one stop bit and even parity so it fits the st bootloader requirements. Then i connect from my linux pc to bluetooth module on board one (the F401) and send after a connect the init byte to it (0x7f) then this board correctly answers the init with the expected (0x79) ack byte. and all is okay. i can call commands, write memory, read memory and so on. Then i do the same procedure with the 3rd board (STM32F429ZI) and it works like a charm. same result as in board one. But then, when i tried the same procedure on board 2 (F103RB) like on board 1 and 3 it wont work. I send init byte 0x7f and get 0x79 back.... seems correct, but if i now try to send a command byte set (f.e. 0x00 0xFF for the GET command) it results in an 0x1f (NACK) and after that every byte will be answered with an 0x1f. BUT if i send the ini byte 0x7f and get an 0x79 back and send an init byte again i got a NACK byte but then every command works like expected. I hope it was clearly now. @clive1 i know that are on different chips different bootloader versions resist and i even know their differences in the command set 🙂 The testapp with my bootloader class is working already like a charm, but only the nucleo F103 didnt want to work like i wished       

[Tesla DeLorean]

Posted on July 10, 2015 at 23:24

You don't have a shield plugged into the Nucleo board, right?

[sauer]

Posted on July 11, 2015 at 00:00

Correct, no shield. Only the bluetooth module on pa9/pa10

[Nickname12657_O]

Posted on July 14, 2015 at 16:53

Dear gentleman,

Can you please try to decrease the baudrate from 115200 to 57600 or 38400 and check if  the STM32F103 is responding correctly. I've have a doubt on the auto-baudrate mechanism not recovering may be from the PC RS232 errors, the STM32F4xx have 16MHz HSI whereas the STM32F1xx have 8MHz HSI internal clock used to compute the right baud based on the 0x7F  magic word used at initialization.  Cheers, STOne-32.

[Tesla DeLorean]

Posted on July 14, 2015 at 17:16

Seem to recall the F1 System Loader uses the PLL to run at 24 MHz?