Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino #1140

stefanrueger · 2022-10-20T23:23:02Z

Supposed to fix Issue #1120

The stk500v1 code in stk500.c is now able to discriminate between usage for a real STK500 programmer with a (very) old firmware or a bootloader in which case the new prog_modes variable has the PM_SPM bit set:

avrdude/src/avrdude.conf.in

Lines 751 to 757 in b864d7e

    
           programmer 
        
               id                     = "arduino"; 
        
               desc                   = "Arduino for bootloader using STK500 v1 protocol"; 
        
               type                   = "arduino"; 
        
               prog_modes             = PM_SPM; 
        
               connection_type        = serial; 
        
           ;

If it's -c arduino, ie, for bootloaders, then the part that is being programmed determines what the STK500v1 protocol variant does: if it's a classic part, all addresses are sent as word addresses (optiboot), if it's an XMEGA or a newer part (UDPI interface) then they are sent as byte addresses. Furthermore, for large parts, the stk500v1 code will then simply send the 0x4d 0x00 ext_addr 0x00 sequence that all these bootloaders expect for the bits 16-23 of either the word or the byte address that's needed.

@WestfW, @SpenceKonde and @MCUdude: Hopefully this will do the trick supporting optiboot, optiboot_dx and optiboot_x for -c arduino without having to resort to shenanigans in avrdude.conf. @dl8dtl and @mcuee may be intrigued to learn that this also supports the original STK500v1 protocol for the -c stk500v1 programmer serving the STK500 hardware with a FW before 2005 (the latter clearly is for the software archaeologists under us).

mcuee · 2022-10-21T00:09:33Z

@stefanrueger

Yes it works with optiboot_dx on the AVR128DB48 Curiosity Nano board. But there is a false verification error message during the verification stage, which is the same as what I encountered before (for larger hex file). This may be a seperate issue.

The programming itself is good as I verified with the onbpard pkobn_updi programmer as well. Standalone verification with the bootloader is also good.

[Regression] Optiboot for "modern AVRs" does not work with upstream version of Avrdude. #1120 (comment)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140 -c arduino -P COM6 -b 115200 -p avr128db48 
-qq -D -U .\hex2\hexaa64KB_with_blink.hex && echo OK
avrdude_pr1140 error: verification mismatch, first encountered at addr 0x0200
               device 0xff != input 0x79
avrdude_pr1140 error: verification mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140 -c pkobn_updi -p avr128db48 -qq -D 
-U flash:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140 -c arduino -P COM6 -b 115200 -p avr128db48 
-qq -D -U flas:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
OK

I will test STK500V1 later.
As of now I can not test optiboot_dx with less than 64KB flash but I should be able to do that in a few weeks.

stefanrueger · 2022-10-21T11:23:11Z

This may be a seperate issue.

Yes, I think this could be a bug in optiboot_dx in the way it deals with the extended byte in the following lines

https://github.com/SpenceKonde/DxCore/blob/3c4909ef7bae32700c060a79a78348b3cb03bce1/megaavr/bootloaders/optiboot_dx/optiboot_dx.c#L819

https://github.com/SpenceKonde/DxCore/blob/3c4909ef7bae32700c060a79a78348b3cb03bce1/megaavr/bootloaders/optiboot_dx/optiboot_dx.c#L857-L858

Optiboot_dx uses elpm rx,Z+ to read a byte from flash and spm Z+ to write flash bytes; it also keeps a copy of AVDUDE's ext_addr_byte in RAMPZ. So, if an upload with automated verify finishes just below 64k, AVRDUDE still holds the ext_addr_byte at the current 64k segment whilst its copy RAMPZ in the bootloader has been auto-incremented. When the next step after uploading exactly 64k is to verify the code from start, then this will expose the discrepancy.

I pushed a commit to repair Optiboot_dx's bug in AVRDUDE. Please test.

@mcuee You did a really great job with testing here. This bug only surfaces with an input file with its highest flash page just below 64k. Great job.

SpenceKonde · 2022-10-21T13:13:16Z

I'd argue that it's perfectly reasonable for the bootloader to expect that the next word interacted with after 32767 is word 32768, and to expect the host to tell it otherwise at the start of verify. You've gotta admit this is a corner case - and the upload would have succeeded, thought the verify would have erroneously reported a failure.
At the point in optiboot_dx where decisions were being made, I was struggling to get just a couple of instruction words to squeak under the 512b minimum bootloader size. I did NOT want to lock in a bloated bootloader and I was only over by like a half dozen instructions, by hook or by crook, that bootloader would be made to fit 512b! I was doing everything I could at one point to get the last few words off to fit it 512, including rewriting ever larger chunks in assembly for paltry returns. Not using SPM Z+ means an extra instruction to increment the pointer! we don't have space for that! (the bootloader came to 518b or something at that point - IIRC I later found some savings, which went towards ensuring that a "dirty reset" could be recovered from without a physical reset pin reset or power cycle.

