Chip Bootloader and Downloader

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)

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

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!)

I found ubaboot on Github with only 512 byte size. It replaces the original 4 KByte Atmel boot loader or the 2 KByte Caterina boot loader on Arduino boards. I further squeezed that Github source to make room for 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 and simply would not fit. Written in Gnu Assembler (gcc) using its local label feature. Suitable for at90usb82, at90usb162, atmega8u2, atmega16u2, atmega32u2, atmega16u4, atmega32u4.

To install ubaboot, i.e. to overwrite any boot loader, you need an ISP programmer once. Most boards have a 6-pin header for doing this.

Moreover, I rewrote the Python download tool to a true Windows executable.

• No external dependencies (except Windows95 at least). No python3, pip, pyusb, to name some.
• Supports ELF files at input, no need for using avr-objdump tool.

See there for more information and download.

See there for more information and download.

• 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.

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.

See there for more information and download.

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?

Both modules to compare
Differences in deatil

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.