Trying to flash STM32f030f4 (ARM, Cortex M0) - what is proper wiring?

Question

I've got STM32F030F4 chips from shop, made a small breadboard adapter for it and tried to connect to its built-in bootloader via USART1.

I've failed and I'm somewhat bewildered about wiring. My current schematic is the following:

• pin 16 (VDD) to +3.3
• pin 15 (GND) to GND
• pin 1 (BOOT0) to +3.3
• pin 4 (RESET) to GND, temporarily
• pin 8 (USART1_TX) to RX of the FTDI-cable
• pin 9 (USART1_RX) to TX of the FTDI-cable

The cable I use constantly with NXP chips, so I think it is using. It also provides +3.3 volts and has LEDS to indicate TX/RX activity.

I've tried this tool http://sourceforge.net/projects/bootstm32/ after plugging the cable and temporarily applying RESET to GND.

Magically, it could not connect, though I see the TX activity LED blink...

I've rechecked datasheet and I am somewhat bewildered. There are also pins 17 and 18 for USART1 TX and RX. I've tried them also but to no avail.

Another concern is that I think this chip do not have BOOT1 pin (many manuals write about driving it low). So I assume it is not needed?

I also thought I can test with multimeter either one of pins is in strong HIGH state, which should be TX - but none is. Though probably TX is turned to output only after auto baud rate detection is completed?

What else can be wrong? I think I need not quartz for simplest schematic, yes? Thanks in advance for your hints!

UPD Solved! It appeared that VDDA should also be connected, otherwise chip is in reset state. Please see my own answer below for more details.

Answer 1

At last I've found what was missing.

VDDA should be connected! e.g. to VDD. I believe if device has VSSA also, it also should be connected.

Otherwise the chip is in reset mode "thanks" to functionality which monitors both VDD and VDDA and simply does not allow chip to start.

So minimal connection is like this:

• 3.3 Volts to VDD, VDDA, BOOT0
• GND to VSS (and VSSA if present)

(at this point you can check that PA9 yields strong high level - seems it at once becomes TX output)

• PA9 (TX) to the RX of the cable (in my case no pull-up is needed as it is full-functional output)
• PA10 (RX) to the TX of the cable.

By the way I use the cable with 5V levels and it is Ok as the pins are 5v-tolerant.

Answer 2

Starting from the reference manual of the STM32F030x4, page 45, Embedded Boot Loader section:

The embedded boot loader is located in the System memory, programmed by ST during production. It is used to reprogram the Flash memory using one of the following serial interfaces:
• USART on pins PA14/PA15 or PA9/PA10
• I2C on pins PB6/PB7 (STM32F070xx and STM32F030xC devices only)
• USB DFU interface (STM32F070xx devices only)
For further details, please refer to AN2606.

If you further read the other recommended document (AN2606) you will find out that you should go with PA9/PA10 because the bootloader is configured on those pins. (Or PA14/PA15 but your chip should be a TSSOP20 20-pin package if Boot0 is pin1, so there isn't any PA15.). Furthermore, you are right, no external crystal is necessary, the MCU is clocked from HSI.

For the hardware connection requirements, pull-up resistors are needed on TX and RX lines if they are not added on the host side.

You will also find information about the Boot0 pin and the nBoot1 bit (at this MCU Boot1 is not a pin but a bit in the User option byte).

The STM32F03xx4/6 bootloader is activated by applying pattern2

and pattern2 is:

Pattern2 Boot0(pin) = 1 and nBoot1(bit) = 1

---

Best would be if you could check the UART lines with an oscilloscope or logic analyzer, just to make sure. And check this software as well and read all related documents from ST.

Answer 3

Don't know about stm32f0 series, but stm32f1 has BOOT0 set to 3.3V, BOOT1 don't even know what is its purpose so it is always in same position. BOOT0 has to be high when you power on the device, then it goes to bootloader mode, you don't need to reset again, at least make sure when you reset you have BOOT0 high otherwise it will start with program. When in bootloader mode, the XTAL has no importance perhaps it uses the internal LSI.
Question is: why don't you use the official ST bootloader GUI for transfer? Don't you think that some custom made bootloader from sourceforge isn't 100% OK?