(difficult to arrange when on a battery meant to last all winter and get recharged in the off season or a solar cell to stay charged and there's a mile of deep snow between you and the device, and you've got some custom OTA update scheme with some other means of resetting it remotely)

(I know a system where this was implemented. It almost worked too - the killer was the virtual boot erase bug, which i didn't understand fully at the time, And they had a hundreds of em deployed in near wilderness in the middle of winter before the problem was discovered, Pity, he was a very good client, paid well and gave interesting assignments, Bit not fixing the virtual boot bug cost me any future work for him :-/ (and I knew there was tons more where that came from)

And of course, on modern AVRs, updating the bootloader requires recompiling sketches for them . The hex files compiled assuming a 1024 byte bootloader are incompatible with a 512b bootloader (or to be pedantic, a binary generated for a BOOTSIZE = 2 is incompatible with BOOTSIZE = 1)

mcuee · 2022-10-21T13:35:00Z

@mcuee You did a really great job with testing here. This bug only surfaces with an input file with its highest flash page just below 64k. Great job.

@stefanrueger
Thanks. It is kind of by luck. I was searching for the usage of srec_cat in this github repo and I found the trick by @MCUdude to generate large hex files for testing (example: srec_cat -generate 0x00 0x1ffff -repeat_data 0x55 -o 0x55_128kib.hex -Intel). So I adopted his testing strategy and combined the blink hex file into the test hex file.

mcuee · 2022-10-21T13:41:15Z

I'd argue that it's perfectly reasonable for the bootloader to expect that the next word interacted with after 32767 is word 32768, and to expect the host to tell it otherwise at the start of verify. You've gotta admit this is a corner case - and the upload would have succeeded, thought the verify would have erroneously reported a failure.

Interesting perspective. Thanks for the sharing of the background.

mcuee · 2022-10-21T13:59:27Z

@dl8dtl and @mcuee may be intrigued to learn that this also supports the original STK500v1 protocol for the -c stk500v1 programmer serving the STK500 hardware with a FW before 2005 (the latter clearly is for the software archaeologists under us).

@stefanrueger
Indeed it works now for the physical STK500 programmer with V1 FW.

git main will fail and this PR will pass, for ATmega328P.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c stk500v1 -P COM18 -p m328p -qq 
-U eeprom:w:.\hex\entest.eep:i && echo OK
avrdude_git error: verification mismatch, first encountered at addr 0x0002
            device 0x71 != input 0x65
avrdude_git error: verification mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140v1 -c stk500v1 -P COM18 -p m328p -qq 
-U eeprom:w:.\hex\entest.eep:i && echo OK
OK

Same results for ATmega8A.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c stk500v1 -P COM18 -p m8a -qq 
-U eeprom:w:.\hex\entest.eep:i && echo OK
avrdude_git error: verification mismatch, first encountered at addr 0x0002
            device 0x71 != input 0x65
avrdude_git error: verification mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140v1 -c stk500v1 -P COM18 -p m8a -qq 
-U eeprom:w:.\hex\entest.eep:i && echo OK
OK

mcuee · 2022-10-21T14:20:45Z

I pushed a commit to repair Optiboot_dx's bug in AVRDUDE. Please test.

@stefanrueger

Yes now the false verification error message is gone. Now optiboot_dx works perfect for the avr128db48.

(write the bootloader first)
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140v1 -c pkobn_updi -p avr128db48 -qq 
-U .\hex2\optiboot_dx_avr128db48_uart3_8s.hex && echo OK
OK

(using the optiboot_dx bootloader)
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1140v1 -c arduino -P COM6 -b 115200 -p avr128db48 
-D -U .\hex2\hexaa64KB_with_blink.hex && echo OK

avrdude_pr1140v1: AVR device initialized and ready to accept instructions

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

avrdude_pr1140v1: device signature = 0x1e970c (probably avr128db48)
avrdude_pr1140v1: reading input file .\hex2\hexaa64KB_with_blink.hex for flash
                  with 65007 bytes in 2 sections within [0x200, 0xfffe]
                  using 127 pages and 17 pad bytes
avrdude_pr1140v1: writing 65007 bytes flash ...

Writing | ################################################## | 100% 10.59s

avrdude_pr1140v1: 65007 bytes of flash written
avrdude_pr1140v1: verifying flash memory against .\hex2\hexaa64KB_with_blink.hex

Reading | ################################################## | 100% 7.57s

avrdude_pr1140v1: 65007 bytes of flash verified

avrdude_pr1140v1 done.  Thank you.

OK

stefanrueger · 2022-10-21T16:28:28Z

| this is a corner case

@SpenceKonde Absolutely, and I am vvv happy that we can solve this AVRDUDE side! I have every sympathy for saving instructions in the bootloader particularly when you are on the boundary of 512 bytes. Well done, too, for going with byte addresses (saves the times two in the bootloader that's particularly costly for those > 64k flash devices).

Please give this PR a shot with optiboot_x and optiboot_dx and your devices. You should be able to program with -c arduino straight from this PR. You will need to install the avrdude.conf from this PR for the prog_modes = PM_SPM; line in the arduino programmer definition. It really should all work out of the box (no need to mod your own avrdude.conf) - and if not give us a shout here! Ask @mcuee for some difficult hex files: with holes in them, last page just below 64, and ones that stretch beyond 64k, too, to check load ext addr (that is untested as far as I can tell).

stefanrueger · 2022-10-21T16:34:28Z

Indeed it works now for the physical STK500 programmer with V1 FW.

Brilliant, thanks @mcuee for testing the ATmega328P and the ATmega8A which represent the two main MCU classes. I know that there should be no one around who still uses the STK500 programmer with FW1.x, but it's kind of a satisfying feeling that AVRDUDE can do this :)

MCUdude · 2022-10-22T20:36:36Z

Sorry for being so slow to test this PR! I can confirm that writing to flash and EEPROM works perfectly fine using optiboot_x and ATmega4808. Thanks, @stefanrueger!

mcuee · 2022-10-23T03:08:30Z

@MCUdude
Great that optiboot_x now works well. The last thing to check is for AVR Dx parts with <=64KB Flash. Just wondering if you have got optiboot_dx working on the AVR64DD32 Curioisty Nano board working. No worry if you have not done that yet.

I have ordered that board as well from Mouser Singapore on Monday and I am waiting for the board (not yet shipped). Previously I was able to get AVR128DB48 Curiosity Nano to work with optiboot_dx (8s delay firmware) and tested this PR to be good.

Parts	memory	size	a_div
UPDI-chips (optiboot_dx)	flash	>64k	1
UPDI-chips (optiboot_dx)	flash	<=64k	1 ?
UPDI-chips (optiboot_x megaTinyCore)	flash	<=64k	1
UPDI-chips (optiboot_x MegaCoreX)	flash	<=64k	1
UPDI-chips (optiboot_x and optiboot_dx)	eeprom	all	1
ISP-chips (optiboot)	flash	all	2
ISP-chips (optiboot)	eeprom	all	2 (with a few exceptions)

mcuee · 2022-10-23T03:38:01Z

Always use paged access for programmers that serve bootloaders #1141 (comment)
@stefanrueger

Great, now this works with ATmega161. I am using the Bigboot optiboot hex file for ATmega328P with EEPROM support in this test.

$ yes hello, world | head -512c | ./avrdude -q -p m161 -F -c arduino -b 115200 -P COM4 -U eeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude warning: expected signature for ATmega161 is 1E 94 01
avrdude: reading input file <stdin> for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 32 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>
avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

$ yes hello, world | head -512c | ./avrdude -q -p m328p -c arduino -b 115200 -P COM4 -U eeprom:v:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: verifying eeprom memory against <stdin>
avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

It also works with the other three classic AVRs which has the same issue.

$ yes hello, world | head -512c | ./avrdude -q -p m169 -F -c arduino -b 115200 -P COM4 -U eeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude warning: expected signature for ATmega169 is 1E 94 05
avrdude: reading input file <stdin> for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 128 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>
avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

$ yes hello, world | head -512c | ./avrdude -q -p m8515 -F -c arduino -b 115200 -P COM4 -U eeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude warning: expected signature for ATmega8515 is 1E 93 06
avrdude: reading input file <stdin> for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 32 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>
avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

$ yes hello, world | head -512c | ./avrdude -q -p m8535 -F -c arduino -b 115200 -P COM4 -U eeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude warning: expected signature for ATmega8535 is 1E 93 08
avrdude: reading input file <stdin> for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 32 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...
avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>
avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

MCUdude · 2022-10-23T10:27:50Z

I just tried with an AVR64DD32, but I'm unable to write to either flash or EEPROM. However, DxCore does not provide a dedicated bootloader for the DD series (even though they're present in the DxCore boards.txt), so I used the default one that's used for AVR DA and DB. I can communicate with the target, but I can't get it to work. However, I can't get it to work with Avrdude 6.3 or 7.0 either, so it might be a bootloader issue, not sure... Maybe @SpenceKonde knows?
It would be interesting to try with an AVR-DA or AVR-DB with 64kiB flash or less since we know these bootloaders actually works.

$  ./avrdude -carduino -pavr64dd32 -P /dev/cu.usbserial-A50285BI -D -Uflash:w:blink_4808_0x200.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e961a (probably avr64dd32)
avrdude: reading input file blink_4808_0x200.hex for flash
         with 768 bytes in 1 section within [0x200, 0x4ff]
         using 2 pages and 256 pad bytes
avrdude: writing 768 bytes flash ...

Writing | #########################                          | 50% 0.00savrdude error: programmer is not responding
Writing | ################################################## | 100% 5.07s

 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;

...

 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
avrdude: 768 bytes of flash written
avrdude: verifying flash memory against blink_4808_0x200.hex

Reading | ################################################## | 100% 0.07s

avrdude error: verification mismatch, first encountered at addr 0x0200
        device 0xff != input 0x47
avrdude error: verification mismatch

avrdude done.  Thank you.

stefanrueger · 2022-10-23T20:47:45Z

can't get it to work with Avrdude 6.3 or 7.0 either, so it might be a bootloader issue, not sure... Maybe @SpenceKonde knows?

It may be the case that the bootloaders expects modified entries for these parts in a private avrdude.conf to trick avrdude 6.3 and 7.0 to work with them. @SpenceKonde isn't very communicative about this (I asked thrice, and won't ask a fourth time); we probably could figure out by reading the bootloader source, but seeing that there is progress in other parts of AVRDUDE that needs tending to this will have to go on the backburner.

MCUdude · 2022-10-23T21:17:59Z

@stefanrueger I can confirm that this PR solves the EEPROM issue for "classic" AVRs!

$ ./avrdude -patmega8535 -carduino -Ueeprom:w:hello_world_256B.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9308 (probably m8535)
avrdude: reading input file hello_world_256B.hex for eeprom
         with 256 bytes in 1 section within [0, 0xff]
         using 16 pages and 0 pad bytes
avrdude: writing 256 bytes eeprom ...

Writing | ################################################## | 100% 2.13s

avrdude: 256 bytes of eeprom written
avrdude: verifying eeprom memory against hello_world_256B.hex

Reading | ################################################## | 100% 0.11s

avrdude: 256 bytes of eeprom verified

avrdude done.  Thank you.


$ echo "read eeprom" | ./avrdude -patmega8535 -carduino -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: device signature = 0x1e9308 (probably m8535)
>>> read eeprom 

Reading | ################################################## | 100% 0.12s

0000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 68 65 6c  |hello, world hel|
0010  6c 6f 2c 20 77 6f 72 6c  64 0a 68 65 6c 6c 6f 2c  |lo, world hello,|
0020  20 77 6f 72 6c 64 0a 68  65 6c 6c 6f 2c 20 77 6f  | world hello, wo|
0030  72 6c 64 0a 68 65 6c 6c  6f 2c 20 77 6f 72 6c 64  |rld hello, world|
0040  0a 68 65 6c 6c 6f 2c 20  77 6f 72 6c 64 0a 68 65  | hello, world he|
0050  6c 6c 6f 2c 20 77 6f 72  6c 64 0a 68 65 6c 6c 6f  |llo, world hello|
0060  2c 20 77 6f 72 6c 64 0a  68 65 6c 6c 6f 2c 20 77  |, world hello, w|
0070  6f 72 6c 64 0a 68 65 6c  6c 6f 2c 20 77 6f 72 6c  |orld hello, worl|
0080  64 0a 68 65 6c 6c 6f 2c  20 77 6f 72 6c 64 0a 68  |d hello, world h|
0090  65 6c 6c 6f 2c 20 77 6f  72 6c 64 0a 68 65 6c 6c  |ello, world hell|
00a0  6f 2c 20 77 6f 72 6c 64  0a 68 65 6c 6c 6f 2c 20  |o, world hello, |
00b0  77 6f 72 6c 64 0a 68 65  6c 6c 6f 2c 20 77 6f 72  |world hello, wor|
00c0  6c 64 0a 68 65 6c 6c 6f  2c 20 77 6f 72 6c 64 0a  |ld hello, world |
00d0  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 68 65 6c  |hello, world hel|
00e0  6c 6f 2c 20 77 6f 72 6c  64 0a 68 65 6c 6c 6f 2c  |lo, world hello,|
00f0  20 77 6f 72 6c 64 0a 68  65 6c 6c 6f 2c 20 77 6f  | world hello, wo|


avrdude done.  Thank you.

MCUdude · 2022-10-23T21:27:09Z

It may be the case that the bootloaders expects modified entries for these parts in a private avrdude.conf to trick avrdude 6.3 and 7.0 to work with them. @SpenceKonde isn't very communicative about this (I asked thrice, and won't ask a fourth time); we probably could figure out by reading the bootloader source, but seeing that there is progress in other parts of AVRDUDE that needs tending to this will have to go on the backburner.

Would you like to create an issue regarding AVR-Dx parts with less than 128kiB flash? I'll throw in some AVR64DA* and AVR64DB* chips in my next Digikey order, so we should be able to resolve this in a timely manner.

DxCore doesn't really support AVR-DDs yet either. A Basic blink example doesn't compile, there are bugs in the boards.txt file and working bootloaders are not present. I believe it's being worked on though...

mcuee · 2022-10-28T10:35:45Z

@MCUdude
Just wondering if you have tested with your ATtiny1616 optiboot_x?

I just can not get this to work with ATtiny1627 Curiosity Nano board. I use Arduino IDE 2.01 and megaTinyCore and it seems to be able to burn the bootloader, but then it is not able to upload the blink sketech using Arduino.

If I use Arduino 1.8.19, it even failed to burn the bootloader.

WIth the bootloader burned from Arduino 2.01, it does not work with either avrdude git main or 7.0 release. It does not seem to write anything (checked with the on-board pkobn_updi programmer).

I am thinking the bootloader does not work for this board (I am choosing official Microchip board with optiboot).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM20 -b 115200 
-p t1627 -D -U .\Blink.ino.t1627opti.20c0.mB1.v261.hex

avrdude7.exe: AVR device initialized and ready to accept instructions

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

avrdude7.exe: Device signature = 0x1e9428 (probably t1627)
avrdude7.exe: reading input file ".\Blink.ino.t1627opti.20c0.mB1.v261.hex"
avrdude7.exe: input file .\Blink.ino.t1627opti.20c0.mB1.v261.hex auto detected as Intel Hex
avrdude7.exe: writing flash (1234 bytes):

Writing | ################################################## | 100% 0.11s

avrdude7.exe: 1234 bytes of flash written
avrdude7.exe: verifying flash memory against .\Blink.ino.t1627opti.20c0.mB1.v261.hex:
avrdude7.exe: input file .\Blink.ino.t1627opti.20c0.mB1.v261.hex auto detected as Intel Hex

Reading | ################################################## | 100% 0.11s

avrdude7.exe: verification error, first mismatch at byte 0x0200
              0xff != 0x3b
avrdude7.exe: verification error; content mismatch

avrdude7.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin>.\avrdude_git -c arduino -P COM20 -b 115200 -p t1627 -D 
-U .\Blink.ino.t1627opti.20c0.mB1.v261.hex

avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e9428 (probably t1627)
avrdude_git: reading input file .\Blink.ino.t1627opti.20c0.mB1.v261.hex for flash
             with 722 bytes in 1 section within [0x200, 0x4d1]
             using 12 pages and 46 pad bytes
avrdude_git: writing 722 bytes flash ...

Writing | ################################################## | 100% 0.11 s

avrdude_git: 722 bytes of flash written
avrdude_git: verifying flash memory against .\Blink.ino.t1627opti.20c0.mB1.v261.hex

Reading | ################################################## | 100% 0.11 s

avrdude_git error: verification mismatch, first encountered at addr 0x0200
            device 0xff != input 0x3b
avrdude_git error: verification mismatch

avrdude_git done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p t1627 -q -t

             Vtarget                      : 3.31 V
             PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e9428 (probably t1627)
avrdude> dump flash 0x200
>>> dump flash 0x200
0200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0210  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0220  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0230  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0240  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0250  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0260  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0270  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0280  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0290  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
02f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> quit
>>> quit
avrdude>
avrdude_git done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM20 -b 115200 -p t1627 -qq -t
avrdude> dump flash 0x200 0x10
>>> dump flash 0x200 0x10
0200  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> write flash 0x200 0xaa 0x55 0xaa 0x55
>>> write flash 0x200 0xaa 0x55 0xaa 0x55
avrdude> flush
>>> flush
avrdude_git error: verification mismatch at flash page addr 0x0200
avrdude> dump flash 0x200 0x10
>>> dump flash 0x200 0x10
0200  aa 55 aa 55 ff ff ff ff  ff ff ff ff ff ff ff ff  |.U.U............|

avrdude> quit
>>> quit
avrdude> avrdude_git error: verification mismatch at flash page addr 0x0200

It seems to work with EEPROM though.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM20 -b 115200 -p t1627 -qq -t
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> write eeprom 0 0xaa 0x55 0xaa 0x55
>>> write eeprom 0 0xaa 0x55 0xaa 0x55
avrdude> flush
>>> flush
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa 55 aa 55 ff ff ff ff  ff ff ff ff ff ff ff ff  |.U.U............|

avrdude> quit
>>> quit
avrdude>

mcuee · 2022-10-28T11:25:24Z

DxCore doesn't really support AVR-DDs yet either. A Basic blink example doesn't compile, there are bugs in the boards.txt file and working bootloaders are not present. I believe it's being worked on though...

@MCUdude
Indeed this is true. I just got my AVR64DD32 Curiosity Nano board today and indeed DxCore does not work yet wth simple blinky sketch compile. optiboot_dx does not work either.

Then I chose the no bootloader option and tried to burn the bootloader and hope to set the right fuse settings -- now my board is bricked. It is my fault though as I did not notice that both the two options for reset require HV UPDI programmer. Stil this looks like a DxCore bug to me. I hope to revive it using PICKit 4 though.

Optiboot for AVR-DD SpenceKonde/DxCore#354 (comment)

mcuee · 2022-10-31T07:38:16Z

I hope to revive it using PICKit 4 though.

Yes I am able to revive the AVR64DD32 using PICkit 4.

Add support for high-voltage UPDI #1015 (comment)

SpenceKonde · 2022-10-31T14:57:25Z

Neither of those options is the one you should be using. The one you should be using is the Reset and UPDI option. That said option is not present is clearly a bug. I didn't name the menu options distinctly.

