Adopt avrdude 7.2 release

[mcuee]

It would be good to adopt avrdude 7.1 release.

Reference: MegaCoreX has adopted avrdude 7.1 release.
https://github.com/MCUdude/MegaCoreX

[SpenceKonde]

Where can I get or point board manager to to get the binaries? Is it expected that changes to the core platform definition are required or should it work without modification?

[mcuee]

Binary release from Arduino avrdude-packing project.
https://github.com/arduino/avrdude-packing/releases/tag/7.1-arduino.1

[mcuee]

As for platform defintions, minor changes will be required, for example, Curiosity Nano programmer is now called pkobn_updi.
Ref: https://github.com/MCUdude/MegaCoreX/blob/master/megaavr/programmers.txt

Reference: MCUdude/MegaCoreX@be87c76#diff-4f98f14cf12c5bc1ea8d0ccb8b42f777537bcb1ccbb7b16efeed9a083efc5cf3

@MCUdude may be able to give more details if you run into questions.

[SpenceKonde]

Huh is there a reason that the old erase recipe is being used? For ages everyhing has seemed to skip that, and just do the whole bootloading process with one command.

I also (in order for this to not be considered a functional downgrade) need to be able to set fuses during all UPDI uploads (DxCore and megaTinyCore set all fuses upon every upload. Before I started doing that, on MTC close to half of issues/inquiries were from people who hadn't "burned bootloader" and switched from a 16-MHz derived speed to 20 MHz derived speed, or the other way around. And they would argue when I told them to "burn bootloader" ("I don't want to use a bootloader, I am programming via UPDI", and so on - since we can't rename the burn bootloader option so it accurately describes what it does). That he separated those into two steps makes me worry that there might be some issue with that. Can you confirm that it's expected that, in a single action, doing a chip erase then writing the fuses and the flash (which is what I do now on all updi uploads) should work on 7.1? If not I don't see how I could do this without significantly degrading the user experience.

[MCUdude]

Huh is there a reason that the old erase recipe is being used?

"Regular" uploads with a UPDI programmer also set the fuses, and it has been like this for years. I think the "old erase recipe" you're referring to is when the user hits "Burn bootloader". Here, I agree that the additional erase command isn't necessary, and can be combined with the tools.avrdude.bootloader command.

I also (in order for this to not be considered a functional downgrade) need to be able to set fuses during all UPDI uploads (DxCore and megaTinyCore set all fuses upon every upload.

This still works with Avrdude 7.1, and MegaCoreX has been doing this for years:

tools.avrdude.program.params.verbose=-v
tools.avrdude.program.params.quiet=-q -q
tools.avrdude.program.verify=
tools.avrdude.program.params.noverify=-V
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} {program.verify} -p{build.mcu} -c{protocol} {program.extra_params} -Ufuses:w:{bootloader.WDTCFG},{bootloader.BODCFG},{bootloader.OSCCFG},0xff,{bootloader.TCD0CFG},{bootloader.SYSCFG0},{bootloader.SYSCFG1},{bootloader.APPEND},{bootloader.BOOTEND}:m -Ulock:w:{bootloader.LOCKBIT}:m "-Uflash:w:{build.path}/{build.project_name}.with_bootloader.hex:i"

https://github.com/MCUdude/MegaCoreX/blob/c7298cdaad039ca31b2a94848809ab7009167476/megaavr/platform.txt#L136-L141

Avrdude 7.1 is a great tool with tons of improvements, new features, and bug fixes compared to 6.3. The only "regression" I'm aware of is the removal of "safemode", which was really only needed on the older parallel port based programmers anyways.

You should especially give Avrdude terminal mode a try (-t). You can have full byte access to every memory that can be written to (flash, eeprom, usersig, userrow etc.), and the new and improved syntax lets you write pretty much any kind of data you want. It's a really nice tool for inspecting memories, and the SerialUPDI programmer is also supported.

$ ./avrdude -cusbasp -pattiny13 -t

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13)

avrdude> write eeprom 0 0x55 0xaa "Hello World!" 3.141592 0xdeadbeef -1337 'A' 'V' 'R'

Caching | ################################################## | 100% 0.01 s 

avrdude> flush
avrdude: synching cache to device ... 
Writing | ################################################## | 100% 0.31 s 
avrdude> read eeprom

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

0000  55 aa 48 65 6c 6c 6f 20  57 6f 72 6c 64 21 00 d8  |U.Hello World!..|
0010  0f 49 40 ef be ad de c7  fa 41 56 52 ff ff ff ff  |[email protected]....|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> quit

avrdude done.  Thank you.

You can also pipe data straight into memory, either through terminal mode (-t) or -U

$ echo "write eeprom 0 \"Hello World\" 0xcafe" | ./avrdude -cusbasp -pattiny13 -t

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13)
avrdude> 
Caching | ################################################## | 100% 0.01 s 

avrdude> avrdude: synching cache to device ... 
Writing | ################################################## | 100% 0.17 s 

