Optiboot EEPROM support cannot be detected by avrdude

[mcuee]

Strange that I am seeing issues with EEPROM write for the bigboot optiboot for the ATmega328P with -c urclock. -c arduino is okay.

This is with a new Nano clone with ATmega328P and FT232RL. Strange. I did test bigboot before on other boards.

• Provide Urclock programmer #1171 (comment)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM15 -p m328p  -qq -xbootsize=1024 -xshowall
0 2022-06-10 21.21 Blink.ino.standard.hex 924 store 30786 meta 34 boot 1024 o8.3 -?s-?-r-- vector 0 (RESET) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c arduino -P COM15 -p m328p  -qqt
avrdude> dump eeprom 0 0x10
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |

avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM15 -p m328p  -qqt -xbootsize=1024
avrdude> dump eeprom 0 0x10
avrdude error: bootloader does not seem to have paged EEPROM read capability
avrdude error: bootloader does not seem to have EEPROM access capability
avrdude error: unable to read eeprom page at addr 0x0000
avrdude error: (dump) error reading eeprom address 0x00000 of part ATmega328P
               read operation not supported on memory type eeprom
avrdude>
avrdude>

[mcuee]

I can reproduce the issue with a new Uno CH340 Clone.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -P COM5 -p m328p -U .\hex\bigboot_328.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file .\hex\bigboot_328.hex for flash
         with 709 bytes in 2 sections within [0x7c00, 0x7fff]
         using 7 pages and 187 pad bytes
avrdude: writing 709 bytes flash ...

Writing | ################################################## | 100% 0.07 s

avrdude: 709 bytes of flash written
avrdude: verifying flash memory against .\hex\bigboot_328.hex

Reading | ################################################## | 100% 0.02 s

avrdude: 709 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM5 -p m328p  -xbootsize=1024 -xshowall

avrdude: AVR device initialized and ready to accept instructions
0 0000-00-00 00.00  application 0 store 0 meta 0 boot 1024 o8.3 -?s-?-r-- vector 0 (RESET) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c arduino -P COM5 -p m328p  -qqt
avrdude> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m328p  -qqt -xbootsize=1024
avrdude> dump eeprom 0 0x10
avrdude error: bootloader does not seem to have paged EEPROM read capability
avrdude error: bootloader does not seem to have EEPROM access capability
avrdude error: unable to read eeprom page at addr 0x0000
avrdude error: (dump) error reading eeprom address 0x00000 of part ATmega328P
               read operation not supported on memory type eeprom
avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -P COM5 -p m328p -qqt
avrdude> dump lfuse
0000  ff                                                |.               |

avrdude> dump hfuse
0000  da                                                |.               |

avrdude> dump efuse
0000  fd                                                |.               |