Do note that there is no currently working version of DxCore for the DD, and I need to get shared serial code that is currently hosed in mTC fixed and released on that core so I can start working on DxCore.

SpenceKonde · 2022-10-31T14:59:45Z

#----------------------------------------#
# Reset pin as INPUT, UPDI as I/O        #
#________________________________________#
avrddopti.menu.resetupdipinsopti.resetupdi=Reset & UPDI
avrddopti.menu.resetupdipinsopti.resetupdi.bootloader.resetpinbits=11
avrddopti.menu.resetupdipinsopti.inputupdi=Input & UPDI (no reset to enter optiboot)
avrddopti.menu.resetupdipinsopti.inputupdi.bootloader.resetpinbits=10
avrddopti.menu.resetupdipinsopti.resetgpio=Reset & GPIO (HV pulse RST for UPDI)
avrddopti.menu.resetupdipinsopti.resetgpio.bootloader.resetpinbits=01
avrddopti.menu.resetupdipinsopti.inputgpio=Input & GPIO (no reset, HV pulse for UPDI)
avrddopti.menu.resetupdipinsopti.inputgpio.bootloader.resetpinbits=00

I belive is what that section of board.txt should be.

SpenceKonde · 2022-11-12T11:12:24Z

You asked me about something? I did not receive

can't get it to work with Avrdude 6.3 or 7.0 either, so it might be a bootloader issue, not sure... Maybe @SpenceKonde knows?

It may be the case that the bootloaders expects modified entries for these parts in a private avrdude.conf to trick avrdude 6.3 and 7.0 to work with them. @SpenceKonde isn't very communicative about this (I asked thrice, and won't ask a fourth time); we probably could figure out by reading the bootloader source, but seeing that there is progress in other parts of AVRDUDE that needs tending to this will have to go on the backburner.

The avrdude.conf is modified for the 128k parts, to add support for loading that last address bit; I didn't see any way around that. Other than that, the avrdude.conf that dxcore uses is AFAIK standard (though I synthesized the entries for the DDs, since there wasn't a place to crib from.

I'm not sure what you asked me three times about, or where you asked me.... I didn't see any of that communication o_o
I'm happy to communicate, though right now I don't have anything to share about the DD's - right now I've gotten DxCore at least partly working on them, but somehow during the summer something went wrong with the timekeeping code (I kept getting pulled off of it over the summer, so I may have been in the middle of something related to timekeeping... I'm not really sure though), and I need to figure out what the hell it is before I can really do anything else with the core. (user code never runs with a type B timer, and with a type A timer, the timing is seriously broken - backwards timetravel on micros that's bad enough that delay is no good)

MCUdude · 2022-11-12T11:58:57Z

Huh, I didn't knew this was necessary in Avrdude 6.3. In the upsteam version of Avrdude (soon to be Avrdude 7.1), I can flash 128kiB sized programs using a UPDI programmer, or Optiboot_dx without a custom avrdude.conf. But I didn't know Avrdude 7+ did anything to the stk500v1 addressing scheme. Avrdude/stk500v1 has supported extended addresses for a long time, and Optiboot on ATmega2560 works up to 265kiB.

mcuee · 2022-12-25T12:21:06Z

@MCUdude and @SpenceKonde

DxCore 1.5.1 fixed the issue.

Optiboot for AVR-DD SpenceKonde/DxCore#354

C:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\tools\avrdude\6.3.0-arduino17or18/bin/avrdude -CC:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.4.10/avrdude.conf -v -pavr64dd32 -cpkobn_updi -Pusb -e -Ufuse0:w:0b00000000:m -Ufuse1:w:0x00:m -Ufuse5:w:0b11010000:m -Ufuse6:w:0b00001100:m -Ufuse8:w:0x01:m -Ufuse7:w:0x00:m -Uflash:w:C:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.4.10/bootloaders/hex/optiboot_64dd_ser0_alt3_all_8sec.hex:i 

