Start USART Bootloader on STM32F070 device does not work

[tj_it]

Posted on May 22, 2016 at 10:50

Hi all,

i am using a Nucleo board ''NUCLEO F070RB'' and i want to start the UART Bootloader. Unfortunately the bootloader doesn�t send the Ack  byte (0x79) after activation.

My procedure to start the bootloader:

- connect the boot0 pin to 3V3

- reset the board (black botton)

- send the 0x7F Byte with 9600, even parity, 1 start bit, 1 stop bit

=> at this point i expect to receive the 0x79 ACK byte from the micro

What i did till now to find what i am doing wrong:

- i checked that nBOOT1 bit in the option bytes is set to 1

- due to the fact that the F070 device has an USB interface i removed the crystal (and i opened SB50 from the NUCLEO to avoid getting clock from the debugger)

- i am quite sure that the micro is in bootloader mode, because the application doesn�t start.

- i verified my sequence with a NUCLEO-F030RB

=> here erverything works fine. The problem just excists on the F070.

=> all my HW-connections should be ok (same Pins)

I am running out of ideas :( 

Any help is appreciated.

Thanks

Thomas

#nucleo-f070rb #bootloader

[Tesla DeLorean]

Posted on May 23, 2016 at 14:51

Which Pins and USART are being utilized?

Can you identify the ROM version being used?

What are the marking/production codes from the top of the device?

[Walid FTITI_O]

Posted on May 23, 2016 at 15:40

Hi jung.thomas.001

In

http://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf

, section'' STM32F070xB devices bootloaders'' p 44,  there is a note:

''

Note: If HSI deviation exceeds 1% , the bootloader might not function correctly.

''

So It may the HSI of the device is not accurate enough, try with a HSE crystal.

-Hannibal-

[tj_it]

Posted on May 24, 2016 at 08:24

Hi clive1,

thanks for the replay.

I am using USART1 on PA9 and PA10. I use the same USART and the same pins in my application and there it works fine. Same connections on a NUCLEO F030 board works fine.

How can i identify the ROM Code Version? Is it part of the production code? 

This evening i will send you the production code. I don´t have the board with me. I tried at least two boards.

Thanks

Thomas

[tj_it]

Posted on May 24, 2016 at 08:33

Hi Hannibal, 

thanks for the replay.

i have read the note you mentioned, therefore i tried both, with and without crystal. Nothing works. Is there any other possibility to skip the USB bootloader. 

What is the indication for the bootloader to detect a connected USB interface (PA11, PA12, PA13) ?

Thanks

Thomas

[tj_it]

Posted on May 24, 2016 at 17:24

Hi clive1,

here is the product code:

STM32F070R8T6 GH262 98 CHN GH 447

The code is the same for all the boards i have tried.

Thanks for help

Thomas

[Tesla DeLorean]

Posted on May 24, 2016 at 18:34

The USART1 should be functional with HSI, one might try different baud rates. Connecting it via a VCP might be problematic, the bootloader will be sensitive to glitches as the 0x7F is a pattern that is being measured, rather than received. You could use a scope to see if there is an 0x79 response at some other baud rate.

Absent USART/USB connectivity to the loader to query its version, one would have to download via SWD and manually dig it out. The ROM is 12KB located at 0x1FFFC800..0x1FFFF7FF[0x3000]

Not a part I'm using, but the codes should let someone at ST identify if there is a parts/batch issue.

[tj_it]

Posted on May 24, 2016 at 19:29

Hi clive1,

the USART is connected to a FTDI Evalboard ''UM232R'' which is mounted nearby the NUCLEO board. I already checked the RX and TX line with my scope. I see a perfect 0x7F on the RX line bt nothing (constant high) on the TX line. I also checked different baud rates (9600, 115200).

I checked the bootloader Version. (Adress 0x1ffff6a6 Version: 0xA2). This is what i expect.  AN2606 tells me that it should be USART bootloader Version 3.1. Do you Need more numbers from the bootloadercode?

We could also debug the bootloader. I could set breakpoints and see if we hit them.

Thanks for help

Thomas

[tj_it]

Posted on May 30, 2016 at 12:41

Hi all,

somebody else who has an idea??

Thanks

Thomas

[Julien SOTIERE]

Posted on June 13, 2017 at 11:43

Hi Thomas

Do you find the problem ? I am the same problem, the boot0 is hight but the stm32f070cb doesnt respond in bootmode.

Thanks.

Julien

[MarcoM]

Posted on August 25, 2017 at 14:54

Hi Thomas,

I have *exactly* the same problem, both on a Nucleo64 with SMT32F070 and a Nucleo64 with STM32F401.

I wired Boot0 to 3.3V and connected a FTDI USB to TTL (3.3V) either to UASRT1 or UASRT2. In both cases I had no answer on my RX line (TX line from the boards). I am sure that the bootloader doesn't start at all, and this is confirmed by the fact that I can start the ST-link and connect to the MCU.

I also confirm that nBoot1 bit is 1 (checked on the SL-Link Utility Option Byte panel).

After testing of several hours, I tried to use a STM32F0-Discovery board with a STM32F051: this time all worked perfectly!

The bootloader starts and communicates without problems when I connect the USB to TTL adapter either to UASRT1 or USART2. Every time I reset (with Boot0 wired to VDD), the bootloader runs as expected.

When the bootloader is in execution, the ST-Link can't take control over the board, that I suppose is correct.

Also, I clearly see that when I wire Boot0 to VDD and reset, the application program (LED blink) doesn't start, which is correct.

So my conclusion is that for same unknown (and undocumented) reason, the MCUs mounted on my *two* different nucleo64 boards doesn't start the bootloader. The one on the STM32F0-Discovery works as expected.

Maybe there are processors with some issue about starting bootloader?

ST, please tell us if this is true. Thanks.

Marco