avrdude> quit
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> cat .\hex\bigboot_328.hex
:107C000001C0F6C0112484B7882361F0982F9A70C0
:107C1000923041F081FF02C097EF94BF282E80E0A0
:107C2000D2D0EEC185E08093810082E08093C000D5
:107C300088E18093C10086E08093C20080E1809358
:107C4000C4008EE0C0D0259A86E020E33CEF91E0AE
:107C5000309385002093840096BBB09BFECF1D9A85
:107C6000A8954091C00047FD02C0815089F7EE24DD
:107C7000E39435E0D32E41E1C42E99D0813451F400
:107C800096D0182FA6D0113811F083E001C088E0FB
:107C900087D083C0823411F484E103C0853419F4A1
:107CA00085E09FD07AC0853539F481D0C82F7FD048
:107CB000D82FCC0FDD1F70C0863521F484E091D021
:107CC00080E0E6CF843609F03DC071D070D0182F27
:107CD0006ED0082FA12CBB24B39469D0F5018193F9
:107CE0005F011E13FACF75D0053481F44E01A12C2B
:107CF000BB24B3941A1509F450C0F50161915F01DA
:107D0000C4018ED0FFEF8F1A9F0AF4CF83E0FE01EB
:107D100087BFE89507B600FCFDCFA0E0B1E0FE010B
:107D20008D919D910C01E7BEE895112432961A13AE
:107D3000F7CFFE01D7BEE89507B600FCFDCFC7BE62
:107D4000E8952BC08437D9F432D031D0F82E2FD01B
:107D5000B82E3FD08E01F5E4BF1209C0C80158D03B
:107D60001FD0FA940F5F1F4FF110F8CF16C0F80123
:107D700085918F0115D0FA94F110F9CF0EC0853797
:107D800039F427D08EE10CD085E90AD08FE080CF7E
:107D9000813511F488E017D01CD080E101D06DCF7F
:107DA0009091C00095FFFCCF8093C600089580910C
:107DB000C00087FFFCCF8091C00084FD01C0A89562
:107DC0008091C6000895E0E6F0E098E1908380831A
:107DD0000895EDDF803219F088E0F5DFFFCF84E110
:107DE000DFCFCF93C82FE3DFC150E9F7CF91F1CFB9
:107DF000FC010A0167BFE895112407B600FCFDCF1E
:107E0000667029F0452B19F481E187BFE895089544
:107E1000F999FECF92BD81BDF89A992780B5089552
:107E2000262FF999FECF1FBA92BD81BD20BD0FB696
:107E3000F894FA9AF99A0FBE01960895FF56657262
:107E400073696F6E3D382E33004465766963653D16
:107E500061746D6567613332387000465F43505519
:107E60003D31363030303030304C00424947424F9F
:107E70004F543D31004275696C743A4D6172202057
:107E80003720323032323A31383A34363A323800EA
:107E9000554152543D3000424155445F5241544592
:107EA0003D313135323030004C45443D4235004C97
:107EB00045445F53544152545F464C4153484553E7
:037EC0003D33004F
:027FFE00030876
:0400000300007C007D
:00000001FF

[mcuee]

Here is another bigboot hex file and I can reproduce the issue as well.

PS C:\work\avr\avrdude_test\avrdude_bin> cat .\hex\optiboot_atmega328_big.hex
:107C000002C003C116C1112484B7882361F0982FE4
:107C10009A70923041F081FF02C097EF94BF282EF6
:107C200080E0DED0EDC185E08093810082E080932A
:107C3000C00088E18093C10086E08093C20080E1AB
:107C40008093C4008EE0CCD0259A86E020E33CEF00
:107C500091E0309385002093840096BBB09BFECFCB
:107C60001D9AA8954091C00047FD02C0815089F738
:107C700023E0D22ECC24C39435E0B32E41E1A42ED0
:107C8000A3D0813479F4A0D0182FB0D0123811F4D9
:107C900080E004C088E0113809F083E08ED080E1F4
:107CA0008CD0EECF823419F484E1A8D0F8CF85349B
:107CB00011F485E0FACF853541F486D0C82F84D001
:107CC000D82FCC0FDD1F92D0EACF863519F484E08F
:107CD00095D0DECF843609F045C076D075D0182F08
:107CE00073D0082F812C9924939474018FEFE81A94
:107CF000F80A6AD0F401808347011E11F6CF76D0CE
:107D0000053491F4E12EF12C10E000E0F801F39538
:107D10000E151F0509F4C3CF6081C8018C0F9D1F8C
:107D2000D9D00F5F1F4FF2CFFE01D7BEE89507B63F
:107D300000FCFDCFFE01A0E0B1E0CD0102962D9147
:107D40003C910901C7BEE89511243296DC01181355
:107D5000F4CFFE01B7BEE89507B600FCFDCFA7BE85
:107D6000E8959DCF8437D1F42FD02ED0182F2CD06A
:107D7000082F3CD07E01053451F4C701A3D01DD09B
:107D80001150FFEFEF1AFF0A1111F7CF88CFF7015B
:107D900085917F0112D01150D1F781CF853739F409
:107DA00025D08EE10AD085E908D08FE077CF8135E4
:107DB00009F089CF88E014D086CF9091C00095FF5C
:107DC000FCCF8093C60008958091C00087FFFCCF50
:107DD0008091C00084FD01C0A8958091C6000895DF
:107DE000E0E6F0E098E1908380830895EDDF803253
:107DF00019F088E0F5DFFFCF84E1DFCFCF93C82F04
:107E0000E3DFC150E9F7CF91F1CFFC010A0167BF71
:107E1000E895112407B600FCFDCF667029F0452BCC
:107E200019F481E187BFE8950895CB01642FA9017A
:107E3000ECCF8F929F92AF92BF92CF92DF92EF9250
:107E40000F931F93CF93DF93EB016901912C812C4A
:107E50008016910629F4EE2049F188E0C1DFFFCFBA
:107E600050E040E063E0CE01D0DFB12CA12CF50161
:107E7000EC0DFD1D4591549161E0C5018C0F9D1FD6
:107E8000C4DF82E0A80EB11C80E8A816B10479F71F
:107E900050E040E065E0CE01B8DF8FEF881A980A25
:107EA000C058DF4F80E8C80ED11CD2CFDF91CF91F0
:107EB0001F910F91EF90DF90CF90BF90AF909F9068
:107EC0008F900895F999FECF92BD81BDF89A9927B8
:107ED00080B50895262FF999FECF1FBA92BD81BDB6
:107EE00020BD0FB6F894FA9AF99A0FBE019608953C
:027FFE00000879
:0400000300007C007D
:00000001FF
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -P COM5 -p m328p -U .\hex\optiboot_atmega328_big.hex

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file .\hex\optiboot_atmega328_big.hex for flash
         with 754 bytes in 2 sections within [0x7c00, 0x7fff]
         using 7 pages and 142 pad bytes
