Stefan Rueger

... more problems: digitalPinToPCMSK(p) is plain wrong (it's a copy from ATmega328P). Should be #define digitalPinToPCMSK(p) (((p)

So, the affected boards' bootloaders latch on to the `-c usbtiny` protocol, which I believe has no handshake. For this to work, AVRDUDE would need to wait for the requests...

And also, have a look at the proposed urprotocol https://github.com/avrdudes/avrdude/discussions/940#discussioncomment-3017328, which is meant to help establish exactly what the bootloader is capable of. This should, if/once implemented into future AVRDUDE...

> > flash->num_pages * part->chip_erase_delay > We now know that the ATtiny85 works with 400 ms delay, while it fails with 100 ms. Does that somewhat fit into this formula?...

But I wouldn't just use the formula. I would cap it somehow. For an ATmega2560 this results in a 9.2 s pause that is hard to explain to users that...

Fixed with PR #1059

> put the fix on top of PR #1063 Either way is fine. Thanks for looking into this!

Fixed by PR #1063

It's a bootloader section write issue, so I wonder whether it's worthwhile playing with the lock bytes and the fuses: change the fuses for a larger, say 1024 bytes, boot...

Looks like a really hard nut. @MCUdude's test put paid to my theory about the boot section. Certain input files can be written certain input files cannot be written. The...