AVRDUDE 7.2 release discussion

[mcuee]

[Updated on 29-June-2023]
avrdude is close to 7.2 release with most of the PRs merged. The target is to release avrdude 7.2 version in July 2023.

[Updated on 23-May-2023]
The following two issues were removed from 7.2 milestones.

• add JTAG support to avrftdi #1324 (Enhancement, PR, under review) ---- removed on 23-May-2023 due to lack of updates from the author
• [patch #9565] Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements #734 (Enhancement, not yet being worked on) -- removed since @dl8dtl may be busy.

[Updated on 12-May-2023]
Remove #968 from 7.2 milestone as it only affects one programme (usbasp with specific FW).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Done items:

• [bug #48261] STK500V2 ISP problem with ATmega8/8515/8535, ATmega16 and ATmega32 #425 (Long standing bug, fixed)
• PICKit 2: MSVC build of avrdude Windows binary does not work #1006 (Bug, fixed by PR CMake: Remove LIB_LIBHID from configuration is favor of hard-coding it #1294)
• Change Arduino auto-reset via DTR/RTS/CTS to allow direct reset connection #1262 (Enhancement, PR, merged)
• CMake: Remove LIB_LIBHID from configuration is favor of hard-coding it #1294 (Bug fix, PR, merged)
• Add optional libgpiod support to linuxgpio #1299 (Enhancement, PR, merged)
• Add CH341A programmer support. #1215 (Enhancement, PR, merged)
• Change Arduino auto-reset via RTS to allow direct RTS-reset connection #1309 (Enhancement, PR merged)
• Provide a programmer dryrun that emulates programming #1347 (Enhancement, PR merged)
• Provide terminal config command to set fuses and lock bits #1365 (Enhancement, PR merged)

I quickly scan through the issues and the following seem to be interesting.

Windows specfic issues.

• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) -- low priority #968 (Bug, related to avrdude-libusb)
• Harmonize WIN32 implementation of serial time-outs with Posix one #1249
• To adopt PR #1264 approach of using Readline replacement for MinGW build (Low Priority) #1271

linuxgpio/linuxspi related (Done)

• linuxgpio issues #932 (Done)
• Port Linux sysfs GPIO feature to libgpiod #831 (Done)

** Nice enhancement to have **

• Remove all calls to exit(3) from libavrdude library functions #774
• Support COM port discovery via USB VID/PID #907
• Differentiate multiple USB programmers of the same VID/PID (libusb or hidapi or libftdi) #973
• Terminal mode: to support command similar to U in CLI mode #1180 (Done)
• Parts with *L, *PV and *V suffixes + others are missing in avrdude.conf #1092 (Done)

** Binary release related **

• Linux and macOS releases are missing -- static linking version preferred (Low Priority) #987
• Enhance CMake to be able to support static link for Linux and macOS #1159

[mcuee]

Some of the above are part of the issues labeld with "Help Wanted"
https://github.com/avrdudes/avrdude/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22

• Parts with *L, *PV and *V suffixes + others are missing in avrdude.conf #1092 (Done)
• Rework PICKit2 programmer to use libhidapi instead of libhid (which will make it work under macOS) #883
• Rework Users Guide #840
• Port Linux sysfs GPIO feature to libgpiod #831 (Done)
• Remove all calls to exit(3) from libavrdude library functions #774

[mcuee]

From @MCUdude
#1061 (reply in thread)

In early 2023 we should have a discussion on what we want to achieve or implement in the next release (Avrdude v8.0?). Along with this, there will also be lots of other PRs with small feature addition and bug fixes. And now that more and more people realize that the Avrdude project is now on Github, and is highly active, we should expect to see new contributions submitting issues and PRs now and then.

[dl8dtl]

I wouldn't want to decide between 8.0 vs. 7.x beforehand.
The usual decision was whether something fundamentally has been changed, that requires the user to take some action (e.g. rewrite personal .avrduderc files, different default behaviour of some options etc.). If not, I'd prefer to continue the 7.x line for a while.

[mcuee]

I see. I have changed 8.0 milestone to 7.2.

[mcuee]

Right now I have put 7 issues for 7.2 milestone (4 open and 3 closed). Please comment if I need to add more or remove some of them.
https://github.com/avrdudes/avrdude/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22AVRDUDE+7.2%22

One outstanding PR is also labled for 7.2 milestone. (4 PR closed)
https://github.com/avrdudes/avrdude/pulls?q=is%3Aopen+is%3Apr+milestone%3A%22AVRDUDE+7.2%22

[mcuee]

BTW, the above issues are just my wish, I think we can always delay the feature enhancements to next release if they are not ready (especiaally for enhancement requests without PR submitted).

[mcuee]

@dl8dtl @mariusgreuel @stefanrueger @MCUdude

Just wondering what will be our release model down the road for 7.2 and beyond.

Option 1: yearly release with potential bug fixes if there are critical bugs introduced by a new release (unlikely in the current state).
Option 2: based on milestones (but the milestone issues can be shifted if agreed).

I am more for Option 1. I am not so sure if any of you want to have a six-month release cycle or not. For example, if I look at the current git main, it seems to be okay to release it as version 7.2 as well, as it fixes quite a few important issues.

[SpenceKonde]

Well, I know I would rather like the new features of a late june 7.2 release when I am updating the versions my cores use, and that timeline is perfect for getting it into 1.6.0 of DxC, compared until waiting until christmas.

How are core maintainers expected to obtain the packages in the exact form Arduino likes? Are packages made available? If not how would we deal with the fact that we need to run on like 7-8 platforms (x64 windows, x86 linux x64 linux, x64 mac, 32 bit ARM, 64 bit ARM IIRC) - If I'd be expected to be able to achive that crosscompile magic.... those expectations are far too optimistic (I struggle with setting up build environment for the architecture I'm building on) Are we expected to rehost them somewhere on our own nickle? (not unreasonable request - it's my one condition on using my toolchains :-P)

Is there a "checklist" of any sort for updating 6.3 to 7.2? in terms of potential incompatibilities that should be checked for?

[mcuee]

@SpenceKonde
Now it is quite easy to build the binaries like what Arduino is doing.

For testing purpose, you can always try my build here, which uses the same build infrasture (docker) as the Arduino-packing project but using latest git main of avrdude. It has Linux x86/x64/ARMv6/ARM64, macOS x64 and Windows MinGW x86 binaries.
https://github.com/mcuee/avrdude-packing/actions/runs/5045430220

It has only 32bit Windows MinGW build though. But actually for Windows I will recommend the latest github MSVC action from official avrdude project to be used for Windows x86/x64/ARM64. I do not think you need to care for Windows on ARM32.
https://github.com/avrdudes/avrdude/actions/runs/5033979061

[mcuee]

@SpenceKonde

As for the change from Arduino's avrdude 6.3 version (quite different from official avrdude 6.3 version) to avrdude 7.2, I think you may take some hints from what @MCUdude for the 7.1 adoption in MegaCoreX and
MCUdude/MegaCoreX@be87c76
https://github.com/MCUdude/MicroCore/commits/master (you can look at the commit history and see how he adopts avrdude 7.1 and then urboot for MicroCore)

[SpenceKonde]

Isn't Windows on ARM32 dead? Like wasn't that Windows Phone and the poverty model Surface?
(I've still got the windows phone T-shirt - "Less Doing. More Done." - Very apt description of Windows phone, but not quite what they intended; WinPho was pretty much recognized as a total failure within months and I thought when I got that T-shirt Microsoft was still supporting Windows on IA64 (at the company I worked for, I occasionally had to test our software on that godawful platform). (It took a lot longer for the Itanic to realize she had left port with her backwards compatibility still onshore, and could only go forwards, but there was an iceberg of irrelevance dead ahead. And, for that matter, to either side - years after she first sailed. Though everyone on the outside could see that something wasn't going smoothly. )... Though that might have been dropped a short time earlier - the point I'm trying to make is, why even worry about win on ARM32? Isn't it no more relevant than IA64? Wasn't every winarm32 device a commercial failure, regardless of how much Microsoft spent promoting it, so the installed base is small, and the computers likely no longer in use due to age and the crippled OS), and didn't they stop coming out within a year of launch? Or is this some different winarm implementation they're trying to pull off now? (But today, nobody tries to run windows with just 4GB of ram, so wouldn't they be talking ARM64, which has been deployed on servers for years?)