avrdude: writing 754 bytes flash ...

Writing | ################################################## | 100% 0.06 s

avrdude: 754 bytes of flash written
avrdude: verifying flash memory against .\hex\optiboot_atmega328_big.hex

Reading | ################################################## | 100% 0.02 s

avrdude: 754 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m328p  -qqt -xbootsize=1024
avrdude> dump eeprom 0 0x10
avrdude error: bootloader does not seem to have paged EEPROM read capability
avrdude error: bootloader does not seem to have EEPROM access capability
avrdude error: unable to read eeprom page at addr 0x0000
avrdude error: (dump) error reading eeprom address 0x00000 of part ATmega328P
               read operation not supported on memory type eeprom
avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c arduino -P COM5 -p m328p  -qqt
avrdude> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

[mcuee]

@stefanrueger
Please take a look and see if you can confirm the issue as well.

[mcuee]

@stefanrueger

I happend to keep the different exe files from PR #1171.
Ineed the initial version of urclock support is still working.

• Provide Urclock programmer #1171 (comment)

I checked the commit history of PR #1171.
https://github.com/avrdudes/avrdude/pull/1171/commits
This is at commmit cf3c81f

PS C:\work\avr\avrdude_test\avrdude_bin\old_bin> echo "dump eeprom 0 0x10" | .\avrdude_pr1171
 -C avrdude_pr1171.conf -c urclock -P COM5 -p m328p  -qqt
avrdude_pr1171 warning: guessing it is optiboot 8.0 with size 512 (better use -xbootsize=<num>)
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

But apprently later version does not work and I did not test the bigboot EEPROM after the initial testing.

This is at commit 20b86fb

