Start USART Bootloader on STM32F070 device does not work

[tj]

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 microWhat 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.ThanksThomas #nucleo-f070rb #bootloader

[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

[Ran Kai]

Posted on August 25, 2017 at 16:42

I have the same part STM32F070RBT6 GH262 98 CHN GH 447 on Nucleo-F070RB board.

And also tried the Nucleo-746ZG board and can't get the bootloader to work anywhere on anything.

My guess is that to keep the cost low for these Nucleo boards they decided not to put the bootloader on them.

:(

 

I will try one of my old Discovery boards and see if it works.  

Also do I need 100k pull-up resistors on my TX-RX lines?  That's what it says in (AN2606 section 3.3) I don't see why... it doesn't work either way.

[Ran Kai]

Posted on August 26, 2017 at 01:44

holy cow it works on my disco board!  But I cant get the 

Nucleo-F070RB, 

Nucleo-746ZG to work.  Now I have to reject these parts and find a working pin compatible mcu.

[Tesla DeLorean]

Posted on August 26, 2017 at 03:44

Remove the CN2 jumpers to disconnect the ST-LINK from the F070, then use the USART1 PA9/PA10

[MarcoM]

Posted on August 28, 2017 at 10:13

Hi Ran, I am happy for that! As told, the same happens to me!

About the 100K resistor, I don't see the reason to have such a resistor if the level of the RX line is driven by an UART transmitter. In my setup I have a FTDI RS232 interface, so the output of the interface is always active and the resistor is usefulness.

In my design I will use a F051, so all seems ok. But in the case I will do another design with an F070 or F072, I will be forced to test the bootloader using a hardware different from the Nucleo board, otherwise it will be impossible to know if the damned bootloader works or not on that part.

Marco

[MarcoM]

Posted on August 28, 2017 at 10:15

Too simple, Cleve.

Thank you for the suggestion, but this was a test already done, without any success.

It is like the parts mounted on Nucleo boards can't start the bootloader at all.

Someone from ST should double check it and write a note for users.

Marco

[Ran Kai]

Posted on August 28, 2017 at 14:47

Good morning there,

I have tried CN2 jumpers but no luck.  Also tried external power supply and still no response from the bootloader.

[Ran Kai]

Posted on August 28, 2017 at 15:04

Hi Marco,

One more notable thing is the bootloader version change log.  For F070 the clock configuration was fixed to HSI 8MHz for some reason and the problem I see with that is if the HSI deviates 1% then bootloader might not function as mentioned on (pg.46).  So if the clock is fixed to HSI then I don't see how it will work.  I am disappointed that a billion dollar company cant figure out Usart. 

[Tesla DeLorean]

Posted on August 28, 2017 at 15:30

>>

Someone from ST should double check it and write a note for users.

Consider talking to the FAE assigned to you account.

>>

I am disappointed that a billion dollar company cant figure out Usart. 

Well, I'm not sure % error in the HSI clock is dire, pretty sure the clock isn't unstable (sweeping around), but off frequency. The boot loader uses the 0x7F 8E1 pattern to TIME the host baud wrt target clocking, and uses that to program the baud rate divider and respond on the USART.

What the loader is going to be highly intolerant of is signal transitions on interface input pins