Arduino IDE option for optiboot with version 3.0.0

[vickash]

I'm using this to repurpose old 3d printer boards (8-bit Ender-3 with 1284p). I have one with a MOSI pin that stopped working, so it's stuck with optiboot.

Uploading from the Arduino IDE worked fine in 2.2.2, but with 3.0.0 I get this error: avrdude ur_initstruct() error: bootloader might be optiboot 5.0? Please use -xbootsize=<num>

I can copy the avrdude command into terminal, then add -xbootsize=512 and it works, but could this be added as an option in the IDE menus too? Thanks!

[MCUdude]

Hi, and thanks for reporting!

The bootloader that's already in there, was this pre-installed, or did you flash this yourself? Avrdude thinks this is an old version of Optiboot, much older than what MightyCore has been using for years. I don't have any issues when uploading programs using Optiboot bundled with MightyCore v2.2.2 and the latest v3.0.0 -c urclock uploader.

The problem with adding -xbootsize=512 for all targets is that it will break uploads for newer Optiboot versions. For instance, the Optiboot bootloader MightyCore used in v2.2.2 for ATmega1284P would require -xbootsize=512

I'm not sure why -c urclock needs to know the boot size for older Optiboot versions. @stefanrueger probably knows why though.

Since you're stuck with (an older version of) Optiboot, and I don't have a clean fix to provide at the moment, I suggest downgrading to MighyCore v2.2.2 for now.

[stefanrueger]

I'm not sure why -c urclock needs to know the boot size for older Optiboot versions

avrdude -c urclock needs to know the boot size in order to protect the bootloader from overwriting itself (as optiboot would happily do if you let it) and to know where to jump if it is a vector bootloader. Optiboot does not advertise its size, but AVRDUDE knows the checksum of a few hundred optiboot versions and therefore recognises popular recent ones. Well, if you are stuck with a damaged part that cannot be reflashed then manually adding -xbootsize=512 seems like a good workaround.

[MCUdude]

Even though the Sanguino bootloader is less than 512 bytes in size, the smallest possible boot sector on the ATmega1284P is 1024 bytes. I installed the Sanguino bootloader on an ATmega1284P, but I could only get it to work with -xbootsize=1024. With -xbootsize=512 uploading failed, and the bootloader stopped working, and I had to re-flash it using an ISP programmer.

[vickash]

Thanks for the explanation.

I'm not sure what version is on it. It was updated from stock (no bootloader) to optiboot + Marlin 2.0 quite a few years ago.

The command line will do for this one then. I've had no problem getting urboot onto the others.

I could only get it to work with -xbootsize=1024. With -xbootsize=512 uploading failed, and the bootloader stopped working, and I had to re-flash it using an ISP programmer.

I tested 1024, and both worked, so will stick with that to be safe. Thanks again.

[MCUdude]

I have just submitted a PR to the Avrdude project where I've added the Sanguino Optiboot bootloaders to a hash table that -c urclock uses to determine which non-urboot bootloader it is communicating with. With this PR I don't have to specify the bootsize "manually" anymore.

I think the PR will be merged very soon, and this "fix" will be available in the next Avrdude version, which I will bundle with MightyCore as soon as it's ready.

[szilvasyz]

Hi, Recently I run into a similar trouble, after updating MightyCore package to v3 form v2.2.2. I have an own devboard with a 1284 that we were playing with a year ago without uploading problem from the Arduino IDE. Now I can see the same "xbootsize" message if I run the simple "upload" from the IDE, the bootloader in the 1284 is likely a series 8 OptiBoot. I run into the same failure with the uploading both of my PCs I use; a 2016 MacBook Pro with the latest MacOS and a Dell Latitude E5440 with a well patched Win10. My temporary solution on both machines to add an "Arduino" type programmer to the MightyCore's programmers.txt and use "Upload using programmer" from the IDE, but is not a very comfortable way. I use Arduino IDE series 1.8, probably the latest. Although I can reflash my 1284 with the new urboot, but I think, the problem with old type bootloader-flashed chips is real. I have just got the package yesteday with new 1284s from a shop, I will check the urboot and actually downloadable OptiBoot too with them (I prefer flashing these AVRs with my TL866 by hi-V parallel method). BTW: is there any documentation on the fuses to be used with the bootloaders when flashing? Regards, Zoltan

[MCUdude]

Hi @szilvasyz. Do you know exactly which bootloader you have installed on your ATmega1284P? If not, can you dump the flash upload the hex file here so I can figure out which bootloader you have installed?

-c urclock can determine the -xbootsize by reading the bootloader content on the chip and comparing it with a set of known hashes. If you're using a bootloader that's in this list, you should be good to go. However, if you're using something else, it won't work without specifying -xbootsize.

What you can do is either replace the bootloader with Urboot or downgrade to MightyCore v2.2.2. Urboot is superior to Optiboot, and there's really no reason to not upgrade. v3.0.0 is a major version bump, which usually means breaking changes. -c urclock is backward compatible to an extent, but I can't guarantee that it will work with every Optiboot binary out there without specifying -xbootsize.

