Closed MCUdude closed 1 year ago
This seems to indicate that optiboot_x is not exactly the same as vanilla optiboot, or maybe it is due to the different memory configuration of the new AVR tiny 0/1/2 part. I am not so sure how to fix this.
One easy solution is to create a new bootloader type optiboot_x
as arduino
seems to include too many bootloaders with potential different implementations. I am also thinking that we need to the function to be able to define the capability of the bootloaders.
Maybe @stefanrueger has a better idea to differentiate the bootloader implementation.
Detailed explanation from @SpenceKonde
Not surprised this broke my forks of Optiboot when someone fiddled with it (was that change made to address a complaint?). Arguably the hardest part of porting optiboot to Dx-series parts was figuring out to get AVRdude to use the correct addressing modes. Everything else was relatively straightforward. But DA and DB can have 128k parts. AVRdude uses byte addresses talking to optiboot_x for the tinyAVR parts, while I used a weird trick to fool it into using word addressing for the AVR128Dx parts (see my avrdude.conf from DxCore). If there's a better way that will work with both 6.3 and future 7.x versions please let me know (based on experience, it must be backwards compatible - I can change what's in the avrdude.conf to make it work with whatever new version - or ideally both versions, but I can't say "Yeah from here on out you need a new bootloader binary", people make an unholy stink*) but shrug that was the trick I found to make it work on 6.3 (haven't tested 7.0 - I'm not allowed to look at that until both megaTinyCore and DxCore have stable releases)
*
especially the ones who are using tinyAVRs with the updi pin fused to act as reset or I/O and who don't own an HVUPDI programmer (virtually nobody does HV updi. most of microchip's programmers don't even support it as implemented on tinyAVR (and small wonder: you need to have a line at 12v, then go back to sending normal data over it. Even microchip retreated from the shared HV pulse + data line concept on the DD's! So there are two HV UPDI's now :-( The DD's put the pulse on reset, which can be fused as input, but never output (reset sucks when used as output anyway - sub-milliamp current? screw that) and if UPDI is fused as GPIO, then a 12V pulse on reset followed rapidly by a KEY on the (now once more) UPDI line is what you need to do to reprogram it. On a tinyAVR, instead, you power-cycle it, almost immediately put the 12v pulse on the UPDI/Reset/GPIO line... there may or may not be a timeout that you have to send that KEY within on some parts; certainly some parts don't, because multiple people have told me they do it with 12v doorbell batteries and nerves of steel),
Not surprised this broke my forks of Optiboot when someone fiddled with it (was that change made to address a complaint?).
Indeed that change https://github.com/avrdudes/avrdude/commit/3d06457a1614a2247efc846b8e73788cb8585978 is because of a long standing bug that typical optiboot implemnetation does not follow the stk500v1 exactly.
There were three options to go as per @stefanrueger and in the end the team aligned and went with Option 1 as the Real STK500v1 is dead. Unfortunately optiboot_x got affected because of the change.
Deprecate the "pure" STK500 v1 support and change above code to simply a_div = 2 (accept that the STK500 kit with FW version 1.xx is a dead horse)
Create a new AVRDUDE programmer stk500v1w that imports the stk500 (v1) programmer and change paged access to be always through word addresses. Modify .conf for these programmers to be based on stk200v1w
Change all STK500 derived programmers to swap out their paged memory access functions
Hm, that problem is about EEPROM, but this bug is reported when uploading to flash. That's the one thing I don't understand here. Why does a change to eeprom impact flash writes?
Hm, that problem is about EEPROM, but this bug is reported when uploading to flash. That's the one thing I don't understand here. Why does a change to eeprom impact flash writes?
Good point. Maybe @MCUdude and @stefanrueger can help here.
If you look closely at the https://github.com/avrdudes/avrdude/commit/3d06457a1614a2247efc846b8e73788cb8585978 diff, you can see that a_div=2;
is added to both flash and EEPROM for stk500_paged_load()
and stk500_paged_write()
@SpenceKonde I see two solutions (there may be more)
We create a different programmer arduino_x
or optiboot_x
that sends word or byte addresses just like the arduino
programmer did before. (Given all the different bootloaders and derivative programmers it seems pretty much impossible to satisfy every use case with one programmer).
You tell us which byte/word addressing you'd need for which parts and which memories and which access modes (paged or byte-wise), and I look into whether/how that can be implemented in a bespoke optiboot_x
programmer that hopefully doesn't need avrdude.conf
juggling (you mentioned a "weird trick").
Another possibility without need for a new arduino
type programmer would be to treat PDI/UPDI parts differently (assuming that the optiboot_x
extension is just for XMEGAs or newer parts with UPDI i/f). That could be done within the current arduino programmer. Still, when doing so, would better address what's needed for the _x
extension w/out private avrdude.conf
manipulations.
It suddenly hit me, @SpenceKonde Optiboot X fork uses the exact same codebase as my own (originally written by @westfw). This mean that this bug also should affect the megaAVR-0 series (ATmega808/809/1608/1609/3208/3209/4808/4809). And in fact, it does!
This means that all Optiboot bootloaders + forks for "modern" AVRs are using a_div=1
.
$ ./avrdude -carduino -P /dev/cu.usbserial-1410 -patmega4808 -D -Uflash:w:/var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_148565/Blink.ino.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9650 (probably m4808)
avrdude: reading input file /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_148565/Blink.ino.hex for flash
with 768 bytes in 1 section within [0x200, 0x4ff]
using 6 pages and 0 pad bytes
avrdude: writing 768 bytes flash ...
Writing | ################################################## | 100% 0.04s
avrdude: 768 bytes of flash written
avrdude: verifying flash memory against /var/folders/6l/ypg6qbw172v1s4vtt6g990tw0000gn/T/arduino_build_148565/Blink.ino.hex
Reading | ################################################## | 100% 0.03s
avrdude: verification error, first mismatch at byte 0x0200
0xd0 != 0x47
avrdude: verification error; content mismatch
avrdude done. Thank you.
In that case, optiboot_dx for AVR128DA should be fine
But optiboot_dx for AVR64Dx isn't.
The incantation i have in my avrdude.conf is this:
memory "flash"
size = 0x20000;
offset = 0x800000;
page_size = 0x200;
readsize = 0x100;
load_ext_addr = " 0 1 0 0 1 1 0 1",
" 0 0 0 0 0 0 0 0",
" 0 0 0 0 0 0 0 a16",
" 0 0 0 0 0 0 0 0";
;
Its the load_ext_addr that makes it do adiv = 2 currently it seems.
(Note also that readsize could be up to 0x200, but it is capped artificially by avrdude to 0x100)
@MCUdude and @SpenceKonde OK, so rather than putting into avrdude.conf
parameters that are for classic AVRs (readsize
is for ISP STK500/STK600, and ISP commands are, well, for the ISP i/f), can I suggest you express which bootloaders expect which type of address for which devices? Ideally dependent on memory type (flash/eeprom/...), interface, memory size, eg,
i/f | memory | size | a_div |
---|---|---|---|
UPDI | flash | >64k | 2 |
UPDI | flash | <=64k | 1 |
UPDI | eeprom | all | 1 |
PDI | flash | all | 1 |
PDI | eeprom | all | 1 |
Clearly, I have been making this table up, but it's much neater if the code expresses what your bootloaders expect rather than resorting to avrdude.conf trickery.
@stefanrueger I can't speak for AVR-Dx'es, but for megaAVR-0's it's supposed to be a_div=1
for both flash and EEPROM.
OK, so, let's wait and hear from @SpenceKonde when his bootloaders need a_div=2
- I assume that's only needed for flash with memory size exceeding 64k and up to 128k and including that. I wonder what people do for ATxmega devices with flash that exceeds 128k?
$ avrdude -p*/d | grep PDI | awk '{ if(strtonum($7) > 2*65536) print; }'
'ATxmega128C3' => [0x1E, 0x97, 0x52, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 11942
'ATxmega128D3' => [0x1E, 0x97, 0x48, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 11997
'ATxmega128D4' => [0x1E, 0x97, 0x47, 0x00800000, 0x22000, 0x100, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12009
'ATxmega128A1' => [0x1E, 0x97, 0x4C, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12025
'ATxmega128A1revD' => [0x1E, 0x97, 0x41, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12043
'ATxmega128A1U' => [0x1E, 0x97, 0x4C, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12054
'ATxmega128A3' => [0x1E, 0x97, 0x42, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12066
'ATxmega128A3U' => [0x1E, 0x97, 0x42, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12078
'ATxmega128A4' => [0x1E, 0x97, 0x46, 0x00800000, 0x22000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12091
'ATxmega128A4U' => [0x1E, 0x97, 0x46, 0x00800000, 0x22000, 0x100, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12150
'ATxmega128B1' => [0x1E, 0x97, 0x4D, 0x00800000, 0x22000, 0x100, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12205
'ATxmega128B3' => [0x1E, 0x97, 0x4B, 0x00800000, 0x22000, 0x100, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12266
'ATxmega192C3' => [0x1E, 0x97, 0x51, 0x00800000, 0x32000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12279
'ATxmega192D3' => [0x1E, 0x97, 0x49, 0x00800000, 0x32000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12334
'ATxmega192A1' => [0x1E, 0x97, 0x4E, 0x00800000, 0x32000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12346
'ATxmega192A3' => [0x1E, 0x97, 0x44, 0x00800000, 0x32000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12363
'ATxmega192A3U' => [0x1E, 0x97, 0x44, 0x00800000, 0x32000, 0x200, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12375
'ATxmega256C3' => [0x1E, 0x98, 0x46, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12387
'ATxmega256D3' => [0x1E, 0x98, 0x44, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12442
'ATxmega256A1' => [0x1E, 0x98, 0x46, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12454
'ATxmega256A3' => [0x1E, 0x98, 0x42, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12470
'ATxmega256A3U' => [0x1E, 0x98, 0x42, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12482
'ATxmega256A3B' => [0x1E, 0x98, 0x43, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12494
'ATxmega256A3BU' => [0x1E, 0x98, 0x43, 0x00800000, 0x42000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_XMEGAJTAG'], # /usr/local/etc/avrdude.conf 12506
'ATxmega384C3' => [0x1E, 0x98, 0x45, 0x00800000, 0x62000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12518
'ATxmega384D3' => [0x1E, 0x98, 0x47, 0x00800000, 0x62000, 0x200, 0x8c0000, 0x1000, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI'], # /usr/local/etc/avrdude.conf 12573
Do bootloaders for these devices expect the ISP command for load extended address?
My test results with optiboot_dx for avr128db48. There is a problem with EEPROM. I will test Flash later.
With current code, the optiboot_dx will fail using PR #1110.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1110v1 -c arduino -P COM6 -b 115200 -p avr128db48
-qq -U eeprom:w:.\hex2\entest.eep && echo OK
avrdude_pr1110v1.exe: verification error, first mismatch at byte 0x0001
0x54 != 0x68
avrdude_pr1110v1.exe: verification error; content mismatch
But with a_div = 1
, it will work with PR #1110.
PS C:\work\avr\avrdude_test\avrdude_sr> git diff
diff --git a/src/stk500.c b/src/stk500.c
index 8966747..43e5111 100644
--- a/src/stk500.c
+++ b/src/stk500.c
@@ -793,7 +793,7 @@ static int stk500_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AVR
* 2000s. Since optiboot, arduino as ISP and others assume a_div = 2,
* better use that. See https://github.com/avrdudes/avrdude/issues/967
*/
- a_div = 2;
+ a_div = 1;
} else {
return -2;
}
@@ -888,7 +888,7 @@ static int stk500_paged_load(const PROGRAMMER *pgm, const AVRPART *p, const AVRM
* 2000s. Since optiboot, arduino as ISP and others assume a_div = 2,
* better use that. See https://github.com/avrdudes/avrdude/issues/967
*/
- a_div = 2;
+ a_div = 1;
} else {
return -2;
}
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1110v1mod -c arduino -P COM6 -b 115200
-p avr128db48 -qq -U eeprom:w:.\hex2\entest.eep && echo OK
OK
It looks like the root optiboot_x (https://github.com/Optiboot/optiboot) assumes byte-addressable flash, and also that all of flash is mapped into the RAM address space.
That probably means that optiboot_x won't work on chips with more than 48k of FLASH (it was originally written for ATmega4809) or with chips that don't/can't map all of their flash at once (if there are any.) (except for "short" programs, I guess.)
@MCUdude and @SpenceKonde code seems to be the same code.
That rather sucks :-(
optiboot assumes that both flash and eeprom are word-addressed, while optiboot_x assumes that both are byte addressed. Sigh.
else if(ch == STK_LOAD_ADDRESS) {
// LOAD ADDRESS
address.bytes[0] = getch();
address.bytes[1] = getch();
// ToDo: will there be mega-0 chips with >128k of RAM?
/* UPDI chips apparently have byte-addressable FLASH ?
address.word *= 2; // Convert from word address to byte address
*/
Indeed optiboot_x and optiboot_dx codes seem to be the same. https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/bootloaders/optiboot_x/optiboot_x.c https://github.com/MCUdude/MegaCoreX/blob/master/megaavr/bootloaders/optiboot/optiboot_x.c https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/optiboot_dx/optiboot_dx.c
I wonder what people do for ATxmega devices with flash that exceeds 128k?
Do bootloaders for these devices expect the ISP command for load extended address?
@stefanrueger optiboot_dx does deal with extended address. https://github.com/SpenceKonde/DxCore/blob/master/megaavr/bootloaders/optiboot_dx/optiboot_dx.c#L535-L543
is a_div determined from the chip type, or a combination of chip and programmer? Certainly it's much more important at the moment that the chips be programmable with the various actual hardware UPDI programmers (and especially the official ones) than with optiboot_x
optiboot assumes that both flash and eeprom are word-addressed
@WestfW That's OK for eeprom with a page size hat exceeds 1. Turns out newer parts with UPDI
i/f and some older parts (ATmega161 ATmega163 ATmega8515 ATmega8535 ...) have an eeprom page size of 1, which out of necessity fail when trying to use word addresses for their pages.
@SpenceKonde I can certainly put code in stk500.c
that recognises that it services a bootloader for parts with PDI/UPDI interfaces and tries to figure out whether to send byte or word addresses.
Of course, the proper physical STK500 programmer (for which stk500.c was originally written) only handles classic AVR parts and has long since been upgraded to v2 firmware. Nevertheless, happy to "upgrade" the old and venerable stk500.c code to the vagaries of various bootloaders that latch onto this protocol.
Of course, the proper physical STK500 programmer (for which stk500.c was originally written) only handles classic AVR parts and has long since been upgraded to v2 firmware. Nevertheless, happy to "upgrade" the old and venerable stk500.c code to the vagaries of various bootloaders that latch onto this protocol.
@stefanrueger
When you are at it (upgraing stk500.c code to the bootloaders and things like "Arduino as ISP" programmer), probably you can consider removing the old codes only for the real STK500 hardware programmer.
is a_div determined from the chip type, or a combination of chip and programmer? Certainly it's much more important at the moment that the chips be programmable with the various actual hardware UPDI programmers (and especially the official ones) than with optiboot_x
We are talking about stk500.c here. The real STK500 only deals with classic AVRs and the V1 FW has been been obsoleted and replaced by V2 FW back in 2006. So we are not talking about any hardware UPDI programmers here.
The hardware UPDI programmers will still work as we are not changing the avrdude.conf parts definitions of the new AVR chips targeted by optiboot_x and optiboot_dx. Rather the change should be in stk500.c (or a new file -- which does not seem to be necessary now).
My test results with optiboot_dx for avr128db48. There is a problem with EEPROM. I will test Flash later.
DxCore apparently works, but only for the first upload -- the LED blinking works fine as well. The second time it will fail to load.
I am not so sure if this is because of the 8s non-auto-reset problem. I am using Microchip AVR128DB48 Curiosity Nano evaluation board.
But avrdude git main will not even work for one time (flash the bootloader again).
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM6 -b 115200 -p avr128db48
-U .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
avrdude_git.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude_git.exe: Device signature = 0x1e970c (probably avr128db48)
avrdude_git.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude_git.exe: erasing chip
avrdude_git.exe: chip erase instruction not defined for part "AVR128DB48"
avrdude_git.exe done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM6 -b 115200 -p avr128db48
-D -U .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
avrdude_git.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude_git.exe: Device signature = 0x1e970c (probably avr128db48)
avrdude_git.exe: reading input file .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex for flash
with 1040 bytes in 1 section within [0x200, 0x60f]
using 3 pages and 496 pad bytes
avrdude_git.exe: writing 1040 bytes flash ...
Writing | ################################################## | 100% 0.16s
avrdude_git.exe: 1040 bytes of flash written
avrdude_git.exe: verifying flash memory against .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
Reading | ################################################## | 100% 0.12s
avrdude_git.exe: verification error, first mismatch at byte 0x0200
0xa9 != 0x79
avrdude_git.exe: verification error; content mismatch
avrdude_git.exe done. Thank you.
avrdude 7.0 release works fine for one time. So this is inline with @MCUdude's result, there is a regression here for flash.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C avrdude7.conf -c arduino -P COM6 -b 115200 -p avr128db48
-D -U .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
avrdude7.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude7.exe: Device signature = 0x1e970c (probably avr128db48)
avrdude7.exe: reading input file ".\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex"
avrdude7.exe: input file .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex auto detected as Intel Hex
avrdude7.exe: writing flash (1552 bytes):
Writing | ################################################## | 100% 0.17s
avrdude7.exe: 1552 bytes of flash written
avrdude7.exe: verifying flash memory against .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex:
avrdude7.exe: input file .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex auto detected as Intel Hex
Reading | ################################################## | 100% 0.12s
avrdude7.exe: 1552 bytes of flash verified
avrdude7.exe done. Thank you.
Somehow the PR #1110 EEPROM mod no longer works. I have no idea why. Apparently it does nothing (still read as 0xff).
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1110v1mod.exe -c arduino -P COM6 -b 115200 -p avr128db48
-U eeprom:w:.\hex2\entest.hex:i
avrdude_pr1110v1mod.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude_pr1110v1mod.exe: Device signature = 0x1e970c (probably avr128db48)
avrdude_pr1110v1mod.exe: reading input file .\hex2\entest.hex for eeprom
avrdude_pr1110v1mod.exe: writing 512 bytes eeprom ...
Writing | ################################################## | 100% 12.29s
avrdude_pr1110v1mod.exe: 512 bytes of eeprom written
avrdude_pr1110v1mod.exe: verifying eeprom memory against .\hex2\entest.hex
Reading | ################################################## | 100% 12.28s
avrdude_pr1110v1mod.exe: verification error, first mismatch at byte 0x0000
0xff != 0x54
avrdude_pr1110v1mod.exe: verification error; content mismatch
avrdude_pr1110v1mod.exe done. Thank you.
Once I change a_div = 1
for flash, then avrdude seems to work with flash write for optiboot, same as avrdude 7.0 release. So again, this is in line with analysis done here by @MCUdude and @stefanrueger.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1110v1mod2 -c arduino -P COM6 -b 115200
-p avr128db48 -D -U .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
avrdude_pr1110v1mod2.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude_pr1110v1mod2.exe: Device signature = 0x1e970c (probably avr128db48)
avrdude_pr1110v1mod2.exe: reading input file .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex for flash
with 1040 bytes in 1 section within [0x200, 0x60f]
using 3 pages and 496 pad bytes
avrdude_pr1110v1mod2.exe: writing 1040 bytes flash ...
Writing | ################################################## | 100% 0.17s
avrdude_pr1110v1mod2.exe: 1040 bytes of flash written
avrdude_pr1110v1mod2.exe: verifying flash memory against .\hex2\Blink.ino.avr128db48opti.16c1.mB2.wO.v1410.hex
Reading | ################################################## | 100% 0.13s
avrdude_pr1110v1mod2.exe: 1040 bytes of flash verified
avrdude_pr1110v1mod2.exe done. Thank you.
I wonder what people do for ATxmega devices with flash that exceeds 128k? ... Do bootloaders for these devices expect the ISP command for load extended address?
@stefanrueger It seems to me Arduino and optiboot booloader is not so popular among ATxmega devices. Rather avr109 ( using xboot) is more popular. And you and @MCUdude have helped fixed the issue with ATxmega devices with flash that exceeds 128KB in #1101 recently.
There is an Arduino implementation here. The bootloader is using either CATERINA (USB variant of AVR109) or STK500v2. It seems to support extended address. I do not have the facility to test them as of now. I am not so sure if @MCUdude can test them or not. https://github.com/XMegaForArduino/arduino https://github.com/XMegaForArduino/arduino/tree/master/bootloaders/xmega
It is a pity that my Arduino Nano Every (official board using ATmega4809)) and Nano 4808 clone (using ATmega4808) do not support bootloader. My ATtiny817 Curiosity Nano is also not a good board to work with bootloaders due to all kinds of limitation.
The only board I have for UPDI AVR is the AVR128DB48 Curiosity Nano board -- it is supposed to work with optiboot_dx but somehow it is also not working very well.
@mcuee send me an email, and I'll see if I can get you some more convenient hardware for testing.
There is an Arduino implementation here. The bootloader is using either CATERINA (USB variant of AVR109) or STK500v2. It seems to support extended address. I do not have the facility to test them as of now. I am not so sure if @MCUdude can test them or not. https://github.com/XMegaForArduino/arduino https://github.com/XMegaForArduino/arduino/tree/master/bootloaders/xmega
I currently only have an ATxmega128A3U and an ATmega256A3BU I can test with, but I'll look into it.
It is a pity that my Arduino Nano Every (official board using ATmega4809)) and Nano 4808 clone (using ATmega4808) do not support bootloader. My ATtiny817 Curiosity Nano is also not a good board to work with bootloaders due to all kinds of limitation.
When working with bootloaders, I usually break the Rx/Tx lies from the MCU to the debugger chip, and instead wire up a dedicated USB to serial adapter. It appears to be more reliable for bootloader use at least.
By the way, terminal mode does not seem to be affected by this issue for optiboot_dx.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM6 -b 115200 -p avr128db48 -qq -t
avrdude> dump flash 0x1000 0x10
>>> dump flash 0x1000 0x10
1000 ff ff aa 55 ff ff ff ff ff ff ff ff ff ff ff ff |...U............|
avrdude> write flash 0x1000 0x55 0xaa 0x55 0xaa
>>> write flash 0x1000 0x55 0xaa 0x55 0xaa
avrdude> flush
>>> flush
avrdude_git.exe: synching cache to device... done
avrdude> dump flash 0x1000 0x10
>>> dump flash 0x1000 0x10
1000 55 aa 55 aa ff ff ff ff ff ff ff ff ff ff ff ff |U.U.............|
avrdude> quit
>>> quit
I can also get you AVR Dx boards with Optiboot-dx and Optiboot-x on them - just email me if you still need (if you're in US, it's easier and faster to get from me, whereas (assuming he has Dx-series boards) MCUdude can get them to you faster if you're in europe.
You can also use the curiosity nano with bootloader on a different set of pins, by selecting NEDBG as programmer, AVR128DA/DB48 with Optiboot as chip (instead of the Microchip board def), and then bootloading, just specify serial pins that you can connect to an external serial adapter, and either manually press reset or wire up an autoreset circuit - I don't think anything keeps it from autoresetting there.
I'd probably send you like... a AVR128DB64, tinyAVR 1624 or 3224 on a rev C (no working LED) PCB, and maybe something with a double D on it to see the differences between large and small memory Dx's - they aren't the same. If I can't get a credible DD available, it'd just be like a AVR64DD48 or something.
Rather than sending h/w, better for me to know what you'd expect from the arduino
programmer to send.
@WestfW and @SpenceKonde: are the chip sets that your respective bootloaders deal with mutually exclusive? If so, we can make arduino work with all of your requests: |
Parts | memory | size | a_div |
---|---|---|---|---|
UPDI-chips (optiboot-dx) | flash | >64k | 2 | |
UPDI-chips (optiboot-dx) | flash | <=64k | 1 | |
UPDI-chips (optiboot-dx) | eeprom | all | 1 | |
PDI-chips (??) | flash | all | 1 | |
PDI-chips (??) | eeprom | all | 1 | |
ISP-chips (optiboot) | flash | all | 2 | |
ISP-chips (optiboot) | eeprom | all | 2 |
For all devices I would send the load_ext_addr command as SPI extension when needed (ie, when flash has more than 128k memory then it's sent once at the beginning and every time the programmer jumps from one section to the other) irrespective of any ISP commands that are mentioned for that part in avrdude.conf
. AVRDUDE has recently introduced a pgm->prog_mode
variable that is set to PM_SPM
programming (ie, bootloader support) for -c arduino
, so the underlying stk500v1
programmer knows the comms is for bootloaders and just needs to consider the expected protocol.
Does that plan work out?
If there are parts that are served by two or more of optiboot, optiboot-dx and optiboot-x and the different bootloaders require a different treatment for the same part then we will need to create another programmer in AVRDUDE as @mcuee has suggested. Not a biggie, but I'd need to know how you want the flash/eeprom addresses served.
If above table is too big a simplification, please feel free to create one that reflects your respective bootloaders.
DxCore apparently works, but only for the first upload -- the LED blinking works fine as well. The second time it will fail to load.
I am not so sure if this is because of the 8s non-auto-reset problem. I am using Microchip AVR128DB48 Curiosity Nano evaluation board.
@SpenceKonde The 8s delay does work for the optiboot_dx. I need to be fast since Windows will pop up with the mass storage thingy for my AVR128DB48 Curiosity Nano board. I need to close that Windows and enter the bootloader.
There is a strange verification error message for large hex file for avrdude 7.0 release and the 6.3 version bundled with DxCore. I am not so sure about the reason. But verification later using the onboard pkobn_updi shows flash writing is correct.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200 -p avr128db48
-qq -D -U .\hex2\hexaa64KB_with_blink.hex && echo OK
avrdude7.exe: verification error, first mismatch at byte 0x0200
0xff != 0x79
avrdude7.exe: verification error; content mismatch
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200 -p avr128db48
-qq -D -U flash:v:.\hex2\hexaa64KB_with_blink.hex && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c pkobn_updi -p avr128db48 -qq
-D -U flash:v:.\hex2\hexaa64KB_with_blink.hex && echo OK
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK
Same result for the avrdude 6.3 version bundled with DxCore.
PS C:\work\avr\avrdude_test\avrdude_bin\bin_misc\6.3.0-arduino17or18\bin> .\avrdude -C ..\etc\avrdude.conf
-c arduino -P COM6 -b 115200 -p avr128db48 -qq -D -U hexaa64KB_with_blink.hex && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0200
0xff != 0x79
avrdude.exe: verification error; content mismatch
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq -D
-U flash:v:.\hex2\hexaa64KB_with_blink.hex:i && echo OK
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK
There is no such warning message with just the blink hex file.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200
-p avr128db48 -qq -D -U .\hex2\optiboot_dx_avr128db48_uart3_8s_blink.hex && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq
-U flash:v:.\hex2\optiboot_dx_avr128db48_uart3_8s.hex:i && echo OK
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK
Ref:
Test hex file: 64KB hex file with 0xaa, but the first part are replaced with the blink hex file from DxCore (where the first 512B are skipped as 512B is reserved for the bootloader). hexaa64KB_with_blink.zip
Once I use the following quick mode (to make all a_div =1), git main will also work as avrdude 7.0 release.
PS C:\work\avr\avrdude_test\avrdude_main> git diff
diff --git a/src/stk500.c b/src/stk500.c
index 8966747..bc0d80c 100644
--- a/src/stk500.c
+++ b/src/stk500.c
@@ -784,7 +784,7 @@ static int stk500_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AVR
if (strcmp(m->desc, "flash") == 0) {
memtype = 'F';
- a_div = 2;
+ a_div = 1;
} else if (strcmp(m->desc, "eeprom") == 0) {
memtype = 'E';
/*
@@ -793,7 +793,7 @@ static int stk500_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AVR
* 2000s. Since optiboot, arduino as ISP and others assume a_div = 2,
* better use that. See https://github.com/avrdudes/avrdude/issues/967
*/
- a_div = 2;
+ a_div = 1;
} else {
return -2;
}
@@ -879,7 +879,7 @@ static int stk500_paged_load(const PROGRAMMER *pgm, const AVRPART *p, const AVRM
if (strcmp(m->desc, "flash") == 0) {
memtype = 'F';
- a_div = 2;
+ a_div = 1;
} else if (strcmp(m->desc, "eeprom") == 0) {
memtype = 'E';
/*
@@ -888,7 +888,7 @@ static int stk500_paged_load(const PROGRAMMER *pgm, const AVRPART *p, const AVRM
* 2000s. Since optiboot, arduino as ISP and others assume a_div = 2,
* better use that. See https://github.com/avrdudes/avrdude/issues/967
*/
- a_div = 2;
+ a_div = 1;
} else {
return -2;
}
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git_mod -c arduino -P COM6 -b 115200 -p avr128db48
-qq -D -U .\hex2\optiboot_dx_avr128db48_uart3_8s_blink.hex && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git_mod -c pkobn_updi -p avr128db48 -qq -D
-U flash:v:.\hex2\optiboot_dx_avr128db48_uart3_8s_blink.hex && echo OK
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git_mod -c arduino -P COM6 -b 115200 -p avr128db48 -qq
-D -U .\hex2\hexaa64KB_with_blink.hex && echo OK
avrdude_git_mod.exe: verification error, first mismatch at byte 0x0200
0xff != 0x79
avrdude_git_mod.exe: verification error; content mismatch
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git_mod -c pkobn_updi -p avr128db48 -qq -D
-U flash:v:.\hex2\hexaa64KB_with_blink.hex && echo OK
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
OK
This is my best guess based on the results from @MCUdude and my own test results. And we do not need to worry about ATxmega parts as the popular bootloader there is based on AVR109 (eg: xboot and caterina), flip2 and STK500v2 ( https://github.com/XMegaForArduino/arduino/blob/master/bootloaders/xmega/xmegaBOOT.c). I have not seen any optiboot implementation for ATxmega part.
Note: all the current parts supported by optiboot_x (megaTinyCore and MegaCoreX) have flash size not greater than 64KB.
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@WestfW, @SpenceKonde and @MCUdude, please review the above.
One thing not so clear is for the whether a_div = 1
or a_div =2
for optiboot_dx with AVR Dx parts with 64KB or less Flash. I tend to believe it is a_div =1
as well but I am not sure.
@mcuee I don't have any AVR-Dx's with less than 128kiB flash, so I'm not able able to help out figuring out the last unknown a_div
. @SpenceKonde probably has though.
@mcuee I don't have any AVR-Dx's with less than 128kiB flash, so I'm not able able to help out figuring out the last unknown
a_div
. @SpenceKonde probably has though.
@MCUdude I was trying to order bare AVR DD chips from Taobao but unfortunately they are all out of stock. In the end, I just ordered AVR64DD32 Curiosity Nano board from Mouser Singapore. I should be able to get it within two weeks.
BTW, Mouse Singapore does have DIP version of AVR64DD28-I/SP part at reasonable price (S$4.72/pc or US$3.33/pc), but then the shipping cost is high at S$25 (about US$17.62) so it is not really worth to buy the bare chips. The development tools will usually have free shipment so the board costs S$32.35 (about US$22.80).
the last unknown a_div
I am guessing this must be 1. Please look at PR #1140 that implements what I believe to be a solution to this issue.
Let's continue the discussion in #1165.
(Probably) related to #1090.
I'm able to upload programs to an ATtiny1616 using optiboot (-c arduino) with Avrdude 6.0 and 7.0, but not the upstream version. I've tracked down the issue to commit https://github.com/avrdudes/avrdude/commit/3d06457a1614a2247efc846b8e73788cb8585978.
The bootloader source code is located here: https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/bootloaders/optiboot_x
Here's Avrdude output.
Avrdude 6.3:
Avrdude 7.0:
Upstream version:
Hex file: