mihaigalos / miniboot

🏗️ An I2C bootloader for Arduino.

Miniboot - an I2C bootloader for Arduino

Miniboot is an I2C bootloader for Arduino, tested on AtMega328p. It is designed to reflash the Mega328p with code residing in an external I2C memory or another I2C device. For testing, CAT24M01 1Mbit (128kByte) external EEPROM was used.

Requirements

Miniboot depends on avr-bootloader-common for commonalities between bootloaders. This dependency will be automatically downloaded by bazel so you don't have to.

Flash size requirements are <2kBytes. With respect to RAM, AtMega328p's 2kBytes should be enough, actual stack usage is way lower than that anyway.

$ avr-size -B miniboot.elf
   text    data     bss     dec     hex filename
   1944       0       0    1944     798 miniboot.elf

Usage

Flash the correct fuses

Please use the following reccommended fuses, or compatible:

miniboot/src/miniboot.c

Line 2 in 995c05d

// Fuses : Ext: 0xFF, Hi: 0xD8, Lo: 0xE2

Get the sources

git clone --recursive https://github.com/mihaigalos/miniboot.git

Build the hex

Building is managed by bazel, so make sure you have it first.

• bazel build --config=328p --verbose_failures //:miniboot.elf
• bazel build --config=328p --verbose_failures //:miniboot_hex

Once Miniboot starts

Miniboot reads the metadata header and it starts reflashing the microcontroller with the information stated there. It expects the following memory layout of the metadata in the (external) I2C memory:

• [last free byte pointer] : 2 bytes - should point to first byte after the appplication. Ignored.
• ['m' 'i' 'n' 'i' 'b' 'o' 'o' 't'] : 8 bytes.
• [name of application] : 10 bytes - user defined.
• [timestamp application] : 4 bytes - unix timestamp when the application in the I2C memory was generated.
• [timestamp of write] : 4 bytes - unix timestamp when the application was flashed to the I2c memory.
• [CRC32] : 4 bytes - generated with polynomial representation 0xEDB88320. Details in Drivers/CRC.
• [length] : 2 bytes - amount of bytes for the application.
• [application] : length bytes - actual payload of the application code.

Miniboot computes a CRC32 checksum on the payload, excluding the header metadata and starting with the first byte of the application. It is important that the length be at byte location 32 and the application start at byte 34.

Bootloader start address

Miniboot can be modified to place the bootloader code at a specific address, via the macro BOOTLOADER_START_ADDRESS. Please ensure that the address lies in the bootloader section, specified by the High fusebits. I recommend using at least 1024 words (2048 bytes) for the bootloader section (Hi fuse : 0xD8). If you choose to modify miniboot, please ensure that your new bootloader fits in the section you specify with the Hi fuse.

Computing the hexadecimal address for bootloader start section:

• bazel clean; bazel build --config=328p --verbose_failures //:miniboot_hex ; take output, let's say it's 2123 (or similar).
• for the size of your device (32kB = 1024 * 32 = 32768 bytes) minus above value 2123... = 30645.
• Which yields 30645 / 128 (128 = mega328p page size in bytes) = 239.41 pages of flash memory.
• round it down to 239 - our new bootloader address is 239 * 128 = 30592, in hex = 7780h.
• put the value in the BOOTLOADER_START_ADDRESS variable in the BUILD file.

Internal EEPROM last application timestamp

After running, miniboot writes the application timestamp (specified earlier) to 4 bytes in the microcontroller's internal EEPROM. The next time the system restarts, it will compare the application's timestamp with the information it reads from the internal eeprom and will only rewrite it again if the timestamp is different or the internal eeprom is unprogrammed (4 bytes of 0xFF). This prevents a new unnecessary rewrite on each system restart.

The variable EEPROM_CONFIGURATION_START_BYTE can be edited to generate the desired macro in bootloader.h for the above logic.

Storing the application in the external EEPROM

Create the binary file

Export the hex file of the application (the one you want to transfer to the I2C memory) to binary before continuing:

avr-objcopy -I ihex application.hex -O binary application.bin