avrdude: Version 7.0-20221101 (4c92030)
         Copyright (c) Brian Dean, http://www.bdmicro.com/
         Copyright (c) Joerg Wunsch

         System wide configuration file is C:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.4.10\avrdude.conf

         Using Port                    : usb
         Using Programmer              : pkobn_updi
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
         AVR Part                      : AVR64DD32
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse0       wdtcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse1       bodcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse2       osccfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse4       tcd0cfg     0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse5       syscfg0     0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse6       syscfg1     0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse7       codesize    0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuse8       bootsize    0     0     0    0 no          1    1      0     0     0 0x00 0x00
           fuses                   0     0     0    0 no          9   16      0     0     0 0x00 0x00
           lock                    0     0     0    0 no          4    1      0     0     0 0x00 0x00
           tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           prodsig                 0     0     0    0 no        125  125      0     0     0 0x00 0x00
           sernum                  0     0     0    0 no         16    1      0     0     0 0x00 0x00
           userrow     usersig     0     0     0    0 no         32   32      0     0     0 0x00 0x00
           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00
           eeprom                  0     0     0    0 no        256    1      0     0     0 0x00 0x00
           flash                   0     0     0    0 no      65536  512      0     0     0 0x00 0x00

         Programmer Type : JTAGICE3_UPDI
         Description     : Curiosity nano (nEDBG) in UPDI mode
         ICE HW version  : 0
         ICE FW version  : 1.25 (rel. 116)
         Serial number   : MC020019502HIP000639
         Vtarget         : 3.31 V
         PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude: partial Family_ID returned: "AVR "
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961a (probably avr64dd32)
erasing chip
avrdude: reading input file 0b00000000 for fuse0/wdtcfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse0/wdtcfg ...
avrdude: 1 byte of fuse0/wdtcfg written
avrdude: verifying fuse0/wdtcfg memory against 0b00000000
avrdude: 1 byte of fuse0/wdtcfg verified
avrdude: reading input file 0x00 for fuse1/bodcfg
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse1/bodcfg ...
avrdude: 1 byte of fuse1/bodcfg written
avrdude: verifying fuse1/bodcfg memory against 0x00
avrdude: 1 byte of fuse1/bodcfg verified
avrdude: reading input file 0b11010000 for fuse5/syscfg0
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse5/syscfg0 ...
avrdude: 1 byte of fuse5/syscfg0 written
avrdude: verifying fuse5/syscfg0 memory against 0b11010000
avrdude: 1 byte of fuse5/syscfg0 verified
avrdude: reading input file 0b00001100 for fuse6/syscfg1
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse6/syscfg1 ...
avrdude: 1 byte of fuse6/syscfg1 written
avrdude: verifying fuse6/syscfg1 memory against 0b00001100
avrdude: 1 byte of fuse6/syscfg1 verified
avrdude: reading input file 0x01 for fuse8/bootsize
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse8/bootsize ...
avrdude: 1 byte of fuse8/bootsize written
avrdude: verifying fuse8/bootsize memory against 0x01
avrdude: 1 byte of fuse8/bootsize verified
avrdude: reading input file 0x00 for fuse7/codesize
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse7/codesize ...
avrdude: 1 byte of fuse7/codesize written
avrdude: verifying fuse7/codesize memory against 0x00
avrdude: 1 byte of fuse7/codesize verified
avrdude: reading input file C:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.4.10/bootloaders/hex/optiboot_64dd_ser0_alt3_all_8sec.hex for flash
         with 488 bytes in 2 sections within [0, 0x1ff]
         using 1 page and 24 pad bytes
avrdude: writing 488 bytes flash ...

Writing | ################################################## | 100% 0.16s

avrdude: 488 bytes of flash written
avrdude: verifying flash memory against C:\Users\xiaof\AppData\Local\Arduino15\packages\DxCore\hardware\megaavr\1.4.10/bootloaders/hex/optiboot_64dd_ser0_alt3_all_8sec.hex

Reading | ################################################## | 100% 0.09s

avrdude: 488 bytes of flash verified

avrdude done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM5 -p avr64dd32  -xbootsize=512 -U '.\Blink_64dd32.ino.avr64dd32opti.24c0.m{build.highestcb}.wO.v151.hex'

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961a (probably avr64dd32)
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 .\Blink_64dd32.ino.avr64dd32opti.24c0.m{build.highestcb}.wO.v151.hex for flash
         with 816 bytes in 1 section within [0x200, 0x52f]
         using 2 pages and 208 pad bytes
avrdude: preparing flash input for device bootloader
avrdude: writing 816 bytes flash ...

Writing | ################################################## | 100% 0.16 s

avrdude: 816 bytes of flash written
avrdude: verifying flash memory against .\Blink_64dd32.ino.avr64dd32opti.24c0.m{build.highestcb}.wO.v151.hex

Reading | ################################################## | 100% 0.11 s

avrdude: 816 bytes of flash verified

avrdude done.  Thank you.

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

avrdude: AVR device initialized and ready to accept instructions
0 2022-12-25 20.13 Blink_64dd32.ino.avr64dd32opti.24c0.m{build.highestcb}.wO.v151.hex 1328 store 64130 meta 78 boot 512 x0.0 ......... vector 0 (RESET) AVR64DD32

Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino

703ecd2

stefanrueger mentioned this pull request Oct 20, 2022

[Regression] Optiboot for "modern AVRs" does not work with upstream version of Avrdude. #1120

Closed

mcuee added bug Something isn't working enhancement New feature or request labels Oct 20, 2022

stefanrueger mentioned this pull request Oct 21, 2022

Always use paged access for programmers that serve bootloaders #1141

Merged

stefanrueger added 3 commits October 21, 2022 11:51

Load ext addr for stk500v1 bootloaders after grazing 64k boundaries

95cbfc1

Fix typo in stk500.c comment

2d6ec9e

Change wording of justification for sending ext byte at 64k boundary

ff7628c

