Chip Bootloader and Downloader

Meanwhile I programmed various chip programmers and boot loaders. Here is a list of that.

PonyProg 2015

A PonyProg2000 source code, forked(?) for some improvements esp. for Windows platform.

This stalled project shows how to route wires to the chip, as Fritzing did similar much later. It can program PIC, AVR, serial EEPROMs and should program all. Using plugins it can use real chip programmers such as GALEP-III.

• (Almost?) Original PonyProg from Italy
• Latest version (not functional)

MSP430F5xx downloader

Easy to use command-line firmware downloader for TI MSP430F55xx microcontrollers, via USB.

As a replacement for the hard-to-use Texas Instruments loader, I wrote a smaller one that accepts .HEX files, preferrable over the strange TI TXT files.
2024: It loads ELF files too, has alternative German output, and is available as 64 bit executeable.

• The chip programmer

AVR downloader

For ElmChans parallel port + parallel high-voltage AVR programmer, I rewrote his avrpp.exe with many nice features. Enhancements:

• For Windows and Linux, both 32 and 64 bit (x86 only) and with full source code
• Fat-reduced, no static runtime library, no dependency to non-preinstalled system component
• Can load ELF files, no need for avr-objcopy
• Can load von-Neumannized HEX files and extract eeprom / fuse / lock / signature data
• Can check signature of target device against data in HEX or ELF file
• Support for TPI (6-pin AVR) devices
• Support for both InpOut32.dll and giveio.sys (Windows executables), using ioperm() or /dev/port (Linux executables)
• Chip insert message per MessageBox() when running from IDE (Windows executables)
• Informative fuse decoding and showup, including factory defaults

• The chip programmer
• Super-tiny AVR disassembler including most AVR I/O space names, for later inclusion into avrpp
• Screenshot while reading ATtiny24 with simple command line avrpp -r (Have a look at fuse decoding at bottom!)

AVR ATmega32U4 USB bootloader + downloader