Send it!

Disclaimer: At the time of this posting, I was using Windows. Sigh.

We finally want to send it over to the microcontroller which will write it to the I2C memory.

You may choose to use the UART method or the Monolithic Binary Method.

• The Monolithic Binary Method: creates a sketch with Arduino which contains a copy-pasted version of the application.hex and its associated metadata filled in manually.
• The UART Method: uses YAT Terminal to fill in the application payload and metadata in the external EEPROM.

I personally think the UART Method is easier and more generic.

Please be aware, the metadata needs to be present alongside the payload. Without proper setup of the
metadata (i.e. : timestamp and CRC), the payload will be ignored by miniboot and not be reflashed.

The Monolithic Binary Method

Don't let the name scare you. 😀

You can compose your metadata by hand, using my eeprom driver, store both the metadata and the payload in the external I2C, for miniboot to use. Have a look at the blink_hex variable in intel_hex.cpp. You need to compile the example sketch and flash the MCU with it. Once it runs successfuly, you will have the code in the external I2C EEPROM.

The UART Method

Br@y's Terminal is broken when using the send file feature. Use YAT Terminal to send the file via UART instead.

First, the Arduino board needs to be flashed with the miniboot_uart_to_eeprom_uploader.hex sketch which can be found in the Drivers/Eeprom/bin folder in this repo. This will read from the UART and will put the information in the external I2C memory.

At this point, you will need a USB to UART bridge hooked up to your Arduino's UART.

In YAT, go to Terminal->Settings and select your baudrate:

• If your Arduino is running at 16Mhz : select 600 bits per second.
• If your Arduino is running at 8Mhz or have a custom board runing at 8Mhz: select 300 bits per second.

The low baudrate ensures the external EEPROM has time to write the payload it receives, since the communication is asynchronous.

When asked to do so, follow the instructions to input the application unix timestamp, the unix timestamp of the time of writing, crc value and the data length. For the unix timestamp, you can use the epoch converter. For computing the crc32 on your binary file, drag and drop the application.bin created earlier in the webpage found here.

You will next be prompted to switch to binary mode and send the binary file.

YAT tries to parse the \r\n sequence when sending, which leads to an error being shown and the transmission is interrupted, the file is not fully sent. To overcome this, ->select Terminal Type: binary. Select Binary Settings... and uncheck everything.

Next select the exported binary file (application.bin) and click Send File.

You should now be able to send the file in full.

No global variables

Miniboot uses no global variables. Thus you can call bootloader functions from the application, without worrying that the application's variables will get overwritten by the bootloader code.

Why should you care, you may ask? Well, if you find you need to compile and link functions which are already present in miniboot, you can just call them from your application to miniboot, potentially reducing the application size.

More details in Section # 14 (Can the application use code built into the bootloader) of doc/bootloader_faq.pdf or AvrFreaks.

License

This software is freely available under the GNU GPL v3.0 aegis, please consult the LICENSE file for further information.

miniboot's Issues

Switch I2C address with switch

Hey, me again :)

So originally I was using an AT24C256, but I grabbed some CAT24M01's, and noticed that they have 2 "partitions" it seems.

(Regardless of the chips used, it would also be nice to have an easy way to switch the address via a switch instead of reuploading the bootloader :) )

I removed the constexpr qualifier from the address definition, added the i2c_address to isReflashNecessary, and... the code doesn't fit in the bootloader section.