stefanrueger added 2 commits October 21, 2022 12:25

Rectify precedence in condition in stk500.c

ec5a33f

Really fix precedence in condition in stk500.c

41a612a

Reformulate justification for sending ext byte at 64k boundary

89c44d0

This was referenced Oct 22, 2022

Support AVR-D series. Optiboot/optiboot#294

Open

optiboot_x fails for >48k of flash (ie xTiny, AVRDx64, AVRDx128) Optiboot/optiboot#353

Open

avrdude has EEPROM bug Optiboot/optiboot#235

Open

stefanrueger linked an issue Oct 22, 2022 that may be closed by this pull request

[Regression] Optiboot for "modern AVRs" does not work with upstream version of Avrdude. #1120

Closed

Fix bootloader stk500v1 EEPROM r/w for classic parts with page size 1

0b8a12a

stefanrueger merged commit baaad71 into avrdudes:main Oct 23, 2022

stefanrueger deleted the arduino branch October 23, 2022 21:32

This was referenced Nov 1, 2022

To check whether optiboot_dx is working with avrdude for <=64KB AVR DA/DB parts #1165

Closed

megaTinyCore optiboot_x issue with avrdude git main -- FALSE ALARM #1166

Closed

Menu options wrong for AVR DD parts SpenceKonde/DxCore#360

Closed

mcuee mentioned this pull request Dec 27, 2023

Force STK500 EEPROM paged r/w for bootloaders #1602

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino #1140

Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino #1140

stefanrueger commented Oct 20, 2022

mcuee commented Oct 21, 2022 •

edited

Loading

stefanrueger commented Oct 21, 2022 •

edited

Loading

SpenceKonde commented Oct 21, 2022 •

edited

Loading

mcuee commented Oct 21, 2022

mcuee commented Oct 21, 2022

mcuee commented Oct 21, 2022 •

edited

Loading

mcuee commented Oct 21, 2022 •

edited

Loading

stefanrueger commented Oct 21, 2022

stefanrueger commented Oct 21, 2022

MCUdude commented Oct 22, 2022

mcuee commented Oct 23, 2022 •

edited

Loading

mcuee commented Oct 23, 2022 •

edited

Loading

MCUdude commented Oct 23, 2022

stefanrueger commented Oct 23, 2022 •

edited

Loading

MCUdude commented Oct 23, 2022

MCUdude commented Oct 23, 2022

mcuee commented Oct 28, 2022 •

edited

Loading

mcuee commented Oct 28, 2022

mcuee commented Oct 31, 2022

SpenceKonde commented Oct 31, 2022

SpenceKonde commented Oct 31, 2022

SpenceKonde commented Nov 12, 2022

MCUdude commented Nov 12, 2022 •

edited

Loading

mcuee commented Dec 25, 2022

	programmer
	id = "arduino";
	desc = "Arduino for bootloader using STK500 v1 protocol";
	type = "arduino";
	prog_modes = PM_SPM;
	connection_type = serial;
	;

Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino #1140

Support optiboot, optiboot_dx and optiboot_x bootloaders for -c arduino #1140

Conversation

stefanrueger commented Oct 20, 2022

mcuee commented Oct 21, 2022 • edited Loading

stefanrueger commented Oct 21, 2022 • edited Loading

SpenceKonde commented Oct 21, 2022 • edited Loading

mcuee commented Oct 21, 2022

mcuee commented Oct 21, 2022

mcuee commented Oct 21, 2022 • edited Loading

mcuee commented Oct 21, 2022 • edited Loading

stefanrueger commented Oct 21, 2022

stefanrueger commented Oct 21, 2022

MCUdude commented Oct 22, 2022

mcuee commented Oct 23, 2022 • edited Loading

mcuee commented Oct 23, 2022 • edited Loading

MCUdude commented Oct 23, 2022

stefanrueger commented Oct 23, 2022 • edited Loading

MCUdude commented Oct 23, 2022

MCUdude commented Oct 23, 2022

mcuee commented Oct 28, 2022 • edited Loading

mcuee commented Oct 28, 2022

mcuee commented Oct 31, 2022

SpenceKonde commented Oct 31, 2022

SpenceKonde commented Oct 31, 2022

SpenceKonde commented Nov 12, 2022

MCUdude commented Nov 12, 2022 • edited Loading

mcuee commented Dec 25, 2022

mcuee commented Oct 21, 2022 •

edited

Loading

stefanrueger commented Oct 21, 2022 •

edited

Loading

SpenceKonde commented Oct 21, 2022 •

edited

Loading

mcuee commented Oct 21, 2022 •

edited

Loading

mcuee commented Oct 21, 2022 •

edited

Loading

mcuee commented Oct 23, 2022 •

edited

Loading

mcuee commented Oct 23, 2022 •

edited

Loading

stefanrueger commented Oct 23, 2022 •

edited

Loading

mcuee commented Oct 28, 2022 •

edited

Loading

MCUdude commented Nov 12, 2022 •

edited

Loading