Flash bootloader then program

Hi folks.

I can successfully flash my bootloader using ‘pio run --target bootloader’ and I can build and upload my program using the normal means. Is there a way I can do this as a single operation? Have it automatically upload the program if the bootloader upload returns successfully?

I just often am precariously holding my programmer cable (A six pin piston header with 1.25mm pitch - the boards are very small - no room for a header!) with one hand, so it’d be less laborious if I wasn’t juggling keyboard shortcuts with the other hand as I program lots of boards in a batch.

I’m sure someone has done it, please point me in the right direction. :slight_smile:

You can give multiple -t targets.

So,

pio run -t bootloader -t upload

will burn the bootloader and then the regular firmware.

This is documented behavior.

https://docs.platformio.org/en/latest/core/userguide/cmd_run.html#cmdoption-pio-run-t

Oh great. Thanks.

And thanks for the pointer to the documentation. I’ll be honest, I have a really hard time with it. I appreciate the enormous amount of work that has gone into it, but somerthing that is never clear to me why some things can be achieved in platformio.ini and others require an extra_scripts python file.

I have a situation now where I’m trying to drop the speed for the initial bootloader and fuse uploading. A simple “-B 4” in the avrdude command. Easy to test with upload_flags. I tried:

board_bootloader.upload_flags =
    -B 4

surmising that variables for the default target might also work for the bootloader target, but that doesn’t work. So I added extra_scripts = extra.py to platformio.ini and put the following in extra.py:

Import("env")

env.Append(
    BOOTUPLOADERFLAGS=[
        "-v"
    ]
)

Just to force a verbose output before changing it to “-B 4”. No dice. If I put a print(“hello”) into the python it does print to the terminal, so it has found and is reading the file… it just isn’t parsing the stuff.

Any ideas?

So my issue here was I hadn’t realised the fuse writing and bootloader writing had independent flags. It was the fuse writing that was failing, not the bootloader writing. This definitely could be clearer. I think most folks would expect the same flags for both, as the primary use-case for special flags when programming an unused device is managing it’s low-speed, all internally-clocked factory setup.

I think a note in the bootloader programming section of the documentation would be helpful, to help folks realise this? Or just have FUSESUPLOADERFLAGS adopt BOOTUPLOADERFLAGS if the former is not explicitly set.

In any case, this extra.py got me the result:

Import("env")

env.Append(
    FUSESUPLOADERFLAGS=[
        '-V', '-B 4',
    ],
    BOOTUPLOADERFLAGS=[
        '-V', '-B 4',
    ],
)