CuVoodoo

the sorcery of copper

User Tools

Site Tools


stm32f1xx

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
stm32f1xx [2016/02/14 10:38] – [SWJ] kingkevinstm32f1xx [2024/01/07 17:49] (current) – external edit 127.0.0.1
Line 72: Line 72:
   * proper USB disconnect circuit (useful for using the DFU bootloader it comes with)   * proper USB disconnect circuit (useful for using the DFU bootloader it comes with)
   * small   * small
-  * good analogue design+  * good analog design
   * more flash (128 vs 64 kB)   * more flash (128 vs 64 kB)
   * small, fits breadboard (600 mil wide)   * small, fits breadboard (600 mil wide)
Line 79: Line 79:
   * no additional connections (SWD, power, GND)   * no additional connections (SWD, power, GND)
   * the pin silkscreen are not the chip pins (you always need the schematic at hand)   * 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 ===== ===== 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: 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}}):   * [[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     * 6: -40 to 85 °C
   * peripherals:   * 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     * USB micro-B
     * SWD on the top     * SWD on the top
     * boot select     * boot select
     * power LED     * power LED
-    * user LED, on P13+    * user LED, on PC13 (warning: switching this LED heavily affects the RTC)
     * reset button (NRST)     * reset button (NRST)
     * 32.768 kHz real time clock (RTC)     * 32.768 kHz real time clock (RTC)
Line 113: Line 114:
   * no user button   * no user button
   * board extends over headers   * 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. 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. 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 ======
  
 Flashing refers to programming your application into flash, so the micro-controller can run it. 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}}): 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. 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 ===== ===== 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}}). 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 211: Line 291:
 You can also get this information using ''./st-info''. You can also get this information using ''./st-info''.
  
-You can also use it combination with GDB to [[#debugging|debug]] or flash images:+You can also use it combination with [[#GDB]] to [[#debugging|debug]] or flash images:
   - start the st-util server: <code bash>   - start the st-util server: <code bash>
 ./st-util  ./st-util 
Line 296: Line 376:
 </code> </code>
  
-Like with [[#st-link]] you can also use OpenOCD as a GDB back-end to flash the firmware or [[#debugging|debug]] it.+Like with [[#st-link]] you can also use OpenOCD as a [[#GDB]] back-end to flash the firmware or [[#debugging|debug]] it.
 ===== IAP ===== ===== IAP =====
  
Line 308: Line 388:
 ==== USB DFU ==== ==== 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/kingkevin/stm32f1/|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>&
 +</code> 
 + 
 +To flash using the USB DFU bootloader:
   - download the [[https://github.com/rogerclarkmelbourne/STM32duino-bootloader|STM32duino booloader]] for your board   - 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/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]]     * [[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]]   - flash bootloader (at 0x0800 0000) using [[#ICP]]
Line 387: Line 473:
 </code> </code>
   - after the device is powered you have 0.5 seconds to flash the firmware before if starts the main firmware   - 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 ====== ====== developing ======
Line 404: 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 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. 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
 +0x00000000 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
 +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
stm32f1xx.1455446319.txt.gz · Last modified: 2024/01/07 17:49 (external edit)