I could double the word count with fuses (Nope, I'm at the max word count with the 32u4, and did get it working by moving the bootloader to 0x7000. but sometimes when erasing flash, it would wipe the bootloader), but I'm wondering if I can scrape every byte I can with some neat tricks.

In io.h I added

#define SWITCH_INPORT(name) CONCAT(PIN, name)
#define SWITCH_OUTPORT(name) CONCAT(PORT, name)
#define SWITCH_INIT() OUTPORT(SWITCH_PORT_NAME) = OUTPORT(SWITCH_PORT_NAME) & ~(1 << SWITCH_PIN); SWITCH_OUTPORT(SWITCH_PORT_NAME) &= ~(1 << SWITCH_PIN)
#define SWITCH_READ() SWITCH_INPORT(SWITCH_PORT_NAME) & (1 << (SWITCH_PIN))

And changed source_i2c_address_for_program depending on SWITCH_READ

If you can give any input, I'd be grateful!

Edit: fix typo and fuse info

Error in the generated bootloader.h made by the Makefile

pi@raspberrypi:~/XX-Core/arduino/miniboot/src $ make rebuild

-------- start --------

Cleaning project:
rm -f miniboot.hex
rm -f miniboot.eep
rm -f miniboot.obj
rm -f miniboot.cof
rm -f miniboot.elf
rm -f miniboot.map
rm -f miniboot.obj
rm -f miniboot.a90
rm -f miniboot.sym
rm -f miniboot.lnk
rm -f miniboot.lss
rm -f miniboot.o I2C-master-lib/i2c_master.o
rm -f miniboot.lst I2C-master-lib/i2c_master.lst
rm -f miniboot.s I2C-master-lib/i2c_master.s
rm -f miniboot.d I2C-master-lib/i2c_master.d
rm -f .dep/*
rm -f bootloader.h
Errors: none
-------- end --------

avr-g++ (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling: miniboot.c
avr-g++ -c -mmcu=atmega328p -I. -g -Os -pedantic -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Werror -Wa,-adhlns=miniboot.lst -std=gnu++11 -DF_CPU=8000000UL -MD -MP -MF .dep/miniboot.o.d miniboot.c -o miniboot.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from miniboot.c:6:0:
bootloader.h:2:1: error: expected unqualified-id before ‘-’ token
-en
^
Makefile:258: recipe for target 'miniboot.o' failed
make: *** [miniboot.o] Error 1

Issue with large programs

Hi Mihai,

I have an issue with flashing larger sketches of up to 28kB. I did all the testing with sketch sizes of around 2kB and everything works just fine. But with the larger files I had some trouble. I'm sure that the header and the program is stored correctly on the EEPROM.
I changed the bootloader that way: while the CRC is checked a green LED is flashing and while writeFlashFromI2C is executed, a red LED is flashing. With toggling every 128byte I would expect ca. 109 on/off cycles with a 28kB program. It appears to me that the program is only partially checked.
However, the crc == expected_crc appears the be true because it goes to writeFlashFromI2C afterwards. At the end the LED is turned off and nothing happens afterwards. The application does not start.
Any suggestion on what could be the problem?

Thanks a lot!
Felix

Fuses:
Hi Fuse: 0xD8
Lo Fuse: 0xD2

Unrecognized option: --distinct_host_configuration=false

Clean install of Ubuntu 23.04, installed bazel from apt.

root@Workspace:~# bazel version
Build label: 7.0.2
.....

root@Workspace:~# mkdir workspace && cd workspace/
root@Workspace:~/workspace# git clone --recursive  https://github.com/mihaigalos/miniboot.gitcd && cd miniboot/

root@Workspace:~/workspace/miniboot# bazel build --config=328p --verbose_failures //:miniboot.elf
Starting local Bazel server and connecting to it...
INFO: Found applicable config definition build:328p in file /root/workspace/miniboot/.bazelrc: --crosstool_top=@avr_tools//tools/avr:toolchain_avr --distinct_host_configuration=false --cpu=avr --define MCU=atmega328p
ERROR: --distinct_host_configuration=false :: Unrecognized option: --distinct_host_configuration=false

root@Workspace:~/workspace/miniboot# vi .bazelrc
# Removed --distinct_host_configuration=false

root@Workspace:~/workspace/miniboot# bazel build --config=328p --verbose_failures //:miniboot.elf
WARNING: --enable_bzlmod is set, but no MODULE.bazel file was found at the workspace root. Bazel will create an empty MODULE.bazel file. Please consider migrating your external dependencies from WORKSPACE to MODULE.bazel. For more details, please refer to https://github.com/bazelbuild/bazel/issues/18958.
INFO: Analyzed target //:miniboot.elf (69 packages loaded, 319 targets configured).
ERROR: /root/workspace/miniboot/BUILD:51:10: Compiling src/miniboot.cpp failed: (Exit 1): gcc failed: error executing CppCompile command (from target //:miniboot.elf)
  (cd /root/.cache/bazel/_bazel_root/c2d1d1fca9699ae911e5d72b4f92e7cf/sandbox/processwrapper-sandbox/3/execroot/_main && \
  exec env - \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++14' -MD -MF bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/miniboot.pic.d '-frandom-seed=bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/miniboot.pic.o' -fPIC -iquote . -iquote bazel-out/avr-fastbuild/bin -iquote external/avr-bootloader-common -iquote bazel-out/avr-fastbuild/bin/external/avr-bootloader-common -iquote external/bazel_tools -iquote bazel-out/avr-fastbuild/bin/external/bazel_tools -Ibazel-out/avr-fastbuild/bin/external/avr-bootloader-common/_virtual_includes/avr-bootloader-common -isystem src -isystem bazel-out/avr-fastbuild/bin/src -isystem external/avr-bootloader-common/include -isystem bazel-out/avr-fastbuild/bin/external/avr-bootloader-common/include '-DF_CPU=8000000UL' -fdiagnostics-color -fpack-struct -fshort-enums -funsigned-bitfields -funsigned-char -g -lm '-Wl,--relax,--gc-sections,-Map=miniboot.map' '-Wl,--section-start=.text=0x7800' '-mmcu=atmega328p' -Os -pedantic '-std=gnu++14' -Wall -Werror '-Wl,-Map=miniboot.map,--cref' -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c src/miniboot.cpp -o bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/miniboot.pic.o)
# Configuration: 5c091e33c4f4cae2263b72c5ad9270f33c6128367db4ddf13c8a3fe28c525286
# Execution platform: @@local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
gcc: error: unrecognized command-line option '-mmcu=atmega328p'
ERROR: /root/workspace/miniboot/BUILD:51:10: Compiling src/i2c_master.cpp failed: (Exit 1): gcc failed: error executing CppCompile command (from target //:miniboot.elf)
  (cd /root/.cache/bazel/_bazel_root/c2d1d1fca9699ae911e5d72b4f92e7cf/sandbox/processwrapper-sandbox/2/execroot/_main && \
  exec env - \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++14' -MD -MF bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/i2c_master.pic.d '-frandom-seed=bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/i2c_master.pic.o' -fPIC -iquote . -iquote bazel-out/avr-fastbuild/bin -iquote external/avr-bootloader-common -iquote bazel-out/avr-fastbuild/bin/external/avr-bootloader-common -iquote external/bazel_tools -iquote bazel-out/avr-fastbuild/bin/external/bazel_tools -Ibazel-out/avr-fastbuild/bin/external/avr-bootloader-common/_virtual_includes/avr-bootloader-common -isystem src -isystem bazel-out/avr-fastbuild/bin/src -isystem external/avr-bootloader-common/include -isystem bazel-out/avr-fastbuild/bin/external/avr-bootloader-common/include '-DF_CPU=8000000UL' -fdiagnostics-color -fpack-struct -fshort-enums -funsigned-bitfields -funsigned-char -g -lm '-Wl,--relax,--gc-sections,-Map=miniboot.map' '-Wl,--section-start=.text=0x7800' '-mmcu=atmega328p' -Os -pedantic '-std=gnu++14' -Wall -Werror '-Wl,-Map=miniboot.map,--cref' -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c src/i2c_master.cpp -o bazel-out/avr-fastbuild/bin/_objs/miniboot.elf/i2c_master.pic.o)
# Configuration: 5c091e33c4f4cae2263b72c5ad9270f33c6128367db4ddf13c8a3fe28c525286
# Execution platform: @@local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
gcc: error: unrecognized command-line option '-mmcu=atmega328p'
Target //:miniboot.elf failed to build
INFO: Elapsed time: 3.074s, Critical Path: 0.05s
INFO: 5 processes: 4 internal, 1 processwrapper-sandbox.
ERROR: Build did NOT complete successfully

I am stuck. Any help would be appreciated.
-Adam

Escape the double quotes

miniboot/scripts/post_summary.sh

Line 9 in c4ada3c

-d "{"body": "${push_message}"}" \

curl -H "Authorization: token ${GITHUB_TOKEN}" -X POST \
    -d "{\"body\": \"${push_message}\"}" \
    "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"

Bootloader corrupting code

Hello,
for few days now I'm debuging a weird issue with miniboot. I'm attaching arduino sketch file + hex sources that will fill i2c memory with a program. Then after a bootloader is loaded to device it starts loading data to internal flash, and then the soft wont start (it just loops on main() of the miniboot as theres nothing to update due to timestamps).

By downloading flash to hex I have noticed that 2 bytes of the code sitting in flash are beeing changed. Whats funny - its always the same bytes, and the resulting "corruption" always have the same values..

What bootloader put in flash:
:200000000C94**003C**0C9452010C9452010C9452010C9452010C9452010C9452010C9452015F

What does the original data in eeprom look like:
0C94**2A01**0C9452010C9452010C9452010C9452010C9452010C9452010C945201

Bolded the issue.
The atmega, and eeprom are fine.
Any idea?

Thank you

this_is_saved_to_eeprom.zip

what_bootloader_put_in_flash.zip

test.zip

Question: Upload sketches from i2c Master with Ethernet webgui to i2c address slaves?

Would this bootloader allow you to update the sketches on many i2c Arduino slaves from an Arduino ethernet master. Like, say the master runs a website with an input box where you would select a compiled Arduino sketch in hex and select the slave address you want to upload on the i2c bus, which would then dump to the sketch to the appropriate i2c slave address on the bus?

[Master] Basically a Leonardo with Ethernet (wiznet)
https://www.dfrobot.com/product-1286.html

Upload sketch from webgui to i2c slave @ address 10 on the bus
blinkaddr10.hex/select addr10 => Webgui => ethernet => [Master]DFR0342 => i2c => address10 => [Slave@Addr10]ArduinoMicroEtc (slave 10 changed to new sketch uploaded)

Upload sketch from webgui to i2c slave @ address 11 on the bus
blinkaddr11.hex/select addr11 => Webgui => ethernet => [Master]DFR0342 => i2c => address11 => [Slave@Addr11]ArduinoMicroEtc (slave 11 changed to new sketch uploaded)

Thanks!

I2C master library is not available anymore

https://github.com/g4lvanix/I2C-master-lib/

Seems to be gone.
Is there a way to still build miniboot?

Question regarding the binary file upload

Thanks a lot for the great work! I have been trying to upload the program to the eeprom. In my case the I2C lines are connected to a pin of the mcu. I do this to disable I2C to reduce power consumption (battery power application). I changed the bootloader that I2C communication works. But...
I tried using the miniboot_uart_to_eeprom_uploader.hex but I doesn't seem to work in my case. Could you provide the sketch of the program?
Thanks

TRAVIS_PULL_REQUEST

miniboot/scripts/post_summary.sh

Line 14 in 995c22f

"https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"

Should check the value of TRAVIS_PULL_REQUEST, it may be false.

Environment Variables - Travis CI

TRAVIS_PULL_REQUEST is set to the pull request number if the current job is a pull request build, or false if it’s not.

Makefile won't rebuild

pi@raspberrypi:~/XX-Core/arduino/miniboot/src $ make rebuild

-------- start --------

Cleaning project:
rm -f miniboot.hex
rm -f miniboot.eep
rm -f miniboot.obj
rm -f miniboot.cof
rm -f miniboot.elf
rm -f miniboot.map
rm -f miniboot.obj
rm -f miniboot.a90
rm -f miniboot.sym
rm -f miniboot.lnk
rm -f miniboot.lss
rm -f miniboot.o I2C-master-lib/i2c_master.o
rm -f miniboot.lst I2C-master-lib/i2c_master.lst
rm -f miniboot.s I2C-master-lib/i2c_master.s
rm -f miniboot.d I2C-master-lib/i2c_master.d
rm -f .dep/*
rm -f bootloader.h
Errors: none
-------- end --------

sh: 1: avr-g++: not found
Makefile:205: recipe for target 'gccversion' failed
make: *** [gccversion] Error 127

LED just blinks quickly, program never flashes

Hi! I think I'm doing something wrong here and could really use some help

I'm wanting to use this on an ATMega32u4 (Arduino Micro) later on, but I wanted to make sure I can get everything working on a 328P first. I'm using a Nano for these tests.

After uploading the given .hex for the UART method, I used CuteCom (Linux) to upload a basic Blink sketch, and using E2PROM::dump, I get this

After burning the compiled miniboot.hex with the given fuses in miniboot.c, the led on PB0 (Arduino pin 8) just blinks forever, around 4x a second?

I'm pretty stumped and could use any advice you can muster.

Application fails to load from external memory

Hello,
I'm trying to have a go with miniboot under Windows 10 using bus pirate as isp, but the application fails to load to an arduino nano. I am writing a short step by step both for help and for reference for others possibly reading this.

I am burning the fuses:
avrdude -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cbuspirate -PCOM5 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF)

I burn miniboot:
avrdude -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cbuspirate -PCOM5 -Uflash:w:"D:\Path_to\miniboot\bin/miniboot.hex":i -Ulock:w:0x0F:m

.. Reading | ################################################## | 100% 4.82s
avrdude: verifying ...
avrdude: 3732 bytes of flash verified
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as FD
avrdude: safemode: Fuses OK (E:FD, H:DA, L:FF)
BusPirate is back in the text mode
avrdude done. Thank you.

At this point the stock bootloader is replaced, because I can't upload programs via USB from the IDE anymore. I can reverse this by rewriting the stock bootloader* which indeed gives the USB upload feature back. So miniboot should exist on the board.

I upload miniboot_uart_to_eeprom_uploader.hex:
avrdude -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cbuspirate -PCOM5 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m
avrdude -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cbuspirate -PCOM5 -D -Uflash:w:D:\Drivers\Eeprom\bin/miniboot_uart_to_eeprom_uploader.hex:i
My target application which I attach in .ino/.hex/.bin forms is converted using:
avr-objcopy.exe -I ihex application.hex -O binary application.bin
I am using Arduino 1.8.9 for extracting the .hex (Ctrl+Alt+S). The .hex file is extracted using "Arduino Pro or Pro Mini" board selection from the IDE.
I am greeted with the prompt using a serial program, followed by my input:

-- Miniboot EEPROM uploader --
Application unix timestamp (decimal):
1570787025
Current unix timestamp (decimal):
1570787235
CRC32 (hex):
b21a3e26
Application size (bytes, decimal):
2180 (I get this from opening the .bin with Notepad++)
Header written. Please switch to binary mode and send a file of byte length 2180.

At this point, I tried both TeraTerm on Win10 and YAT on Win7 (can't get it to work on Win10 yikes). I upload the .bin using binary mode and it completes. I then dump the contents of CAT24M01 . Using a hex to ascii converter, I can see "Heminibootblink" in the beginning as you describe in README (address byte followed by "miniboot" and "blink" name from the library).
However, the application does not run. When I restart the board, it reruns miniboot_uart_to_eeprom_uploader. I also checked internal EEPROM and it is empty.

Any ideas? I can try different tests but I am kinda lost here. I appreciate your effort and input. If I can contribute somehow, let me know.

As a sidenote, when I clone and run
make rebuild
under /src I get:

The system cannot find the path specified.
ECHO is off.
-------- start --------
ECHO is off.
Cleaning project:
rm -f miniboot.hex
process_begin: CreateProcess(NULL, rm -f miniboot.hex, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [clean_list] Error 2

Using GnuWin32 and by adding it to PATH.

*for burning stock bootloader avrdude -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -cbuspirate -PCOM5 -Uflash:w:"C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex":i -Ulock:w:0x0F:m