From urclock_hash.h:

    { 1024, 1, 0x70394fcf, 0xd85f6d82 }, // optiboot_flash_atmega1284p_UART0_57600_8000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x1fbd2028 }, // optiboot_flash_atmega1284p_UART0_38400_8000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0xed72231d }, // optiboot_flash_atmega1284p_UART1_38400_8000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x7f4a01a9 }, // optiboot_flash_atmega1284p_UART1_57600_8000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0xb0f7a5b8 }, // optiboot_flash_atmega1284p_UART1_38400_8000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0xc20575ef }, // optiboot_flash_atmega1284p_UART1_57600_8000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x88e15790 }, // optiboot_flash_atmega1284p_UART0_57600_8000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x55370f29 }, // optiboot_flash_atmega1284p_UART0_38400_8000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x6f4a2030, 0x96d5dbb4 }, // optiboot_flash_atmega1284p_UART0_9600_1000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x6f4a2030, 0x658f1f52 }, // optiboot_flash_atmega1284p_UART1_9600_1000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x6f4a2030, 0xbee18fbd }, // optiboot_flash_atmega1284p_UART1_9600_1000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x6f4a2030, 0x1fc522fc }, // optiboot_flash_atmega1284p_UART0_9600_1000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x10b83310 }, // optiboot_flash_atmega1284p_UART1_115200_20000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x39e2135a }, // optiboot_flash_atmega1284p_UART0_115200_20000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x3fc0adef }, // optiboot_flash_atmega1284p_UART0_115200_20000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0xa19ba944 }, // optiboot_flash_atmega1284p_UART1_115200_20000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x5bc6b3f2 }, // optiboot_flash_atmega1284p_UART1_115200_16000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x7ee4239d }, // optiboot_flash_atmega1284p_UART0_115200_16000000L_B7_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0x246eaa1b }, // optiboot_flash_atmega1284p_UART0_115200_16000000L_B0_BIGBOOT.hex
    { 1024, 1, 0x70394fcf, 0xc9469042 }, // optiboot_flash_atmega1284p_UART1_115200_16000000L_B7_BIGBOOT.hex

BTW: is there any documentation on the fuses to be used with the bootloaders when flashing?

No, but everything is in boards.txt. You can also turn on verbose upload in the IDE settings, and look at the actual fuse values the Avrdude command provides. The reason for not documenting the fuses is that they're not user-configurable, and that users don't have to know the exact fusebits to get their AVR up to speed. MightyCore/the IDE deals with this for them.

[szilvasyz]

Hi MCUdude,

First, I attached the hex file read from the bootloader area of my "old" 1284p. read_boot_1284p_231116.txt

Second, I have downloaded the actual urboot and optiboot bootloaders from here and flashed 1-1 "new" 1284 with them (the new chips are not PicoPower "p" marked ones, but as I remember from the documentation there are no differences in programming relations). The actual bootloaders both work with the IDE 1.8.16 and MightyCore 3.0 using the default (urclock) programmer.

Third, I found the following optiboot files on my virtual machine that is used for the TL866 programmer, I assume, these were used last time I flashed 40-pin AVRs with bootloader:

I can provide more details if you feel you need.

Regards, Zoltan

[szilvasyz]

In the meantime I have checked it, the bootloader in my 1284p does not match even the OptiBoot files above. Sorry, I cannot remember, which bootloader was programmed into the chip and where that came from.

[MCUdude]

I just compared the flash content you provided with the ATmega1284/P bootloaders, and it appears that is a 1 MHz 9600 baud bootloader you have installed, but the size is significantly smaller than the size of Optiboot flash, which means that it ran a different version of Optiboot than what MightyCore did bundle previously.

MightyCore is meant to be used with the bootloaders bundled with MightyCore. If your board happened to use a different bootloader, that was probably fine when MightyCore used -c arduino. But now that it uses -c urclock things are different, and you'll either have to flash the older Optiboot bootloaders MightyCore used to provide, or use Urboot.

[szilvasyz]

Hi MCUdude,

Many thanks for inspecting the bootloader. Maybe it was a blind alarm, since I cannot remember, where my bootloader is from but seemingly not from your repository. I asked my friend with whom that project was made where this board was used whether he knows, where the bootloader we installed is from - I am still waiting for the answer if he remembers anything on that. The board uses standard 16MHz XTAL clock, I would surprised if a 1MHz/9600bps bootloader could be that. Until the latest update to MightyCore 3.0 we could use our chips with Arduino IDE with the default upload (arrow icon). We use mainly mega1284 and mega644, in downsizing tests mega324 and even mega32 were successfully run with our code (of course conditional snippets in the code especially for mega32) in the same board. I have 1284s at myself for playing with new ideas, my friend uses 644s and he also run into the uploading issue after recent update to MightyCore 3.0. His bootloader is obviously from the same series than it was in my 1284.

Otherwise, I can confirm, that the actual downloadable OptiBoot and UrBoot bootloaders are working well with Arduino IDE using the default upload. I reflashed my old chip and prepared the newly arrived 1284s and 644s with UrBoot, too.

Thank you for guidance. Regards, Zoltan

[MCUdude]

The PlatformIO AVR package, and the MightyCore platformio.ini template have been updated to both support urboot and optiboot. If you're using PlatformIO, you can select the bootloader you want to run with.