Anyway, back on topic - So the changes I see in MegaCoreX are:

• fuse# syntax changed to fusename - one assumes that the old names will still work.
• different names for programmer types. What does pkobn stand for? Like I can't guess even one of those words
• I see a forced -v being shed - I think I also force a -v so you never look at an unchanging console output window for more than 1/100th of the write time; anything that takes longer is failing and you can kill the upload process by bouncing the hardware if you're impatient, especially if it's going to try 9 more times (ooh, the CH342 has a reset pin. Since I need to rev my boards anyway because I made a series of blunders), I should put a button on it, or at least pads for one.)
• New avrdude.conf file? Does it have all parts for which the device ID is known in it? (or at least all ATtiny and post 2016 parts, that's all I care about. I guess maybe a few people here and there still use atmega328p's? :-P

So - end of the month, 7.2 release still expected? It'd be no fun to put in the new support, and then have to revert the files because the release wasn't ready. This month's goal is working EA's and 1.7.0 DxC release, which I hope to pair with avrdude7.2

If you care for my opinion on the matter, I think the releases should be done...
a. Immediately if a super critical bugfix goes in (something like a .hex file that would execute arbitrary code when you try to upload it instead of uploading, or if the fusebit handling had a bug that destroyed hardware, that kinda thing.
b. After an orderly testing of a new Very Big Feature. I don't know the project well, so I can't comment on what would count as that, but you probably know. The kind of release where you'd want to get farmers to mow "avrdude 8.0" into their fields [this is another jab at Microsoft; they paid farmers to mow the windows logo into fields for the Win95 launch event].
c. At least annually, with option for midyear releases if you've put in a bunch of small fixes.

Though it would matter a great deal what you expect the "number of fixed bugs per time interval" and "number of enhancements per time interval graphs to look like as time passes - you started with a mountain of technical debt from avrdude having langushed like it did, but it looks like a lot of that has been sorted out. That suggests that bugs fixed would exponentially decay as there were fewer and fewer bugs to fix, possibly with jumps after major features. However, in my experience, it seems that open source projects instead tend towards constant density of new bug discoveries!

It's like they materialize out of the vacuum. Computational studies have recently supported the possibility that "hawking radiation" can occur around not just objects with an event horizon, but around any sufficiently dense object. If software bugs are in fact quantum mechanical objects (admittedly a stretch, but hey, so are most largescale physics models - string theory, LQG, LambdaCDM, and all the rest of them are varying flavors of implausible. Heck - if these software bugs could only interact with computational systems, then disenprogrammed software bugs could be dark matter! And we wouldn't detect it because we try to use the lowest background detectors we can make. If we instead put a bunch of CPUs next to eachother, depending on how fast we're moving through the interstellar medium, the rate at which new bugs appear in existing firmware will be modulated by that velocity. Plus, without further studer, we can't assume that they wouldn rotate in time with normal objects in the galaxy either, so we might imagine that we would occasionally pass through densely (buggy) patches of space and clear ones, which would explain periodic mass extinctions - maybe the reason all those species went extinct at once is because all of a sudden their computers, cellphones, and information technology infrastructure interacted with a dense cloud of software bugs, and became non-functional, leading to civilizational collapse; I know what you're going to say, dinosaurs didn't have computers, but do we know that? How do we know there are not other drastically different ways of making processors - maybe the dinosaurs had advanced beyond todays technology, and their computers were all biodegradable? Or what if we just haven't found them - I mean, there's a tablet carved hundreds of years ago clearly depicting people from Atlantis with a laptop computer \o/ but the closest we've found to a preserved ancient laptop is the Antikythera mechanism). Anyway, so if that theory is true and software bugs materialize out of the vacuum in proximity to highly dense objects; Surely you're not going to tell me you haven't interacted with some extremely dense users? Q E D!

Okay, that'll be about enough of that...

[mcuee]

Target for avrdude 7.2 release will be some time in July 2023, unless some very critical issues are found (unlikely).

BTW, there are some users of Windows on ARM64. And I agree Windows on ARM32 is dead practically speaking.

Reference Windows 10/11 on ARM64 -- some users are using it on Raspberry Pi 4 and some are using it as a VM under Apple Silicon Macs. As of now libwdi/Zadig do not work on Windows 11 ARM64. So the programmers must use either HID driver or WinUSB driver (with Windows OS descriptor) to work with avrdude.

• Windows 10 on ARM64 support pbatard/libwdi#155

[stefanrueger]

So - end of the month, 7.2 release still expected?

More like sometime July. Code freeze end of June and then however long it takes the team to test.

New avrdude.conf file?

Very much so. Try avrdude -vp\? |& more to see which parts are supported, and -c\? to see which programmers are supported.

Software bugs

Yes, some but not many (and if so, real bugs not quantum bugs ;). It's more a case of having enough new features to warrant a release; check out the terminal config command. The complexity of AVRDUDE comes primarily from a progression of chip development and programmers that necessitates a change of how AVRDUDE models either and secondly from the (quadratically) increasing number of combinations of programmers and parts.

old [fuse#] names will still work

Yes, in fact the new names are aliases to the old names.

[mcuee]

It is great now we only have a few issues labeled as bug as of 16-June-2023.
https://github.com/avrdudes/avrdude/issues?q=is%3Aopen+is%3Aissue+label%3Abug

19-June-2023: #1292 has been closed.
20-June-2023: #1097 has been closed.

• xplainedmini_dw upload not working #1292 (closed)
• PICKit 4, SNAP, Atmel ICE and Power Debugger only work with hidapi but not libusb (low priority) #1221 (low impact issue as hidapi is the default library to work with PICKit 4 and SNAP)
• Windows console history via F7 does not work in terminal mode #1097 (only for Windows MSVC build)
• avrdude MSVC build problem with USB composite device (avrdude-libusb library issue) -- low priority #968 (not exactly avrdude issue, but rather avrdude-libusb issue, only for Windows MSVC build)
• [bug #44644] Missing access to user signature rows in ATmega256RFR2 et al. #379 (PR Define usersig memory for ATmega*RF[AR]* parts #1406 available, need help from community for testing, low impact, only affect some RF AVAR chips)
• [bug #41857] avr109 atmega2564rfr2 erase timeout to short #336 (low impact, only affect bootloader for some specific RF AVR chips)

[stefanrueger]

Wow. We've come a long way since January. Only 37 issues/6 bugs. I think I can deal with #336, at least for the programmers that might be used for bootloading.

[mcuee]

@stefanrueger

Thanks a lot for the great work dealing with the bugs, including long-standing ones like #425 and #509.

• [bug #48261] STK500V2 ISP problem with ATmega8/8515/8535, ATmega16 and ATmega32 #425
• [bug #59667] STK500v2 ATtiny15 problem #509

[mcuee]

Today I got the Microchip AVR64EA48 Curiosity Nano from Mouser SIngapore and avrdude git main seems to work fine.

Example hex file used: I can see the data sending from the UART.
https://github.com/microchip-pic-avr-examples/avr64ea48-digital-filters-studio/releases/tag/1.0.0

The factory hex file will turn on the LED. Afer flashing back the factory hex file, I can see the LED lighting up. So looks good.

Run log:

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c pkobn_updi -p avr64ea48 -U flash:r:avr64ea48_cnano_factory.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961e (probably avr64ea48)

avrdude: processing -U flash:r:avr64ea48_cnano_factory.hex:i
avrdude: reading flash memory ...
Reading | ################################################## | 100% 13.17 s
avrdude: writing output file avr64ea48_cnano_factory.hex

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c pkobn_updi -p avr64ea48 -U .\median_Release_1.0.0.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961e (probably avr64ea48)
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: processing -U flash:w:.\median_Release_1.0.0.hex:i
avrdude: reading input file .\median_Release_1.0.0.hex for flash
         with 5122 bytes in 1 section within [0, 0x1401]
         using 41 pages and 126 pad bytes
avrdude: writing 5122 bytes flash ...
Writing | ################################################## | 100% 2.48 s
avrdude: 5122 bytes of flash written
avrdude: verifying flash memory against .\median_Release_1.0.0.hex
Reading | ################################################## | 100% 1.23 s
avrdude: 5122 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c pkobn_updi -p avr64ea48 -U .\avr64ea48_cnano_factory.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961e (probably avr64ea48)
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: processing -U flash:w:.\avr64ea48_cnano_factory.hex:i
avrdude: reading input file .\avr64ea48_cnano_factory.hex for flash
         with 6206 bytes in 1 section within [0, 0x183d]
         using 49 pages and 66 pad bytes
avrdude: writing 6206 bytes flash ...
Writing | ################################################## | 100% 2.95 s
avrdude: 6206 bytes of flash written
avrdude: verifying flash memory against .\avr64ea48_cnano_factory.hex
Reading | ################################################## | 100% 1.47 s
avrdude: 6206 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

For those want to try out the latest release without building from source, here are the snaphost binraries you can test.
https://github.com/mcuee/avrdude/releases/tag/snapshot_29June2023

[elfmimi]

My concern is this one.
#1006 (Bug, fixed by PR #1294)
I confirm that it is now fixed.

[dioannidis]

In PR's #1294 first comment says that the #968 bug is fixed also.

Using the @mcuee's above snapshot ( if it's builded with MSVC and not with MinGW ) I confirm that it is now fixed .

[mcuee]

@dioannidis
#1294 does not fix #968. The 32bit Windows binary in the above snapshot was using MinGW (libusb-1.0 + libusb-compat-0.1) so that #968 is applicable.

#968 will be applicable for the MSVC build (using avrdude-libusb).

[mcuee]

I have tested avrdude git main with more common programmer like usbasp, stk500v2, avrispmkii (isp and pdi), pkobn_updi and jtag2updi and so far so good.

I am going to test a few programmers which I seldom use to see if there are any issues with git main.

I have not tested JTAG ICE 1 (clone) for quite some time. And it is working fine.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c jtag1 -P COM41 -p m128A -U .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9702 (probably m128a)
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: processing -U flash:w:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i
avrdude: reading input file .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex for flash
         with 388 bytes in 2 sections within [0x1fe00, 0x1ffff]
         using 2 pages and 124 pad bytes
avrdude: writing 388 bytes flash ...
Writing | ################################################## | 100% 0.05 s
avrdude: 388 bytes of flash written
avrdude: verifying flash memory against .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 388 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p m128A -U flash:v:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i -qq && echo OK
OK

[mcuee]

Same for AVRDragon in JTAG mode and ISP mode.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p m128A -e
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9702 (probably m128a)
avrdude: erasing chip

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m128A -U .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9702 (probably m128a)
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: processing -U flash:w:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i
avrdude: reading input file .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex for flash
         with 388 bytes in 2 sections within [0x1fe00, 0x1ffff]
         using 2 pages and 124 pad bytes
avrdude: writing 388 bytes flash ...
Writing | ################################################## | 100% 0.03 s
avrdude: 388 bytes of flash written
avrdude: verifying flash memory against .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 388 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -p m128A -U flash:v:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i -qq && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_isp -p m128A -U .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex -B1
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9702 (probably m128a)
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: processing -U flash:w:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i
avrdude: reading input file .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex for flash
         with 388 bytes in 2 sections within [0x1fe00, 0x1ffff]
         using 2 pages and 124 pad bytes
avrdude: writing 388 bytes flash ...
Writing | ################################################## | 100% 0.13 s
avrdude: 388 bytes of flash written
avrdude: verifying flash memory against .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 388 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

Same for my USB AVR910 (ATmega8535 based).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avr910 -P COM42 -p m128A -U .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9702 (probably m128a)
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: processing -U flash:w:.\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex:i
avrdude: reading input file .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex for flash
         with 388 bytes in 2 sections within [0x1fe00, 0x1ffff]
         using 2 pages and 124 pad bytes
avrdude: writing 388 bytes flash ...
Writing | ################################################## | 100% 0.16 s
avrdude: 388 bytes of flash written
avrdude: verifying flash memory against .\urboot_m128a_1s_autobaud_uart0_rxe0_txe1_lednop_pr_ee_ce.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 388 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

Same for STK500 clone with official V1 firmware (ATmega8535)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c stk500v1 -P COM42 -p m16A -U .\m16a_muzi.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
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: processing -U flash:w:.\m16a_muzi.hex:i
avrdude: reading input file .\m16a_muzi.hex for flash
         with 16384 bytes in 1 section within [0, 0x3fff]
         using 128 pages and 0 pad bytes
avrdude: writing 16384 bytes flash ...
Writing | ################################################## | 100% 8.34 s
avrdude: 16384 bytes of flash written
avrdude: verifying flash memory against .\m16a_muzi.hex
Reading | ################################################## | 100% 4.79 s
avrdude: 16384 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

I have also done some testing under macOS (Mac Mini M1 2020, macOS Ventura 13.4 on Apple Silicon ARM64) and Linux (Ubuntu 20.04 x64). So far so good.

[mcuee]

The pending PRs have all been merged with the exception of PR #1324 which will be delayed since there are still issues not resolved.

[mcuee]

Now git main will be very close to the avrdude 7.2 release.

For those who want to carry out the test but do not want to build from source, here are the binaries for testing.
https://github.com/mcuee/avrdude/releases/tag/snapshot_15July2023

[mcuee]

Just tried FreeBSD 13.2 Release on my Raspberry Pi 400 (for sure not as smooth as Raspberry Pi OS since the Firefox browser is suprer slow, so I use SSH from my Windows 11 machine, which becomes very smooth), avrdude works fine.

freebsd@FreeBSD132RPI400:~/build/avr % uname -a
FreeBSD FreeBSD132RPI400 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC arm64

freebsd@FreeBSD132RPI400:~/build/avr % cd avrtest/
freebsd@FreeBSD132RPI400:~/build/avr/avrtest % sh avrtest
hole/lext test m2560 OK
srec/hex test m328p OK
hex/srec test m328p OK
raw test m2560 OK
b number test m2560 OK
o number test m2560 OK
d number test m2560 OK
h number test m2560 OK
R number test m2560 OK

freebsd@FreeBSD132RPI400:~/build/avr/avrdude_test % avrdude -c usbasp -p m16a -U m16a_test.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
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: processing -U flash:w:m16a_test.hex:i
avrdude: reading input file m16a_test.hex for flash
         with 16384 bytes in 1 section within [0, 0x3fff]
         using 128 pages and 0 pad bytes
avrdude: writing 16384 bytes flash ...
Writing | ################################################## | 100% 2.79 s
avrdude: 16384 bytes of flash written
avrdude: verifying flash memory against m16a_test.hex
Reading | ################################################## | 100% 1.70 s
avrdude: 16384 bytes of flash verified

avrdude done.  Thank you.

[mcuee]

I tried to install NetBSD 9.3 release on my Raspberry Pi 400 but I was not able to get it to work.

Then I tried to install OpenBSD 7.3 on my Raspberry Pi 400. I was able to install it on a USB Flash Drive but it was too slow (seems to be a known problem) so I gave up.

Anyway, I think this a niche use case. After 7.2 release, I may try other embedded ARM hosts (my Orange Pi boards and older Raspberry Pi 3B+).

[mcuee]

I just got NetBSD 9.3 installed on my Raspberry Pi 3B+ and avrdude git main works fine.

arm64$ avrdude -c usbasp -p m16a -e
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
avrdude: erasing chip

avrdude done.  Thank you.

arm64$ avrdude -c usbasp -p m16a -U m16a_netbsd.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
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: processing -U flash:w:m16a_netbsd.hex:i
avrdude: reading input file m16a_netbsd.hex for flash
         with 16384 bytes in 1 section within [0, 0x3fff]
         using 128 pages and 0 pad bytes
avrdude: writing 16384 bytes flash ...
Writing | ################################################## | 100% 18.20 s
avrdude: 16384 bytes of flash written
avrdude: verifying flash memory against m16a_netbsd.hex
Reading | ################################################## | 100% 17.92 s
avrdude: 16384 bytes of flash verified

avrdude done.  Thank you.

arm64$ uname -a
NetBSD arm64 9.3 NetBSD 9.3 (GENERIC64) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 evbarm

[mcuee]

Same for OpenBSD 7.3 on Raspberry Pi 3B+.

openbsdrpi3$ sudo ./avrdude -c usbasp -p m16a -e
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
avrdude: erasing chip

avrdude done.  Thank you.

openbsdrpi3$ sudo ./avrdude -c usbasp -p m16a -U m16a_openbsd.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9403 (probably m16a)
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: processing -U flash:w:m16a_openbsd.hex:i
avrdude: reading input file m16a_openbsd.hex for flash
         with 16384 bytes in 1 section within [0, 0x3fff]
         using 128 pages and 0 pad bytes
avrdude: writing 16384 bytes flash ...
Writing | ################################################## | 100% 19.32 s
avrdude: 16384 bytes of flash written
avrdude: verifying flash memory against m16a_openbsd.hex
Reading | ################################################## | 100% 2.25 s
avrdude: 16384 bytes of flash verified

avrdude done.  Thank you.

openbsdrpi3$ uname -a
OpenBSD openbsdrpi3.my.domain 7.3 GENERIC.MP#2194 arm64

[mcuee]

Simple tests done on the following platform.

macOS 13.4 ARM64 (mac Mini M1)

• build
• run

macOS 13.4 x86_64 using Rosetta Translation, not native (mac Mini M1)

• build
• run

Linux x86_64 (Ubuntu 20.04, Debian 12)

• build
• run

Linux ARM32 (Raspberry Pi 400 running Raspberry Pi OS Bullseye 32 bit)

• build
• run

Windows VS2022 64 bit (Windows 11 x64 laptop)

• build
• run

Windows MinGW 64 bit (Windows 11 x64 laptop)

• build
• run

FreeBSD 64 bit (x86_64 and ARM64) -- FreeBSD 13.2 release, VirtualBox VM and Raspberry Pi 400

• build
• run

OpenBSD 64 bit (x86_64 and ARM64) -- OpenBSD 7.2 release with VirtualBox VM and OpenBSD 7.3 Release on Raspberry Pi 3B+

• build
• run

NetBSD 64 bit (x86_64 and ARM64) -- NetBSD 9.3 release with VirtualBox VM and on Raspberry Pi 3B+

• build
• run

[mcuee]

@MCUdude seems to still care for auto-tools build and it is still working under my Mac Mini M1 2020 (mac OS Ventura 13.4.1).

[stefanrueger]

We are now getting into diminishing returns from our tests. On balance (and given their simple nature) I would slightly prefer to merge #1468 and #1470 before releasing v7.2 (but also happy to merge after releasing). I could merge tomorrow, and other than that, recommend the release.

[dl8dtl]

Personal opinion: delay both PRs right now, and just release it.

The STK500v1 detection has probably been broken for quite a while, and nobody noticed it. The reason is exactly the same as I could see in the audit trail of the bug issue: probing V1 first, and V2 second makes no sense these days, so we reversed it some day – and thereby apparently broke it entirely.
I'd just avoid the risk of introducing more bugs, so rather go along with a known bug.
Likewise for the Vtarget stuff: it's a bug, but nothing earth-shattering.

So from me: just roll the release.

[stefanrueger]

Yes, agreed. I can relate to that. So, if @mcuee and @MCUdude agree, it's over to you, @dl8dtl for the final honours.

[mcuee]

@dl8dtl @stefanrueger and @MCUdude

Yes I agree to proceed with the release of avrdude 7.2 now.

[MCUdude]

I'm fine with a 7.2 release without merging #1468 and #1470

[mcuee]

@dl8dtl

Great. Now you can roll the release.

[dl8dtl]

OK, I thought Stefan would be the next guy to roll a release. ;-)

After all, you guys did all the work on it.

Sure, if you don't want to do it, I'll do. I'm just busy a bit (out of curiosity) to get parallel programming working for an ATmega128RFA1.

[MCUdude]

Before we release anything, I'd be interested to see what this issue is about. Still waiting for OP to provide more details, but a weird error anyway.

https://forum.arduino.cc/t/port-not-found-in-avrdude/1149292

[dl8dtl]

i cannot reproduce that in any way. Regardless of what I'm trying, AVRDUDE can clearly distinguish -p from -P.
Since I have seen Powershell doing strange things with a Pipe (it completely corrupts the piped data), my first question would be which shell has been used there. Suppose for a minute, their shell transposes all uppercase letters to lowercase, then the resulting message would no longer be a suprise to me.

[stefanrueger]

Yes, I think one of us would have noticed. Also, this is defo nowhere near the current version, which might say AVR part COM6 not found but defo not AVR Part "COM6" not found. (Find the 4 differences in the error message :)

[mcuee]

I do not think Powershell will do that as I am using Powershell most of the time under Windows. The answer from ptillisch is totally wrong and jumped to wrong conclusion without waiting for the OP of that post to come back.

I suspect that the CH340 latest driver is the issue -- I have to use back older version for avrdude to work under Windows. But in my case the error message is different.

• WCH CH340 serial port issue under Windows: can't set com-state for "\\.\COMx #1328

[MCUdude]

It seems like OP posted a different question on the avrfreaks forum, and there he used Avrdude 6.3. So I'm pretty sure that's what he used in the Arduino forum thread as well.

[dl8dtl]

It's done now, congratulations guys to your hard work! Awesome!

Stefan asked for a transcript what I've been doing:
releaseprocedure.txt

[mcuee]

This procedure is well written. Probably it can be added to git repo, or at least in Wiki.

[mcuee]

WIki page created:
https://github.com/avrdudes/avrdude/wiki/Release-Procedure

[stefanrueger]

transcript

@dl8dtl Brilliant! Thanks for this and for trailblazing the release.

[mcuee]

@umbynos

Now that avrdude 7.2 has been released. Hopefully you can start the process on rolling the build here.
https://github.com/arduino/avrdude-packing

[mcuee]

Early adopters of avrdude 7.2

1. macOS Homebrew (avrdude 7.2)
   https://github.com/Homebrew/homebrew-core/blob/0328ea99163b8fd854468908f76ad2a22f126a74/Formula/avrdude.rb

2. Arch Linux has avrdude 7.2
   https://archlinux.org/packages/extra/x86_64/avrdude/

[dl8dtl]

I just updated the FreeBSD ports.

[mcuee]

Updated on 30-July-2023

Here is the updated situation for avrdude version used by major OS distributions. We will rely on the community to raise ticket to the respective project/distro to upgrade the avrdude version in the distributions.

1. macOS Homebrew (avrdude 7.2)
   https://github.com/Homebrew/homebrew-core/blob/0328ea99163b8fd854468908f76ad2a22f126a74/Formula/avrdude.rb

2. Arch Linux has avrdude 7.2
   https://archlinux.org/packages/extra/x86_64/avrdude/

3. FreeBSD ports (avrdude 7.2)
   https://www.freshports.org/devel/avrdude

4. macOS macPorts (avrdude 7.0)
   https://ports.macports.org/port/avrdude/details/

5. OpenBSD ports (avrdude 6.3)
   https://openports.pl/path/devel/avrdude

6. NetBSD pkgsrc (avrdude 6.4)
   https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/cross/avrdude/index.html

7. WIndows winget -- avrdude 7.1
   https://github.com/microsoft/winget-pkgs/tree/master/manifests/a/AVRDudes/AVRDUDE/7.1

8. Windows Scoop -- avrdude 7.1
   https://github.com/ScoopInstaller/Main/blob/master/bucket/avrdude.json

9. Windows chocolatey -- avrdude 6.3
   https://community.chocolatey.org/packages/avrdude

10. Debian Linux stable and testing -- avrdude 7.1
    https://packages.debian.org/search?keywords=avrdude

11. Ubuntu 23.04 and earlier use avrdude 6.3, next version (23.10) will use avrdude 7.1
    https://packages.ubuntu.com/search?keywords=avrdude

12. Fedora 39 is using avrdude 6.4
    https://src.fedoraproject.org/rpms/avrdude