avrdude done.  Thank you.


$ echo "read eeprom 0 ..." | ./avrdude -cusbasp -pattiny13 -t

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13)
avrdude> 
Reading | ################################################## | 100% 0.03 s 

0000  48 65 6c 6c 6f 20 57 6f  72 6c 64 00 fe ca ff ff  |Hello World.....|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> 
avrdude done.  Thank you.


$ echo "\"The quick brown fox\" 0xdeadbeef" | ./avrdude -cusbasp -pattiny13 -Ueeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13)
avrdude: reading input file <stdin> for eeprom
         with 33 bytes in 1 section within [0, 0x20]
         using 9 pages and 3 pad bytes
avrdude: writing 33 bytes eeprom ...

Writing | ################################################## | 100% 0.38 s 

avrdude: 33 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>

Reading | ################################################## | 100% 0.01 s 

avrdude: 33 bytes of eeprom verified

avrdude done.  Thank you.


$ ./avrdude -cusbasp -pattiny13 -Ueeprom:r:-:I

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9007 (probably t13)
avrdude: reading eeprom memory ...

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

avrdude: writing output file <stdout>
:200000002254686520717569636B2062726F776E20666F78222030786465616462656566A1 // 00000> "The_quick_brown_fox"_0xdeadbeef
:200020000AFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD5 // 00020> ................................
:00000001FF

avrdude done.  Thank you.

Oh. And Avrdude 7.1 supports the Urboot bootloader, which is truly a game changer. It is so good that I'll recommend users to use the virtual bootloader option because the bootloader and Avrdude protect the bootloader and the patched reset vector, so it's pretty much impossible to "brick" an AVR running Urboot. It also has autobaud, EEPROM read/write, terminal mode with read/write access to flash and eeprom, and metadata (name of the file uploaded to flash, upload date, bootloader specs etc.). It's really cool, and I'll replace Optiboot in all my cores and instead bundle Urboot. Heck, I'll even provide a bootloader for MicroCore!

I know Stefan, the author of the Urboot bootloader and the Avrdude side of things, is planning to add support for "modern" AVRs later.

[SpenceKonde]

Well Urboot sounds like an exciting thing if I could get it ported to the classic tinyAVRs. I'm not sure what advantage it would have on modern AVRs though - the Dx-series is alreadyt at the smallest permitted bootloader size. What would the advantage be of urboot over optiboot except in cases where there is no hardware bootloader support? I certainly see the reason that I need it on ATTinyCore for the classic tinies, because those are all virtual boot and can brick themselves.

[MCUdude]

Well Urboot sounds like an exciting thing if I could get it ported to the classic tinyAVRs

you can find pre-compiled bootloaders here: https://github.com/stefanrueger/urboot.hex
Note that Stefan is still trying to figure out a way to make the file and folder names humanly readable, while still making it possible for scripts to easily pick the correct bootloader binary based on some user scripts. Discussion here:
stefanrueger/urboot#19.

If you contact him, he may create and host the exact bootloader binaries you'd need for ATTinyCore.He's already doing it for my cores.

You should definitely give it a try, and read the docs (and/or use the -xhelp flag in Avrdude) to fully understand what the bootloader (along with Avrdude) can and can't do. BTW Stefan is also one of the maintainers of Avrdude now, so no wonder why there are so many new features in the recent Avrdude release! (And if you haven't already realized it, Stefan is really, really, really good at writing code)

I'm not sure what advantage it would have on modern AVRs though - the Dx-series is already at the smallest permitted bootloader size.

I'm not the right person to fully answer this, but for AVR-Dx you'd get EEPROM r/w support (and userrow/usersig support I'm sure), autobaud, and chip erase functionality. I'm sure there is more to it than this. And I'm sure he'll manage to create a version for the tinyAVR-0/1/2 series that's 256 bytes or less in size, so you could use the smallest possible bootloader size. That would give the user an additional 256 bytes of flash compared to Optiboot.

[mcuee]

Well Urboot sounds like an exciting thing if I could get it ported to the classic tinyAVRs.
I certainly see the reason that I need it on ATTinyCore for the classic tinies, because those are all virtual boot and can brick themselves.

As @MCUdude mentioned, they are available now.

Even ATtiny13A got urboot now.

• Urboot for ATTiny13/A stefanrueger/urboot#19

I have created the following two issues for ATTinyCore.

• To adopt avrdude 7.2 ATTinyCore#749
• To adopt urboot ATTinyCore#750

[SpenceKonde]

If it wasn't clear, the latest version of AVRdude, likely 7.2, will be released as part of the 2.7.0 release. It will have first been tested in 1.6.0 of DxCore.

[mcuee]

Arduino avrdude-packing project has released their version of Arduino 7.2, which should be suitable for the usage here.
https://github.com/arduino/avrdude-packing/releases/tag/7.2-arduino.1

[mcuee]

avrdude 7.3 has been released.
https://github.com/avrdudes/avrdude/releases/tag/v7.3