Differences

This shows you the differences between two versions of the page.

--- stm32f1xx [2016/02/14 09:35] – add syntax highlighting in code kingkevin
+++ stm32f1xx [2020/02/12 08:58] – [blue pill] add pictures kingkevin
@@ Line 72: / Line 72: @@
   * proper USB disconnect circuit (useful for using the DFU bootloader it comes with)
   * small
-  * good analogue design
+  * good analog design
   * more flash (128 vs 64 kB)
   * small, fits breadboard (600 mil wide)
@@ Line 79: / Line 79: @@
   * no additional connections (SWD, power, GND)
   * the pin silkscreen are not the chip pins (you always need the schematic at hand)
-  * the clones don't provide a second voltage regulator for the analague part
+  * the clones don't provide a second voltage regulator for the analog part
 ===== blue pill =====
-{{  :stm32f1xx:minimum_system-back.jpg?0x400|system board}}{{  :stm32f1xx:minimum_system-front.jpg?0x400|system board}}
+{{ :stm32f1xx:minimum_system-back.jpg?0x400|system board}}{{ :stm32f1xx:minimum_system-front.jpg?0x400|system board}}
+{{ :stm32f1xx:blue-pill_pinout.svg?0x400|}}
-This cheap board is often referred as blue pill in forums and sold under $2.50 as [[http://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-arduino/32478120209.html|STM32 minimum system development board]].
+This cheap board is often referred as blue pill in forums and sold under $2.50.
 It has:
   * [[http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164476|STM32F103C8T6]] MCU ([[http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00161566.pdf|DS5319 datasheet]], {{:stm32f1xx:CD00161566-STM32F103x8_datasheet.pdf|archive}}):
@@ Line 96: / Line 97: @@
     * 6: -40 to 85 °C
   * peripherals:
-    * 2x20 GPIO pins on the side (most MCU pins are accessible)
+    * two 1x20 GPIO pins headers on the side (most MCU pins are accessible)
     * USB micro-B
     * SWD on the top
     * boot select
     * power LED
-    * user LED, on P13
+    * user LED, on PC13 (warning: switching this LED heavily affects the RTC)
     * reset button (NRST)
     * 32.768 kHz real time clock (RTC)
@@ Line 113: / Line 114: @@
   * no user button
   * board extends over headers
+  * the RTC is not stable when the on-board LED is toggled
 Here a rough {{:stm32f1xx:bluepill-6-stm32f103c8t6原理图.pdf|schematic}}, but there a many derivatives.
 Mine for example has a 10 kΩ pull-up (to 3.3 V) resistor on USB D+/PA12 instead if a 4.7kΩ (to 5 V), although USB devices use a 1.5 kΩ resistor to pull up (to 3.3 V) usually.
+===== black pill =====
+{{ :stm32f1xx:black-pill_bottom-mini.jpg?0x400|}}
+{{ :stm32f1xx:black-pill_top-mini.jpg?0x400|}}
+the [[https://stm32-base.org/boards/STM32F103C8T6-Black-Pill.html|black pill]] is a "fixed" version of the blue pill, but I find it quite inferior.
+advantages:
+  * correct 1.5 kΩ pull-up resistor on USB D+
+  * RTC is usable at the same time as the LED
+  * has 4 mounting holes
+  * USB input diode protection
+changes:
+  * LED is on PB12 (sink to enable it)
+  * different pinout
+drawbacks:
+  * larger
+  * same length but with less pins
+  * only one 3.3V pin (instead of 2 on the blue pill)
+  * no 5V pin
+  * no VBAT pin
+  * one less GND pin
+  * no C15 and C14 pin (used for OSC32)
+===== core board =====
+{{ :stm32f1xx:core-board_back.jpg?0x400|core board}}{{ :stm32f1xx:core-board_front.jpg?0x400|core board}}
+You can often find this versatile board for $6 by searching for "51 core board".
+It has:
+  * [[http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164476|STM32F103C8T6]] MCU ([[http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00161566.pdf|DS5319 datasheet]], {{:stm32f1xx:CD00161566-STM32F103x8_datasheet.pdf|archive}}):
+    * STM32: 32-bit ARM
+    * F: general purpose
+    * 103: medium density (performance line)
+    * C: 48 pins
+    * 8: 64 kB flash
+    * T: LQFP
+    * 6: -40 to 85 °C
+  * peripherals:
+    * two 2x10 GPIO pin headers on the side (most MCU pins are accessible)
+    * USB micro-B
+    * 2x3 SWD+UART port
+    * boot select
+    * power LED
+    * user LED, on PA1
+    * reset button (NRST)
+    * user button (PA8)
+    * 32.768 kHz real time clock (RTC)
+{{ :stm32f1xx:core-board_schematic.jpg?0x400|}}
+It offers quite a lot of peripheral options:
+  * 2x4 header for the ESP-01 WiFi module (base on the ESP8266)
+  * 2x4 header for the nRF24L01 transceiver module
+  * 1x4 header for a Bluetooth module (using as UART port)
+  * 1x8 header for an OLED/TFT screen
+  * 2x5 header for a VS1053/W5500 Ethernet module
+  * space and pads for a CR1220 coin cell (with knife pins) connected to VBAT (for the the RTC circuit of the micro-controller), but don't forget to also add the two diodes (D3 and D4)
+  * footprint for a flash chip (W25xxx, SOP-8) connected to an SPI port (SPI1)
+  * footprint for a EEPROM chip (24Cxx, SOP-8) connected to an I2C port (I2C1), but don't forget to add the pull-up resistors (R12 and R13)
+  * footprint for a [[https://www.aliexpress.com/item/20PCS-Push-Push-Type-TransFlash-TF-Micro-SD-Card-Socket-Adapter-Automatic/32596334297.html|micro-SD card slot]] connected to an SPI port (SPI1), but don't forget to add the pull-up resistors (R14, R15, and R16)
+advantages:
+  * user LED and button
+  * large AMS1117 voltage regulator
+  * fuse on USB 5V
+  * separate 5V connection
+  * SWD+UART header (ideal for the black magic probe)
+  * RTC oscillator included
+  * compact (42x53 mm)
+  * M3 mounting holes
+drawbacks:
+  * very few power pins
+**warning**: on the board silkscreen SWDIO and SWCLK are swapped
 ====== flashing ======
 Flashing refers to programming your application into flash, so the micro-controller can run it.
 There are several ways to program the flash, as explained in [[http://www.st.com/web/en/resource/technical/document/programming_manual/CD00283419.pdf|PM0075]] ({{:stm32f1xx:pm0075_flash_programming_manual.pdf|archive}}):
-  * In-Circuit Programming (ICP): using SWJ (serial wire and JTAG) or the built-in boot loader. This mechanism is provided natively by the micro-controller
+  * [[#ICP|In-Circuit Programming (ICP)]]: using SWJ (serial wire and JTAG) or the embedded bootloader. This mechanism is provided natively by the micro-controller
-  * In-Application Programming (IAP): using a custom application which can write into flash. But for that you first need to flash this application (often called boot loader) using an ICP method
+  * [[#IAP|In-Application Programming (IAP)]]: using a custom application which can write into flash. But for that you first need to flash this application (often called boot loader) using an ICP method
 It's also possible to program it into RAM and run it from there, but this is not the focus here.
@@ Line 131: / Line 208: @@
 ===== ICP =====
-In-Circuit Programming methods.
+In-Circuit Programming methods:
-==== built-in bootloader ====
+  * [[#embedded bootloader]]: simple but slow
+  * [[#SWJ]]: complex but fast, and allows debugging
+==== embedded bootloader ====
-The STM32 micro-controller come with a built-in boot loader stored in ROM which allows you to program the flash using simple communication protocols like USART, I2C, ...
+The STM32 micro-controller come with a embedded bootloader stored in ROM which allows you to program the flash using simple communication protocols like USART, I2C, ...
 How to start this bootloader is described in [[http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00167594.pdf|AN2606]] ({{:stm32f1xx:an2606_boot_mode.pdf|archive}}).
@@ Line 166: / Line 246: @@
 You first need a SWD or JTAG adapter.
 I am using a [[jtag#st-link_v2_clone|ST-Link V2]], which I connect on the SWD debug port (SWD-DP): SWDIO is on PA13, SWCLK is on PA14.
+Don't forget to add a udev rule to allow the user to access the SWD adapter: <code bash>
-To control the SWD adapter several software are available:
-  * [[https://github.com/texane/stlink|stlink]] is pretty popular
-  * but I am using [[http://openocd.org/|OpenOCD]], which I will explain here
-Using OpenOCD:
-  - install PpenOCD: <code bash>
-sudo apt-get install openocd
-</code>
-  - add a udev rule to allow the user to access the SWD adapter: <code bash>
 sudo tee /etc/udev/rules.d/60-st-linkv2.rules << EOF
 # STMicroelectronics ST-LINK/V2
@@ Line 182: / Line 253: @@
 sudo service udev reload
 </code>
-  - connect the SWD adapter to PC USB
-  - start openOCD: <code bash>
+To control the SWD adapter several software are available:
+  * the dedicated [[#st-link]] tool
+  * but I am using [[#OpenOCD]], which I will explain here
+=== st-link ===
+[[https://github.com/texane/stlink|stlink]] is a dedicated tool for the ST-Link V2 SWD adapter and STM32 micro-controllers.
+To install st-link:
+<code bash>
+git clone https://github.com/texane/stlink.git
+cd stlink/
+./autogen.sh
+./configure
+make
+</code>
+To write the firmware at 0x0800 0000 (the flash memory start address) you can simply use:
+<code bash>
+./st-flash write firmware.bin 0x08000000
+-02-14T10:56:33 INFO src/stlink-common.c: Loading device parameters....
+-02-14T10:56:33 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
+-02-14T10:56:33 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
+-02-14T10:56:33 INFO src/stlink-common.c: Attempting to write 7100 (0x1bbc) bytes to stm32 address: 134217728 (0x8000000)
+Flash page at addr: 0x08001800 erased
+-02-14T10:56:33 INFO src/stlink-common.c: Finished erasing 7 pages of 1024 (0x400) bytes
+-02-14T10:56:33 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id
+-02-14T10:56:33 INFO src/stlink-common.c: Successfully loaded flash loader in sram
+/6 pages written
+-02-14T10:56:33 INFO src/stlink-common.c: Starting verification of write complete
+-02-14T10:56:34 INFO src/stlink-common.c: Flash written and verified! jolly good!
+</code>
+What is useful is that it show some information about the chip at the beginning.
+You can also get this information using ''./st-info''.
+You can also use it combination with [[#GDB]] to [[#debugging|debug]] or flash images:
+  - start the st-util server: <code bash>
+./st-util
+INFO src/stlink-common.c: Loading device parameters....
+INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
+INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
+INFO gdbserver/gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
+INFO gdbserver/gdb-server.c: Target voltage is 3288 mV.
+INFO gdbserver/gdb-server.c: Listening at *:4242...
+</code>
+  - start GDB with the firmware to flash/debug, connect to st-util, flash the image: <code bash>
+arm-none-eabi-gdb firmware.elf
+...
+Reading symbols from firmware.elf...done.
+(gdb) tar extended-remote :4242
+Remote debugging using :4242
+x0800016c in ?? ()
+(gdb) load
+Loading section .text, size 0x85d8 lma 0x8002000
+Loading section .ARM.exidx, size 0x8 lma 0x800a5d8
+Loading section .data, size 0x8b4 lma 0x800a5e0
+Start address 0x80043fc, load size 36500
+Transfer rate: 9 KB/sec, 7300 bytes/write.
+</code>
+=== OpenOCD ===
+[[http://openocd.org/|OpenOCD]] is a more general tool than [[#st-link]].
+It supports numerous adapters and micro-controllers (targets).
+You just have to specify what you are using.
+To use OpenOCD:
+  - install OpenOCD: <code bash>
+sudo apt-get install openocd
+</code>
+  - start openOCD and specify the adapter we are using and micro-controller we want to control : <code bash>
 openocd --file interface/stlink-v2.cfg --file target/stm32f1x.cfg
 </code>
@@ Line 195: / Line 340: @@
 dump_image dump.bin 0x08000000 0x1ffff
 </code>
-  - and write to flash a new firmware at 0x0800 0000 (the flash memory address). firmware.bin must be in the working directory where you started openOCD: <code bash>
+  - and write the firmware at 0x0800 0000 (the flash memory start address). firmware.bin must be in the working directory where you started openOCD: <code bash>
 flash write_image erase firmware.bin 0x08000000
 </code>
@@ Line 231: / Line 376: @@
 </code>
+Like with [[#st-link]] you can also use OpenOCD as a [[#GDB]] back-end to flash the firmware or [[#debugging|debug]] it.
 ===== IAP =====
@@ Line 242: / Line 388: @@
 ==== USB DFU ====
-There are several USB DFU bootloader.
+There are several USB DFU bootloaders available (one from [[http://www.st.com/resource/en/application_note/cd00264379.pdf|STMicroelectronics]] themselves, or the open source [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader|STM32duino-bootloader]]), but I developed [[https://git.cuvoodoo.info/stm32f1/about/|my own]] because I wanted to know how DFU works.
-I am using [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader|STM32duino-bootloader]] ([[https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader|wiki]]).
-It works well on most generic boards and is small (8kB).
-To flash using the bootloader:
+Here I will explain how to use USB DFU with the [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader|STM32duino-bootloader]] because it provides binaries for numerous development boards (while mine supports only a few, needs to be configured, and must compiled), but for other DFU bootloaders just replace with the corresponding USB ID.
+If you want to make use of USB in your actual application after the bootloader started it, don't forget to force re-enumerating USB so the host computer sees the new interface:
+    * you can do this on the board by signalling a USB reset. On the [[#maple mini]] there is a dedicated circuit. On generic boards you can pull USB D+/PA12 low for a short time
+    * you can also force this on the host using [[https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Using-a-generic-stm32-board-on-linux-with-Maple-bootloader|usb-reset]]: <code bash>
+sudo ./usb-reset "/dev/bus/usb/$(lsusb |grep "1eaf" |awk '{print $2,$4}'|sed 's/\://g'|sed 's/ /\//g')" >/dev/null 2>&1
+</code>
+To flash using the USB DFU bootloader:
   - download the [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader|STM32duino booloader]] for your board
     * [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/generic_boot20_pa1.bin|with LED on PA1]] for the [[#system board]]
-    * [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/maple_mini_boot20.bin|maple_mini]] for the [[#maple mine]]
+    * [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/maple_mini_boot20.bin|maple_mini]] for the [[#maple mini]]
     * [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/STM32F1/binaries/generic_boot20_pc13.bin|with LED on PC13]] for the [[#blue pill]]
   - flash bootloader (at 0x0800 0000) using [[#ICP]]
@@ Line 321: / Line 473: @@
 </code>
   - after the device is powered you have 0.5 seconds to flash the firmware before if starts the main firmware
-  - on [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/README.md|some boards]] the USB will not re-enumerate when exiting the bootloader. You can force this using [[https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Using-a-generic-stm32-board-on-linux-with-Maple-bootloader|usb-reset]]: <code bash>
-sudo ./usb-reset "/dev/bus/usb/$(lsusb |grep "1eaf" |awk '{print $2,$4}'|sed 's/\://g'|sed 's/ /\//g')" >/dev/null 2>&1
-</code>
 ====== developing ======
@@ Line 338: / Line 487: @@
 I am using [[http://libopencm3.org/|libopencm3]] because it's very make and gcc-arm friendly (the development environment I am using), and comes with plenty of [[https://github.com/libopencm3/libopencm3-examples|examples]].
 I still keep the [[http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf|reference manual]] open to check what registers are used.
+====== debugging ======
+Here are methods I use to debug my firmware, in increasing order of difficulty and power.
+===== LED =====
+Most of the development boards come with a user LED connected to a GPIO.
+Switching it on an off is pretty easy.
+I use it to show a current state (on/off) or activity (toggling).
+The advantage is that you can also use it in interrupt service routines, or see the signal on the oscilloscope (to measure the speed, frequency, or use it as trigger).
+===== prinft =====
+The LED is pretty simple but also very limited.
+The next step is printing messages on the console about what is being done.
+For the communication I use a USART port.
+They are easy to configure and run, reliable, and simple to connect to.
+It's also fast enough to send debug messages.
+With these messages I can show multiple states, the history of events, and ongoing actions.
+But don't use USART in interrupt service routines.
+That just creates a mess.
+===== GDB =====
+The [[https://www.gnu.org/software/gdb/|GNU debugger]] GBD is a common tool used to debug software.
+Often it's used to debug local computer software, but it can also be used to debug software running on a remote micro-controller.
+For that you just need as [[#SWJ]] adapter to be able to control the hardware, and software making use of this adapter such as [[#st-link]] and [[#OpenOCD]].
+Then tell GDB to connect to this remote target, through this SWJ software.
+Here a quick example using [[#OpenOCD]]: <code bash>
+arm-none-eabi-gdb --eval-command="target remote | openocd --file interface/stlink-v2.cfg --file target/stm32f1x.cfg --command \"gdb_port pipe; init\"" firmware.elf
+...
+Reading symbols from firmware.elf...done.
+Remote debugging using | openocd --file interface/stlink-v2.cfg --file target/stm32f1x.cfg --command "gdb_port pipe; init"
+Open On-Chip Debugger 0.10.0-dev-00189-g554313b (2016-01-12-16:26)
+...
+Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
+Info : using stlink api v2
+Info : Target voltage: 3.286573
+Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
+Info : accepting 'gdb' connection from pipe
+Info : device id = 0x20036410
+Info : flash size = 128kbytes
+undefined debug reason 7 - target needs reset
+x00000000 in ?? ()
+(gdb) monitor halt
+stm32f1x.cpu: target state: halted
+target halted due to debug-request, current mode: Thread
+xPSR: 0x21000000 pc: 0x08002314 msp: 0x20004f80
+stm32f1x.cpu: target state: halted
+target halted due to debug-request, current mode: Thread
+xPSR: 0x21000000 pc: 0x08002314 msp: 0x20004f80
+(gdb) backtrace
+#0  0x08002314 in main () at main.c:193
+(gdb) frame
+#0  0x08002314 in main () at main.c:193
+				__WFI(); // go to sleep
+</code>
+This is pretty useful to check the state (to figure out where the code runs havoc) and control the flow, even in interrupt service routines.
+===== SWO =====
+TODO