PS C:\work\avr\avrdude_test\avrdude_bin\old_bin> echo "dump eeprom 0 0x10" | .\avrdude_pr1171v1 -C avrdude_pr1171v1.conf -c urclock -P COM5 -p m328p  -qqt
avrdude_pr1171v1 warning: guessing it is optiboot 8.0 with size 512 (better use -xbootsize=<num>)
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
avrdude_pr1171v1 error: bootloader does not seem to have EEPROM r/w capability
avrdude_pr1171v1 error: bootloader does not seem to have EEPROM r/w capability
avrdude_pr1171v1 error: unable to read eeprom page at addr 0x0000
avrdude_pr1171v1 error: (dump) error reading eeprom address 0x00000 of part ATmega328P
                        read operation not supported on memory type eeprom
avrdude>
avrdude>

[mcuee]

Same problem for ATmega2560 Optiboot hex file from @MCUdude's MegaCore.
https://github.com/MCUdude/optiboot_flash/blob/master/bootloaders/atmega2560/atmega2560_build_info.txt

And it is the same if I look into the commit history of PR #1171.

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m2560 -qqt -xbootsize=512
avrdude> dump eeprom 0 0x10
avrdude error: bootloader does not seem to have paged EEPROM read capability
avrdude error: bootloader does not seem to have EEPROM access capability
avrdude error: unable to read eeprom page at addr 0x0000
avrdude error: (dump) error reading eeprom address 0x00000 of part ATmega2560
               read operation not supported on memory type eeprom
avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c arduino -P COM5 -p m2560 -qqt
avrdude> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

[mcuee]

BTW, no issues with urboot EEPROM support.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM5 -p m2560 -qqt -xshowall
0000ffffffff 0000-00-00 00.00  application 0 store 0 meta 0 boot 1024 u7.7 weu-hprac vector 0 (RESET) ATmega2560
PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m2560 -qqt
avrdude> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

[mcuee]

Okay, this may not be a real problem. It seems to me that need to add -xeepromrw in the option in this case.

PS C:\work\avr\avrdude_test\avrdude_bin> echo "write eeprom 0 0xaa 0x55" | .\avrdude -c urclock -P COM5 -p m328p -qqt -xbootsize=1024 -xeepromrw
avrdude> write eeprom 0 0xaa 0x55
avrdude>
avrdude>
PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m328p -qqt -xbootsize=1024 -xeepromrw
avrdude> dump eeprom 0 0x10
0000  aa 55 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |.U..............|
avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "write eeprom 0 0x55 0xaa" | .\avrdude -c urclock -P COM5 -p m2560 -qqt -xbootsize=1024 -xeepromrw
avrdude> write eeprom 0 0x55 0xaa
avrdude>
avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c urclock -P COM5 -p m2560 -qqt -xbootsize=1024 -xeepromrw
avrdude> dump eeprom 0 0x10
0000  55 aa ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |U...............|

avrdude>
avrdude>

[mcuee]

@stefanrueger

Do you think it is possible to detect the EEPROM R/W capability of optiboot hex file?

• Provide Urclock programmer #1171 (comment)

In order to better support the existing optiboot bootloaders from, say, version 4.1 that are out there on millions of chips

• How can AVRDUDE tell how many pages the optiboot binary occupies?
• How can AVRDUDE tell whether the optiboot binary can read/write EEPROM?
• How can AVRDUDE tell whether the optiboot binary is a vector bootloader or not? If so, which vector was used?

(as background, AVRDUDE can read all flash locations of the connected MCU. Currently it detects the presence of optiboot by the last byte in flash being between 4 and 55; the major version number that optiboot puts there; urboot uses that byte to pack both major and minor version number in there so that this byte is between 56 and 254).

@WestfW has not answered the question so maybe it is not possible.

In this case, maybe the best thing we can do now is to change the warning message to something like the following.

avrdude error: bootloader does not seem to have paged EEPROM read capability, 
               please specify `-xeepromrw` if the bootloader has EEPROM read/write capability
avrdude error: bootloader does not seem to have paged EEPROM write capability, 
               please specify `-xeepromrw` if the bootloader has EEPROM read/write capability
avrdude error: bootloader does not seem to have EEPROM access capability
               please specify `-xeepromrw` if the bootloader has EEPROM read/write capability

Affected lines:
https://github.com/avrdudes/avrdude/blob/main/src/urclock.c#L2316
https://github.com/avrdudes/avrdude/blob/main/src/urclock.c#L2281
https://github.com/avrdudes/avrdude/blob/main/src/urclock.c#L1783

[stefanrueger]

Thanks, @mcuee. Yes, -c urclock cannot augur eeprom support from unknown bootloaders. The user has to specify eeprom capability explicitly. (Urboot bootloaders tell AVRDUDE, so they don't have a problem.) I have pushed a PR that issues error messages hinting at the -xeepromrw option.

Are the bootloaders you used common bootloaders (eg, distributed with commonly sold hardware)? If so, we might include their hash into our little table that caters for known bootloaders:

    { 1024, 1, 0x6ca0f37b, 0x21124cde }, // bigboot_328p_8v3_uno_ch340_clone.hex
    { 1024, 1, 0xae42ebb8, 0xeb4b1b71 }, // bigboot_328p_8v0.hex 

Pro tip: When you have more such bootloaders that are often used, why not run the botloader-hash tool to create more table entries, and we push that onto the PR #1226

[mcuee]

@stefanrueger

I think PR#1226 is good to go.

PS C:\work\avr\avrdude_test\avrdude_bin> echo "write eeprom 0 0xaa 0x55" | .\avrdude_pr1226
 -c urclock -P COM5 -p m328p -qqt -xbootsize=1024
avrdude> write eeprom 0 0xaa 0x55
avrdude_pr1226 error: bootloader might not have paged EEPROM read; try -xeepromrw if it has
avrdude_pr1226 error: bootloader might not have EEPROM access; try -xeepromrw if it has
avrdude_pr1226 error: unable to read eeprom page at addr 0x0000
avrdude_pr1226 error: (write) error writing 0xaa at 0x00000, rc=-1
                       write operation not supported on memory type eeprom
avrdude_pr1226 error: bootloader might not have paged EEPROM read; try -xeepromrw if it has
avrdude_pr1226 error: bootloader might not have EEPROM access; try -xeepromrw if it has
avrdude_pr1226 error: unable to read eeprom page at addr 0x0001
avrdude_pr1226 error: (write) error writing 0x55 at 0x00001, rc=-1
                       write operation not supported on memory type eeprom
avrdude>
avrdude>

[mcuee]

Are the bootloaders you used common bootloaders (eg, distributed with commonly sold hardware)?
Pro tip: When you have more such bootloaders that are often used, why not run the botloader-hash tool to create more table entries, and we push that onto the PR #1226

I think these bootloaders are not distributed with commonly sold hardware. Therefore maybe it is not really necessary to include them in avrdude. I am more familiar with Microchip official tools and cheap boards from AliExpress/Taobao. Microchip does not seem to ship any official boards with Optiboot.

Then the commonly available Uno/Nano clones are usually shipped with Arduino original bootloader without EEPROM support, or even non-working bootloaders in the case of Nano clones (ATmega328P or ATmega168P, many with 16MHz crystal and not 8MHz). The Mega2560 clones are usually shipped with the Wiring (stk500v2) bootloader.

For my testing of Uno/Nano clones I tend to use @MCUdude's MiniCore optiboot bootloader which by default does not support EEPROM for the ATmega328P/ATmega168P. Then I will test with bigboot firmware as well since it supports EEPROM. One of the hex file is from @WestfW but I forgot where I got the second one.

As for Mega2560 clones, I will usually use @MCUdude's MegaCore optiboot bootloader which by default does support EEPROM for ATmega2560.

Then I've seen a few boards from AliExpress/Taobao (by a company called Muzi Technology) which uses @MCUdude's MightyCore for the ATmega32A/64A/128A. I got one such board using ATmega32A and it also does not support EEPROM by default. The board is dead now though.

Then there are quite some ATtiny13/85/88/167based boards, they do not usually come with optiboot FW. Quite some of them (especially ATtiny88 based Nano style board) come with micronucleus bootloaders.

As for the Leonardo/Micro clones with ATmega32U4, they usually ship with AVR109 based USB bootloader (caterina).

There is also one company selling xMega based boards and they do not come with optiboot bootloader either.

There are very few UPDI boards available from AliExpress/Taobao except Nano Every 4808 clone (with ATmega4808). They do not come with any bootloader either. @MCUdude does not support optiboot_x for this board even though he provided me optiboot_x compatible bootloader for testing.

Ref: programmers and boards I have for avrdude testing.
#1021 (comment)

[mcuee]

@MCUdude

I know you are selling some boards which will ship with optiboot bootloader, do you want to include the bootloaders in avrdude by running the botloader-hash tool to create more table entries to be included in avrdude? Thanks.

[mcuee]

@stefanrueger and @MCUdude

I am not so sure about the vast amount of bootloaders in optiboot_flash.
https://github.com/MCUdude/optiboot_flash/tree/master/bootloaders

It is probably too many. But is it possible to include a few specific ones?

1. 16MHz and 8MHz for ATmega328P/ATmega168P, 115200bps
2. 16MHz and 8MHz for ATmega2560, 115200bps
3. 16MHz and 8MHz for ATmega8/16/32/64/128

[mcuee]

@stefanrueger and @MCUdude
I also think we can include the bootloaders from MegaCoreX.
https://github.com/MCUdude/MegaCoreX/tree/master/megaavr/bootloaders/optiboot/bootloaders/mega0/115200

[mcuee]

@stefanrueger and @MCUdude

For Dr Azzy's following bootloaders, I am not so sure.

The following optiboot_x bootloader may be worth adding, similar to MegaCoreX.
https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/bootloaders/hex

The following two (ATTinyCore and DxCore) are probbaly too many to be included.
https://github.com/SpenceKonde/ATTinyCore/tree/v2.0.0-devThis-is-the-head-submit-PRs-against-this/avr/bootloaders/optiboot/hex
https://github.com/SpenceKonde/DxCore/tree/master/megaavr/bootloaders/hex

[stefanrueger]

I suggest only including bootloaders that are commonly used. The hash table in urclock.c only deals with classic-part bootloaders in top flash. It cannot deal with bootloaders in low flash. That's past v7.1 when -c urclock expands support for UPDI parts.

[mcuee]

I suggest only including bootloaders that are commonly used. The hash table in urclock.c only deals with classic-part bootloaders in top flash. It cannot deal with bootloaders in low flash. That's past v7.1 when -c urclock expands support for UPDI parts.

I see. In that case, I think the current list is already good enough from my side. I do not think picoboot is commonly used but since we have already included so we can keep it. It is good for testing as well.
https://github.com/avrdudes/avrdude/blob/main/src/urclock.c#L1146

Let's see if there are some hex files @MCUdude would like to include.

[mcuee]

@stefanrueger

BTW, I believe that -xbootsize and -xshowall uses BYTE as the unit, right?

Just tested a new Nano Clone with ATmega328P (5V, 16MHz).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1226 -c urclock -P COM10 -p m328p -qq -xshowall
0 0000-00-00 00.00  application 0 store 0 meta 0 boot 512 o4.4 --s-h-r-- vector 0 (RESET) ATmega328P

For AVR fuse settings, WORD is used as the unit.

[MCUdude]

Well, by hardcoding in hashes, this means that I can never re-compile the bootloaders again since the hash would then be different. I understand it makes sense for official boards that haven't changed their in more than 10 years, but I tend to re-compile whenever a bug is discovered or a new feature gets crammed in there.

[mcuee]

Well, by hardcoding in hashes, this means that I can never re-compile the bootloaders again since the hash would then be different. I understand it makes sense for official boards that haven't changed their in more than 10 years, but I tend to re-compile whenever a bug is discovered or a new feature gets crammed in there.

This makes sense. In that case, we can keep status quo.

[stefanrueger]

| For AVR fuse settings, WORD is used as the unit.

@mcuee Yes, all sizes are in bytes. Yes, I realise Atmel has this odd and confusing mixture of using bytes (es, to say how big flash, eeprom etc is) and words in their tables for fuse settings. That's a generic and self-inflicted Atmel pitfall. I am not aware that AVRDUDE routinely reports sizes in words, in fact I struggle to find a single example. We should not start confusing AVRDUDE users in the same way as Atmel/Microchip sometimes does.

[stefanrueger]

| by hardcoding in hashes, this means that I can never re-compile the bootloaders again

It's wrong to compile optiboot bootloaders! Compile urboot bootloaders. 😄

Seriously, switch. Urboot is shorter and more powerful (can do EEPROM and chip erase and protext itself from overwriting in the same size as optiboot that does neither).

Just to put this into perspective: -c urclock is for urboot bootloaders; it protects the bootloader and cooperates with it on a wide range of desirable properties, eg, emulating chip erase by uploading 0xffs etc. If you want to have the same benefit for your optiboot bootloaders then -c urclock needs to know the bootloader size and capabilities. I have put these properties in a small, elegant hash table for a handful of bootloaders that I came across, the most important of which is the optiboot v4.4 that has been distributed with arduino for donkey's years and will sit on many millions of chips. Anyone using these will benefit from the hash table.

So to cut a long short: Feel free to put existing and widely-distributed bootloader hashes into the urclock.c code.

[WestfW]

Compile urboot bootloaders. 😄
Seriously, switch.

Have you talked the Arduino folk into switching, yet? Or just including the avrdude with urboot support in their tools distribution?

In the ~10years since version 4.4 of Optiboot, Arduino has not updated the version of the bootloader that they ship with Unos. :-(
Now, admittedly, most of the changes have been unimportant for the Arduino Products. I added new chips, new Makefile features, adjusted for new compiler versions... None of it necessary
But urboot isn't necessary, either.

[stefanrueger]

Sure, it may well be that arduino folks see no need for a better bootloader than optiboot v4.4. And that's fair enough. That and the fact that there are so many chips with optiboot out there made me put some effort into making -c urclock backwards compatible, so it can cope with optiboot characteristics

• So avrdude -c urclock doesn't overwrite the bootloader (as optiboot doesn't protect itself)
• So avrdude -c urclock doesn't deliver flash as EEPROM (as optiboot mistakenly does)
• So avrdude -c urclock erases the flash (which optiboot doesn't)

Whether or not the arduino folks want any of that is their prerogative

[mcuee]

Have you talked the Arduino folk into switching, yet? Or just including the avrdude with urboot support in their tools distribution?

In the ~10years since version 4.4 of Optiboot, Arduino has not updated the version of the bootloader that they ship with Unos. :-( Now, admittedly, most of the changes have been unimportant for the Arduino Products. I added new chips, new Makefile features, adjusted for new compiler versions... None of it necessary But urboot isn't necessary, either.

@WestfW

I do not think Arduino has any motivation to upgrade their bootloaders (and often the same for built-in FW as well).

Just an example, the following is a confirmed bug for the wiring (STK500V2) bootloader for the Mega2560 and there is a pull-request (dated June 2018) to fix it. They have not adopted

• Fix stk500v2 READ_EEPROM to properly read EEPROM arduino/ArduinoCore-avr#24

The bootloader file they are shipping is more than 10 years ago.
https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/stk500v2

Same for this FW issue I reported.

• Arduino Uno or Mega2560 ATmega16U2 DFU FW issue arduino/ArduinoCore-avr#490

Right now I actually use @MCUdude's MiniCore and MegaCore for the Uno and Mega2560 Clones. @MCUdude has adopted the fix for the Mega2560 wiring bootloader once I informed him the fix.

[mcuee]

@WestfW

Just wondering if you have fixed or have intentions to fix the paticular optiboot bug.

• Optiboot without EEPROM support returns flash on EEPROM request #1227 (comment)

This is a well-known optiboot bug. It returns flash for EEPROM if optiboot has been compiled to not handle EEPROM. This bug has been around for a long time (and possibly still is today but defo was 2016 when I last looked closely at optiboot).

[mcuee]

@stefanrueger

For the Arduino compatible core developers like @MCUdude, maybe there is one more questions: which flavour of urboot FW to use?

• autobaud or non-autobaud
• Which of the following option combination to go?

1. ee bootloader supports EEPROM read/write
2. fr bootloader provides non-essential code for smoother error handing
3. ce bootloader provides a chip erase command
4. vbl vector bootloader: set fuses to jump to reset, not the HW boot section

The following should be a given.
ur uses urprotocol and requires avrdude -c urclock for programming

[stefanrueger]

Which urboot? Here are some tips: https://github.com/stefanrueger/urboot/blob/main/howtoselect.md

TLDR? EEPROM support is neat, autobaud is neat (I've finally come round to it as it only costs 16 bytes). If there is space left compile for frills (fr) and/or chip erase (ce). If the part has hardware bootloader support that would occupy the same size as the vector bootloader go for hardware support otherwise compile for a vector bootloader (you don't have that choice for parts without hardware bootloader support; there it's got to be a vector bootloader). Don't compile for dual boot unless you really want programming over the air for that project and have a board with external SPI flash.

If you have a certain bootloader usage budget (ie, the size the bootloader will take away from flash): browse the README.md of the autobaud directory of a part, you will see the "best" bootloaders suggested for the bootloader usage that you can afford, eg, https://github.com/stefanrueger/urboot/blob/main/bootloaders/atmega328p/autobaud/README.md

Also notice I have similar pages for (some) popular boards, eg, https://github.com/stefanrueger/urboot/blob/main/bootloaders/board_uno/autobaud/README.md

[stefanrueger]

@WestfW BTW, I hugely admire your work; without that the urboot project with ensuing -c urclock avrdude support would never have happened. Urboot started from optiboot but like the ship of Theseus it has morphed into sth else. See
https://github.com/stefanrueger/urboot/blob/main/AUTHORS

[stefanrueger]

Well, it's a shame there is no label for "have no idea how do any better than the current workaround for a problem that originates elsewhere". My attempt to get avrdude to know whether a particlular optiboot instantiation deals with EEPROM is to look that up in a hash table of known instatiations... So, lucky us, Arduino has only ever shipped one...

[mcuee]

I agree with change the lable to wontfix. We can keep this issue open for a while and then close it.

We can even create a FAQ Wiki page to include information like this one.

[mcuee]

@WestfW

Just wondering if you have fixed or have intentions to fix the paticular optiboot bug.

• Behavior of Optiboot firmware without EEPROM capability when reading eeprom #1227 (comment)

This is a well-known optiboot bug. It returns flash for EEPROM if optiboot has been compiled to not handle EEPROM. This bug has been around for a long time (and possibly still is today but defo was 2016 when I last looked closely at optiboot).

I can confirm the issue is still there with latest optiboot git.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM4 -p m328p -xbootsize=512 -xshowall

avrdude: AVR device initialized and ready to accept instructions
0 2022-06-10 21.21 Blink.ino.standard.hex 924 store 31298 meta 34 boot 512 o8.3 -?s-?-r-- vector 0 (RESET) ATmega328P

PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c arduino -P COM4 -p m328p -qqt
avrdude> dump eeprom 0 0x10
0000  0c 94 5c 00 0c 94 6e 00  0c 94 6e 00 0c 94 6e 00  | .\. .n. .n. .n.|

avrdude>
avrdude>
PS C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude -c usbasp -p m328p -qqt
avrdude> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>
avrdude>

[mcuee]

Optiboot/optiboot#358 raised against Optiboot.