There is ubaboot with only 512 byte size. That replaces the original 4 KByte boot loader. I squeezed the boot loader from a Github assembly source to deliver helpful string descriptors. Moreover, I decided to keep on USB VID+PID from Atmel as they use the same driver architecture relying on „good old“ libusb0.sys + libusb0.dll. No USB class is actually used to fit into the 512 byte (256 instructions) space; USB classes (as HID which wouldn't need user-supplied drivers on Windows) need more space for the firmware. Written in Gnu Assembler (gcc) using its local label feature.

See there for more information and download. That downloader supports ELF files at input but doesn't handle EEPROM download.

PIC16F145x USB bootloader + downloader

See there for more information and download. That downloader supports ELF files at input. It doesn't handle EEPROM download as there is no EEPROM but so-called 256 Byte High-Endurance-Flash (HEF) at the end of Flash space. (That area can be read as any other Flash space, e.g. at address 0xFF00 .. 0xFFFF. Only the lower 8 bits are accessible and of high-endurance.) The downloader also fully supports the test monitor of the boot loader with symbolic and bit-wise register access.

STM32F USB bootloader + downloader

• For STM32F103 aka Blue Pull:
  • Firmware {arm-none-eabi-gcc}. Currently, the firmware is fixed to flash an LED at PB12. Simply change main.h accordingly and recompile for your LED connection.
  • flashing LED example using BitBanding address space, C++11 constexpr function and tiny linker script for that bootloader (i.e. offset flash start)
  • CMSIS = Arm's Common Microcontroller Software Interface Standard, fat-reduced for STM32F10x and gcc
• For STM32F401 aka BlackPill from WeAct:
  • flashing LED example using BitBanding address space and tiny linker script
  • CMSIS = Arm's Common Microcontroller Software Interface Standard, fat-reduced for STM32F4xx and gcc
• For both or possible all STM32F chips:
  • stm32flash + source {MSVC6, MSVC2008}
  • hid-flash + source {MSVC6, MSVC2008, Linux}

See there where I use it (i.e. the reason why I rewrote all the stuff from Github source).

The big CMSIS header files (Σ 780 KByte) remain. However, only the needed files are included in the archives.

All (my) source files are changed to C++ for easier maintenance.

How to use?

• For STM32F103 board, also known as “blue pill” board: You have to replace the preprogrammed boot loader by my 2K boot loader:
  • Use a serial connection, typically using a USB-Serial converter.
  • Activate uneraseable serial boot loader by placing jumper on BOOT0 and press RESET button.
  • Use my stm32flash to flash my 2K boot loader. (It is functionally compatible to github source. Even vid_1209&pid_BEBA is the same. However, I added more HID compliant “feature requests” instead of their “magic packets” containing "BTLDCMD". My hid-flash supports both.) It will reset the chip afterwards, that will activate my boot loader. You may also use the ST-LINK software for flashing, but IMHO that's cumbersome.
  • From now on, forget the serial connection and the BOOT0 jumper!
    • Powering up the STM32 will jump to your application when flashed. Otherwise, my boot loader remains active.
    • Pressing RESET button always invokes my boot loader.
    • Use my hid-flash to flash/update your application. By your linker script, your application must start at address 0x08000800.
    • To leave my boot loader and jump to your application, you can
      • power-cycle the STM32
      • invoke hid-flash start
    What's the advantage? Much simpler usage, no timeouts, and more free flash space for your application, compared to some older Arduino-based solutions that eat up 20 KiByte and require quite fast action after RESET button press.
• For factory-new STM32F103 chip: You have to program my 2K boot loader. Same procedure as above, except that you possibly have another access to controller pins rather than a button and a jumper. For really clean STM32F103 devices, you have no need for accessing the RESET and BOOT0 pins of the chip as the empty chip will fall into the non-eraseable serial bootloader mode.
  What's the advantage? No need for serial connection anymore, no need for BOOT0 pin access for firmware upgrade, for a little loss of 2 KB flash space.
• For STM32F401/411 board, also known as “black pill” board:
  • They come with the old-style boot loader with no HID Feature requests but “magic packets” containing "BTLDCMD" as above. Or with a boot loader that dims the C13 LED up-and-down and uses "WeAct:" as magic. It is auto-detected by 64 byte out-report size and 0 byte feature-report size. Not counting a not-really-present report ID byte handled by operating system. Github source?
  • Recently I added a match to vid_0483&pid_572A into my hid-flash program, which is the ID of the officially-STM-supported boot loader, which is different to the STM32F103 one.
  • By your linker script, your application must either start at address 0x08004000 or at address 0x00004000. The latter case uses the memory remap option of STM32F4xx which defaults to Flash mapping. Arduino software does this automatically.
  • To enter the WeAct boot loader again, you have to hold the KEY button while you press the NRST button. Cumbersome. NRST alone will start your application.
• For factory-new STM32F401/411 chip: Very probably, that driverless USB-HID bootloader is not preprogrammed. Either you stick on my stm32flash but need a Zadig (universal USB) driver to access in Windows. Or … I don't know.

GALEP-III and GALEP-IV driver

No new programmer software but a signed(!) driver for Win64. So users can run their expensive programmer on newest computers with Windows 10/64. Moreover, a full schematic of GALEP-III allows for developing programmer software for including newer chips to program.

See there for more information and download.

RAM/EPROM simulator PEPS-III downloader

See there for more information and download.

ESP8266, ESP32, and ESP32xx downloader

That Unofficial SDK compiles quite fast and is Makefile-based. But the esptool (flashing utility) lacks on various Python dependencies and doesn't work with ESP32.

So I decided to rewrite the esptool in C++. At first for Windows, later maybe for Linux. Command-line compatibility is not the most important thing. Easy use is more important! Some features:

• No need for noting COM port nor baudrate on command line. As this is a user-specific setting, it is not the right place for Makefiles. A COM port selection dialog (showing descriptive strings and their parent in hardware tree) automatically pops up when needed, and all settings are persistently saved in the registry.
  • Example: See screenshot
• No need for providing load addresses for binary files when (recommended) included inside the file name as @hexaddr. Alternatively, load addresses can be given by prepending the file name with addr:, no more by extra arguments.
  • Example: esptool write_flash bootloader@1000.bin parttab@8000.bin 0x10000:myfirmware.bin (program all three files while myfirmware.bin doesn't contain load address in file name, not recommended)
  • Example: esptool verify_flash bootloader@1000.bin (compare flash content with file using SHA-256 hash)
• Length arguments are given as another prefix when reading RAM or Flash.
  • Example: esptool read_flash L0xC00:parttab@8000.bin
  • In case of well-known base addresses 0x1000, 0x8000, and 0x10000, length is auto-detected by checking overall image size while reading (as esptool „knows“ that flash contents are almost always ESP Image files)
• Support for nested ESP Image files: One file for flashing all sections!
  • Example: esptool -o=bundle.bin make_image bl@1000.bin pt@8000.bin fw@10000.bin (Build bundle. The “=” can be also space, colon, or omitted.)
  • Example: esptool write_flash bundle.bin (Flash the bundle. esptool auto-detects by missing address.)
• Wildcard support: Flash multiple files with shorthand write_flash *.bin
• Direct support for ELF files when flashing, no intermediate Image files necessary (but still good for distribution) — under construction
  • Example: esptool write_flash firmware@10000.elf (update firmware, not the second bootloader or „partition table“ {I would say „root directory“})
• Support of (hopefully) all ESP32xxx devices
• Compression support, direct handling of gzip files
  • Example: esptool write_flash firmware@10000.bin.gz (In this case, compressed data is directly fed to the ESP32 controller, no inflate or deflate is involved as ESP32 self-inflates the data stream.)
  (later possibly zip files, why not?)
• No dependencies to non-standard DLL files, no Python runtime, no invocation of external programs, built-in ELF file handling
• Bilingual output (englisch/german), extensible by Resource Editing
• Colored output (todo)

Current software

Reset at ESP32CAM

Problem: One of some bought ESP32CAM was able to bring into boot mode by USB-Serial adapter. AFAIK impossible because RESET is not available on pin headers, or is there a backdoor? Possibly using long Break condition?

Solution: RESET is available on pin headers for newer ESP32CAM! One former GND pin is now changeable to RESET by solder jumper (0 Ω resistor SMD 0603 size), and defaults to RESET at shipping. GPIO0 (apply L to enter boot mode while RESET gets the L/H edge) was and is always available at pin headers.