Closed askn37 closed 10 months ago
mcuee
commented
10 months ago I tend to think this belongs to wontfx type of issues. Basically I do not think this is a problem myself.
But maybe @dl8dtl, @stefanrueger and @MCUdude can chime in and offer their opinion.
askn37
commented
10 months ago @mcuee
I am confident that the combination of "avrdude" itself and the updated "avrdude.conf" that comes with it does not cause this problem. However, be careful when combining "~/.avrduderc". I can only imagine what would have happened if someone had added their own "programmers" and "parts" in the past. (Except for some weirdo who switches home directories and tests different versions of his avrdude)
stefanrueger
commented
10 months ago Whenever I have had a seg fault in avrdude, it was because of make not realising some files were changed (it goes by date, not checksum). Going back and forth between versions using git checkout or similar can be the cause of this. Of course, it could also be some real problem but AVRDUDE rarely has these.
@askn37 Please could I ask you to make clean (or whatever effects removing of all compiled object files) after switching between versions and before compiling. Here is what I do: I copy the following Makefile into the cloned avrdude version
all:
cmake --build build_linux
install:
cmake --build build_linux; sudo cmake --build build_linux --target install
new:
sudo rm -rf build_linux
cmake -D BUILD_DOC=1 -D CMAKE_BUILD_TYPE=RelWithDebInfo -D HAVE_LINUXGPIO=1 -D HAVE_LINUXSPI=1 -D HAVE_PARPORT=1 -B build_linux
cmake --build build_linuxThen I carry out make new whenever I switch versions.
stefanrueger
commented
10 months ago @askn37 But you are right. I spotted code that would cause the segfault in the way you describe. I will create a PR for this. Thanks for reporting!
mcuee
commented
10 months ago @askn37 But you are right. I spotted code that would cause the segfault in the way you describe. I will create a PR for this. Thanks for reporting!
I see. Changed the label to bug.
askn37
commented
10 months ago Supplementary exam. The build in question was a simpler method and stopped at another failure. Caution is required.
$ git clone https://github.com/avrdudes/avrdude.git avrdude_main
$ cd avrdude_main
$ pwd
/Users/askn/Collaborator/avrdude_main
$ sh build.sh
$ ./build_darwin/src/avrdude -c dryrun -v
avrdude: Version 7.2-20231029 (9dfb6164)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude.conf
avrdude main() error: unable to process system wide configuration file /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude.conf@askn37
I am sorry. This is an issue in git main caused by PR #1542. I made a mistake and did not test it properly. This will be fixed.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c usbasp -p m2560
avrdude_git error: unable to process system wide configuration file
C:\work\avr\avrdude_test\avrdude_bin\avrdude.conf@mcuee
We've found some other strange issues with "dump sernum", but they're a lower priority, so we'll hold off on retesting and reporting until the build issues are resolved.
mcuee
commented
10 months ago @mcuee
We've found some other strange issues with "dump sernum", but they're a lower priority, so we'll hold off on retesting and reporting until the build issues are resolved.
@askn37 Yes, that is perfectly fine.
And thanks a lot for collecting the potential issues in your repo. You are very helpful.
stefanrueger
commented
10 months ago I will create a PR for this.
On second thoughts I pushed a commit onto PR #1538 to avoid merge conflicts. @askn37 Please try PR #1538. You should now get an error message rather than a seg fault.
askn37
commented
10 months ago @stefanrueger
I will create a PR for this.
On second thoughts I pushed a commit onto PR #1538 to avoid merge conflicts. @askn37 Please try PR #1538. You should now get an error message rather than a seg fault.
got it. Segment violation resolved.
askn@alicia avrdude_main % git branch
main
* memory-types
askn@alicia avrdude_main % git log --oneline -n 5
54eacc51 (HEAD -> memory-types) Convert avr_locate_mem(p, string) to avr_locate_mem_by_type()
2be7f7e5 Refer to memory rather than memory type
03db6e5c Use memory type for fuse memories instead of fuse names
c8d11f65 Replace str_eq(m->desc, "(usersig|userrow|prodsig|sigrow") with macros
cd53766d Replace str_eq(m->desc, "...") with mem_is_...(m)
askn@alicia avrdude_main % ./build_darwin/src/avrdude -P /dev/cu.usbserial-230 -c jtag2updi -p avr64dd32 -vT "dump sernum"
avrdude: Version 7.2-20231030 (54eacc51)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude.conf
User configuration file is /Users/askn/.avrduderc
Using Port : /dev/cu.usbserial-230
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 2.01
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 7.53
hardware version: 1
Serial number: 4a:34:94:37:55:3e
Device ID: JTAGICE mkII
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
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 16 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 128 128 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 4 1 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
io 0 0 0 0 no 4160 1 0 0 0 0x00 0x00
sib 0 0 0 0 no 32 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 : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 2.01
S_MCU HW version: 1
S_MCU FW version: 7.53
Serial number : 4a:34:94:37:55:3e
avrdude: silicon revision: 1.3
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961a (probably avr64dd32)
avrdude: processing -T dump sernum
>>> dump sernum 0x0 0x10
Reading | -------------------------------------------------- | 0% 0.00 s
avrdude jtagmkII_read_byte() error: unknown memory sernum
avrdude cmd_dump() error: (dump) error reading sernum address 0x00000 of part AVR64DD32
read operation not supported on memory sernum
avrdude done. Thank you.avrdude jtagmkII_read_byte() error: unknown memory sernum
@askn37 I have pushed a commit to PR #1538 to handle sub-memories of sigrow. Please update from the PR and test reading sernum, osccal20 etc memories.
askn37
commented
10 months ago @stefanrueger
@askn37 I have pushed a commit to PR #1538 to handle sub-memories of
sigrow. Please update from the PR and test readingsernum,osccal20etc memories.
JTAG2UPDI results are negative.
Added debug print to check if the condition does not hold at the relevant location.
diff --git a/src/jtagmkII.c b/src/jtagmkII.c
index 6dcec577..db22150b 100644
--- a/src/jtagmkII.c
+++ b/src/jtagmkII.c
@@ -2239,13 +2239,20 @@ static int jtagmkII_read_byte(const PROGRAMMER *pgm, const AVRPART *p, const AVR
}
} else if (mem_is_in_sigrow(mem)) {
AVRMEM *sr = avr_locate_sigrow(p);
- int doff;
- if ((p->prog_modes & (PM_PDI | PM_UPDI)) && sr && (doff = mem->offset-sr->offset) >= 0 &&
+ int doff = mem->offset-sr->offset;
+ if ((p->prog_modes & (PM_PDI | PM_UPDI)) && sr && doff >= 0 &&
(int) (addr + doff) < sr->size) {
cmd[1] = MTYPE_PRODSIG;
addr += doff;
} else {
pmsg_error("unable to handle memory %s\n", mem->desc);
+ pmsg_error("check: p->prog_modes => %x\n", p->prog_modes);
+ pmsg_error("check: (PM_PDI | PM_UPDI) => %x\n", (PM_PDI | PM_UPDI));
+ pmsg_error("check: bool=> %x\n", (p->prog_modes & (PM_PDI | PM_UPDI)));
+ pmsg_error("check: sr->size => %x\n", sr->size);
+ pmsg_error("check: addr => %x\n", addr);
+ pmsg_error("check: doff => %x\n", doff);
+ pmsg_error("check: (addr + doff) < sr->size => %x\n", (int) (addr + doff) < sr->size);
return -1;
}
} else if (mem_is_io(mem)) {And I got the following information.
sh -x ./J_READ.sh -qvvvv | grep "\(error|conf\)"
+ /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -p avr64dd32 -c jtag2updi -P /dev/cu.usbserial-230 -U fuses:r:avr64dd32/Fuse.hex:i -U lock:r:avr64dd32/Lock.hex:i -U sernum:r:avr64dd32/SERNUM.bin:r -U eeprom:r:avr64dd32/EEPROM.hex:i -U userrow:r:avr64dd32/USERROW.hex:i -U flash:r:avr64dd32/Flash.hex:i -qvvvv
System wide configuration file is /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude.conf
User configuration file is /Users/askn/.avrduderc
User configuration file does not exist or is not a regular file, skipping
avrdude jtagmkII_read_byte() [jtagmkII.c:2248] error: unable to handle memory sernum
avrdude jtagmkII_read_byte() [jtagmkII.c:2249] error: check: p->prog_modes => 11
avrdude jtagmkII_read_byte() [jtagmkII.c:2250] error: check: (PM_PDI | PM_UPDI) => 18
avrdude jtagmkII_read_byte() [jtagmkII.c:2251] error: check: bool=> 10
avrdude jtagmkII_read_byte() [jtagmkII.c:2252] error: check: sr->size => 80
avrdude jtagmkII_read_byte() [jtagmkII.c:2253] error: check: addr => 1110
avrdude jtagmkII_read_byte() [jtagmkII.c:2254] error: check: doff => 10
avrdude jtagmkII_read_byte() [jtagmkII.c:2255] error: check: (addr + doff) < sr->size => 0
avrdude avr_read_mem() [avr.c:484] error: unable to read byte at address 0x0000
avrdude avr_read_mem() [avr.c:486] error: read operation not supported for memory sernum
avrdude do_op() [update.c:411] error: unable to read all of sernum memory, rc=-2(int) (addr + doff) < sr->size showed false.
please refer.
stefanrueger
commented
10 months ago @askn37 Vvv useful; the addr already contains the offset. It is not necessary to figure out where the sub-memory sits in sigrow.
I made change in PR #1538 to reflect this.
askn37
commented
10 months ago @askn37 Vvv useful; the addr already contains the offset. It is not necessary to figure out where the sub-memory sits in sigrow.
I made change in PR #1538 to reflect this.
wonderful. The issue with jtagmkII_updi not being able to read IO memory is definitely resolved.
Current programmer=jtag2updi
Current type=t824
+/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -p t824 -c jtag2updi -P /dev/cu.usbserial-230 -U fuses:r:-:I -U lock:r:-:I -U prodsig:r:-:I -U signature:r:-:I -U tempsense:r:-:I -U sernum:r:-:I -U osccal16:r:-:I -U osccal20:r:-:I -U osc16err:r:-:I -U osc20err:r:-:I -q
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9329 (probably t824)
avrdude: processing -U fuses:r:-:I
avrdude: reading fuses memory ...
avrdude: writing output file <stdout>
:0A0000000DC009C09DE994BF809374 // 00000> .@.@.i.?..
:00000001FF
avrdude: processing -U lock:r:-:I
avrdude: reading lock memory ...
avrdude: writing output file <stdout>
:01000000C53A // 00000> E
:00000001FF
avrdude: processing -U prodsig:r:-:I
avrdude: reading prodsig/sigrow memory ...
avrdude: writing output file <stdout>
:200000000000F20000000E00000000000000000000000000000000000000000000000000E0 // 00000> ..r.............................
:200020000000000000000000000000000000000000000000000000000000000000FF3F0280 // 00020> ..............................?.
:00000001FF
avrdude: processing -U signature:r:-:I
avrdude: reading signature memory ...
avrdude: writing output file <stdout>
:030000001E932923 // 00000> ..)
:00000001FF
avrdude: processing -U tempsense:r:-:I
avrdude: reading tempsense memory ...
avrdude: writing output file <stdout>
:0200000088F97D // 00000> .y
:00000001FF
avrdude: processing -U sernum:r:-:I
avrdude: reading sernum memory ...
avrdude: writing output file <stdout>
:0A000000304150535349D947362AC6 // 00000> 0APSSIYG6*
:00000001FF
avrdude: processing -U osccal16:r:-:I
avrdude: reading osccal16 memory ...
avrdude: writing output file <stdout>
:02000000A30655 // 00000> #.
:00000001FF
avrdude: processing -U osccal20:r:-:I
avrdude: reading osccal20 memory ...
avrdude: writing output file <stdout>
:020000002206D6 // 00000> ".
:00000001FF
avrdude: processing -U osc16err:r:-:I
avrdude: reading osc16err memory ...
avrdude: writing output file <stdout>
:02000000FFFF00 // 00000> ..
:00000001FF
avrdude: processing -U osc20err:r:-:I
avrdude: reading osc20err memory ...
avrdude: writing output file <stdout>
:02000000FFFF00 // 00000> ..
:00000001FF
avrdude done. Thank you.Current programmer=jtag2updi
Current type=avr64dd32
+/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -p avr64dd32 -c jtag2updi -P /dev/cu.usbserial-230 -U fuses:r:-:I -U lock:r:-:I -U prodsig:r:-:I -U signature:r:-:I -U tempsense:r:-:I -U sernum:r:-:I -U osccal16:r:-:I -U osccal20:r:-:I -U osc16err:r:-:I -U osc20err:r:-:I -q
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961a (probably avr64dd32)
avrdude: processing -U fuses:r:-:I
avrdude: reading fuses memory ...
avrdude: writing output file <stdout>
:1000000002C0F8950895112480914000811105C027 // 00000> .@x....$..@....@
:00000001FF
avrdude: processing -U lock:r:-:I
avrdude: reading lock memory ...
avrdude: writing output file <stdout>
:040000005CC5C55CBA // 00000> \EE\
:00000001FF
avrdude: processing -U prodsig:r:-:I
avrdude: reading prodsig/sigrow memory ...
avrdude: writing output file <stdout>
:200000000000000000000000000000000000000000000000000040000000000000000000A0 // 00000> ......................@.........
:200020000000000000000000000000000000000000000000000000000000000000FF7F350D // 00020> ...............................5
:20004000200000000000000000000000000000000000000033760D000000000000000000CA // 00040> _...................3v..........
:2000600000000000000200010C0000000A0213000100000000060000001E0000000000002D // 00060> ................................
:00000001FF
avrdude: processing -U signature:r:-:I
avrdude: reading signature memory ...
avrdude: writing output file <stdout>
:030000001E961A2F // 00000> ...
:00000001FF
avrdude: processing -U tempsense:r:-:I
avrdude: reading tempsense memory ...
avrdude: writing output file <stdout>
:04000000F2031E0DDC // 00000> r...
:00000001FF
avrdude: processing -U sernum:r:-:I
avrdude: reading sernum memory ...
avrdude: writing output file <stdout>
:1000000042225361510074160102013000000000C9 // 00000> B"SaQ.t....0....
:00000001FF
avrdude: processing -U osccal16:r:-:I
avrdude warning: skipping -U osccal16:... as memory not defined for part AVR64DD32
avrdude: processing -U osccal20:r:-:I
avrdude warning: skipping -U osccal20:... as memory not defined for part AVR64DD32
avrdude: processing -U osc16err:r:-:I
avrdude warning: skipping -U osc16err:... as memory not defined for part AVR64DD32
avrdude: processing -U osc20err:r:-:I
avrdude warning: skipping -U osc20err:... as memory not defined for part AVR64DD32
avrdude done. Thank you.Current programmer=updi4avr
Current type=avr64ea32
+/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -p avr64ea32 -c updi4avr -P /dev/cu.usbserial-230 -U fuses:r:-:I -U lock:r:-:I -U prodsig:r:-:I -U signature:r:-:I -U tempsense:r:-:I -U sernum:r:-:I -U osccal16:r:-:I -U osccal20:r:-:I -U osc16err:r:-:I -U osc20err:r:-:I -q
avrdude warning: programmer jtag2updi overwrites previous definition /Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude.conf:2570. [/Users/askn/.avrduderc:27]
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e961f (probably avr64ea32)
avrdude: processing -U fuses:r:-:I
avrdude: reading fuses memory ...
avrdude: writing output file <stdout>
:1000000049C000004FC000004DC000004BC00000C0 // 00000> I@..O@..M@..K@..
:00000001FF
avrdude: processing -U lock:r:-:I
avrdude: reading lock memory ...
avrdude: writing output file <stdout>
:040000005CC5C55CBA // 00000> \EE\
:00000001FF
avrdude: processing -U prodsig:r:-:I
avrdude: reading prodsig/sigrow memory ...
avrdude: writing output file <stdout>
:200000000000000000000000000000000000000000000000000000000000000000000000E0 // 00000> ................................
:200020000000000000000000000000000000000000000000000000000000000000FF7F0240 // 00020> ................................
:200040002500070025000700250007002500070000000000000000000000000000000000F0 // 00040> %...%...%...%...................
:200060000700000000000005000000002A0006000000000000100000002E00000000000006 // 00060> ............*...................
:00000001FF
avrdude: processing -U signature:r:-:I
avrdude: reading signature memory ...
avrdude: writing output file <stdout>
:030000001E961F2A // 00000> ...
:00000001FF
avrdude: processing -U tempsense:r:-:I
avrdude: reading tempsense memory ...
avrdude: writing output file <stdout>
:04000000C9FDAEEC9C // 00000> I}.l
:00000001FF
avrdude: processing -U sernum:r:-:I
avrdude: reading sernum memory ...
avrdude: writing output file <stdout>
:10000000622321159FFF8222F028F045FFFFFFFFAA // 00000> b#!...."p(pE....
:00000001FF
avrdude: processing -U osccal16:r:-:I
avrdude warning: skipping -U osccal16:... as memory not defined for part AVR64EA32
avrdude: processing -U osccal20:r:-:I
avrdude warning: skipping -U osccal20:... as memory not defined for part AVR64EA32
avrdude: processing -U osc16err:r:-:I
avrdude warning: skipping -U osc16err:... as memory not defined for part AVR64EA32
avrdude: processing -U osc20err:r:-:I
avrdude warning: skipping -U osc20err:... as memory not defined for part AVR64EA32
avrdude done. Thank you.(EDIT: There was a mistake in pasting the log, so I replaced the AVR_EA section.)
stefanrueger
commented
10 months ago @askn37 Thanks for testing. Your results look like sigrow/prodsig is not read correctly. I would expect this to contain signature, sernum, tempsense, etc but it doesn't look like it in your examples. -c dryrun shows where which sub-memories should go:
$ avrdude -qqp t824 -c dryrun -U prodsig:r:-:I
:200000001E93295554535251504F4E4D4CFFFFFFFFFFFFFFFFFFFFFF6F6F4F4FFFFFFFFF74 // 00000> ..)UTSRQPONML...........ooOO....
:20002000545465654545FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE // 00020> TTeeEE..........................
:00000001FFT is where the tempsense calibration values should be, o the osccal values, UTS... where sernum should be.
The jtagmkII.c code is not crisp and clear as it has grown organically to cater for very different interfaces over the last 20 years. I think https://github.com/avrdudes/avrdude/blob/2bb36b9b0b828c8fe3c92e308c5e40f56e6aa9aa/src/jtagmkII.c#L1006 and https://github.com/avrdudes/avrdude/blob/2bb36b9b0b828c8fe3c92e308c5e40f56e6aa9aa/src/jtagmkII.c#L2169 has the effect of adding offset twice and we are reading from 0x2200 rather than 0x1100. Can someone confirm, please?
askn37
commented
10 months ago @stefanrueger
Unlike JTAG2UPDI, which uses the device_descriptor structure, UPDI4AVR uses the xmega_device_desc structure. The branch condition to switch is PDATA(pgm)->fwver >= 0x700.
This requires that the byte chunks passed in STK500v2 are zero-based relative addresses. If the address value is doubled, then both the structure and the READ/WRITE instruction can be considered to have the same address.
UPDI4AVR was fine in the 6.3 to 7.2 implementation, so this fact suggests a break in compatibility.
To double check this behavior you will need another JTAG debugger that uses jtagmkII_set_xmega_params. (who is that? Dragon?)
askn37
commented
10 months ago I will add a little explanation to deepen your knowledge.
'xmega_device_desc', as the name suggests, contains a memory layout enhanced with the XMEGA architecture. It does not pass the model number of the working chip or his NVMCTRL version number. Instead, pass this structure to the STK500v2 adapter.
/* New Xmega device descriptor, for firmware version 7 and above */
struct xmega_device_desc {
unsigned char whatever[2]; // cannot guess; must be 0x0002
unsigned char datalen; // length of the following data, = 47
unsigned char nvm_app_offset[4]; // NVM offset for application flash
unsigned char nvm_boot_offset[4]; // NVM offset for boot flash
unsigned char nvm_eeprom_offset[4]; // NVM offset for EEPROM
unsigned char nvm_fuse_offset[4]; // NVM offset for fuses
unsigned char nvm_lock_offset[4]; // NVM offset for lock bits
unsigned char nvm_user_sig_offset[4]; // NVM offset for user signature row
unsigned char nvm_prod_sig_offset[4]; // NVM offset for production sign. row
unsigned char nvm_data_offset[4]; // NVM offset for data memory (SRAM + IO)
unsigned char app_size[4]; // size of application flash
unsigned char boot_size[2]; // size of boot flash
unsigned char flash_page_size[2]; // flash page size
unsigned char eeprom_size[2]; // size of EEPROM
unsigned char eeprom_page_size; // EEPROM page size
unsigned char nvm_base_addr[2]; // IO space base address of NVM controller
unsigned char mcu_base_addr[2]; // IO space base address of MCU control
};
#endif /* JTAGMKII_PRIVATE_EXPORTED */Seeing this, the STK500v2 adapter can deduce which series the target chip belongs to even if it cannot read the target chip's PDI/UPDI. In other words, you can get hints on how to switch the circuits and signal lines required for high voltage control. Regarding UPDI, even if you can't read the SIB from the chip, you can infer the version of NVMCTRL and therefore decide whether to give 12V to the UPDI pad or 8.2V to the RESET pad. In particular, nvm_lock_offset, nvm_user_sig_offset, and nvm_prod_sig_offset are significantly different. Additionally, the SRAM starting address needed to rewrite his USERROW of the lock device can also be obtained through nvm_data_offset. (Since it is not normally used, a dummy value is set.)
The problem is that subsequent READ/WRITE instructions mix relative addressing to the structure and absolute addressing from the beginning of the memory map. It's probably an old bug, but it's a convention kept for backwards compatibility. Additionally, terminal mode also has non-uniform addressing. The complex conditional branching in the code below is the result of trial and error to accommodate the differences. At least, this is how I interpreted it from 6.3 to 7.2.
stefanrueger
commented
10 months ago complex conditional branching in the code below is the result of trial and error to accommodate the differences.
It is better controlling both sides the FW of the programmer HW and the -c module of AVRDUDE. Assuming there is a published open hardware design for a programmer HW, a competently written FW for the programmer, then I am sure that the AVRDUDE team would consider adding a corresponding -c programmer module.
askn37
commented
10 months ago test case plan to me
Prepare the following shell script
-c *** -p t824 -U fuses:r:-:I -U lock:r:-:I -U prodsig:r:-:I
Try this 2x2 pattern
Two types of configuration files Old type (7.0 or earlier?): jtagmkII_pdi+has_updi New type (main): jtagmkII_updi+PM_UPDI
Build the latest JTGA2UPDI main and write it to UNO (mine hasn't been touched in a long time) Prepare the public UPDI4AVR main (return to before AVR_EB modification)
stefanrueger
commented
10 months ago | UPDI4AVR was fine in the 6.3 to 7.2 implementation, so this fact suggests a break in compatibility.
This may well be. I suspect the root problem is that updi4avr project is (so far) not catered for: AVRDUDE has no way of knowing which unsupported projects utilise which behaviour!
Whilst we develop AVRDUDE further we try hard to ensure that once supported and known programmers keep working with AVRDUDE. These are often programmers someone in the team has and that we can test on. We welcome reports on regressions.
Also, please note, it is generally discouraged to use outdated .conf files with newer AVRDUDE versions. Always try to use the matching .conf file: AVRDUDE expects it can rely on a configuration model of a part/programmer that matches the code base.
Having said this, once you figure out what needs changing in AVRDUDE so that updi4avr keeps working well, feel free to submit a PR. We will try to see if that breaks supported programmers. If it does not, we will consider merging. The best way forward, however, is to make sure that AVRDUDE knows about a project/programmer and has a dedicated -c programmer for it that works in tandem with it. If you can control both sides of the programming, host downloader/uploader and programmer firmware, then both -c programmer and the FW have a sporting chance to be crisp, clear, simple and easily maintainable.
askn37
commented
10 months ago @stefanrueger
UPDI4AVR also provides upward compatibility with JTAG2UPDI. This means you can safely create a bootloader using "-c jtag2updi". We are also approaching AVR_Dx/Ex, which JATG2UPDI has not followed before. This functionality is available out-of-the-box for DxCore and MCUdude projects. (Their "avrdude" is still old)
What I specifically want to do is cross-check whether the old and new "avrdude"(and the pair of configuration files) and their adapters are backwards compatible. Generate a report if any discrepancies are found.
askn37
commented
10 months ago Script
#!/bin/bash
#
# STK500v2 cross-check
#
avrdude_main=~/Collaborator/avrdude_main/build_darwin/src/avrdude
avrdude_72=~/Library/Arduino15/packages/MultiX-Zinnia/tools/avrdude/7.2-arduino.1/bin/avrdude
avrdude_71=~/Library/Arduino15/packages/MegaCoreX/tools/avrdude/7.1-arduino.1/bin/avrdude
conf=
part=t824
port_jtag2updi=/dev/cu.usbmodem1201
port_updi4avr=/dev/cu.usbserial-230
avrdude_prog_force=jtag2updi
verbose=-qvvvv
test_prog=jtag2updi
test_fwv=6
# testcase userconfig for avrdude_63
(cat <<-EOL
programmer
id = "jtag2updi";
desc = "JTAGv2 to UPDI bridge";
type = "jtagmkii_pdi";
connection_type = serial;
baudrate = 115200;
EOL
) > _avrduderc_old
test_run_part () {
avrdude_name=$1
avrdude_prog=$2
avrdude_cmd=$(eval echo \$$1)
avrdude_port=$(eval echo \$port_${2})
sigrow=
echo
echo -----------------------
echo Test case: $avrdude_name
echo Test prog: $avrdude_prog
echo Test port: $avrdude_port
# rm -f ~/.avrduderc 2>&1 > /dev/null
if [ $avrdude_name = "avrdude_main" ]
then
sigrow="-U sigrow:r:sigrow_${avrdude_prog}_${avrdude_name}.hex:i"
fi
cmd=$(echo $avrdude_cmd $verbose -p $part -c $avrdude_prog_force -P $avrdude_port $conf \
-l ${avrdude_name}_${avrdude_prog}.log \
-U fuses:r:fuses_${avrdude_prog}_${avrdude_name}.hex:i \
-U lock:r:lock_${avrdude_prog}_${avrdude_name}.hex:i \
-U prodsig:r:prodsig_${avrdude_prog}_${avrdude_name}.hex:i \
-U sernum:r:sernum_${avrdude_prog}_${avrdude_name}.hex:i \
$sigrow \
)
echo +$cmd
$cmd
}
test_compare () {
cmd=$(echo diff -u ${1}_${2}_avrdude_71.hex ${1}_${2}_avrdude_72.hex)
echo
echo +$cmd
echo
$cmd
cmd=$(echo diff -u ${1}_${2}_avrdude_72.hex ${1}_${2}_avrdude_main.hex)
echo
echo +$cmd
echo
$cmd
}
# run stage
test_run_part avrdude_71 $test_prog
test_run_part avrdude_72 $test_prog
test_run_part avrdude_main $test_prog
# compare stage
echo
echo -----------------------
echo comparing STK500v2 FW_V=$test_fwv
test_compare fuses $test_prog
test_compare lock $test_prog
test_compare prodsig $test_prog
test_compare sernum $test_prog
cmd=$(echo diff -u prodsig_jtag2updi_avrdude_main.hex sigrow_jtag2updi_avrdude_main.hex)
echo
echo +$cmd
echo
$cmd
# restore userconfig
# cp -f _avrduderc_main ~/.avrduderc
echo end of testcaseaskn@alicia _is1546 % ./crosstest_STK500v2_6.sh
-----------------------
Test case: avrdude_71
Test prog: jtag2updi
Test port: /dev/cu.usbmodem1201
+/Users/askn/Library/Arduino15/packages/MegaCoreX/tools/avrdude/7.1-arduino.1/bin/avrdude -qvvvv -p t824 -c jtag2updi -P /dev/cu.usbmodem1201 -l avrdude_71_jtag2updi.log -U fuses:r:fuses_jtag2updi_avrdude_71.hex:i -U lock:r:lock_jtag2updi_avrdude_71.hex:i -U prodsig:r:prodsig_jtag2updi_avrdude_71.hex:i -U sernum:r:sernum_jtag2updi_avrdude_71.hex:i
-----------------------
Test case: avrdude_72
Test prog: jtag2updi
Test port: /dev/cu.usbmodem1201
+/Users/askn/Library/Arduino15/packages/MultiX-Zinnia/tools/avrdude/7.2-arduino.1/bin/avrdude -qvvvv -p t824 -c jtag2updi -P /dev/cu.usbmodem1201 -l avrdude_72_jtag2updi.log -U fuses:r:fuses_jtag2updi_avrdude_72.hex:i -U lock:r:lock_jtag2updi_avrdude_72.hex:i -U prodsig:r:prodsig_jtag2updi_avrdude_72.hex:i -U sernum:r:sernum_jtag2updi_avrdude_72.hex:i
-----------------------
Test case: avrdude_main
Test prog: jtag2updi
Test port: /dev/cu.usbmodem1201
+/Users/askn/Collaborator/avrdude_main/build_darwin/src/avrdude -qvvvv -p t824 -c jtag2updi -P /dev/cu.usbmodem1201 -l avrdude_main_jtag2updi.log -U fuses:r:fuses_jtag2updi_avrdude_main.hex:i -U lock:r:lock_jtag2updi_avrdude_main.hex:i -U prodsig:r:prodsig_jtag2updi_avrdude_main.hex:i -U sernum:r:sernum_jtag2updi_avrdude_main.hex:i -U sigrow:r:sigrow_jtag2updi_avrdude_main.hex:i
-----------------------
comparing STK500v2 FW_V=6
+diff -u fuses_jtag2updi_avrdude_71.hex fuses_jtag2updi_avrdude_72.hex
+diff -u fuses_jtag2updi_avrdude_72.hex fuses_jtag2updi_avrdude_main.hex
--- fuses_jtag2updi_avrdude_72.hex 2023-11-02 00:00:19
+++ fuses_jtag2updi_avrdude_main.hex 2023-11-02 00:00:20
@@ -1,2 +1,2 @@
-:0900000000007EFFFFF7FF000283
+:0A00000000007EFFFFF7FF0002FF83
:00000001FF
+diff -u lock_jtag2updi_avrdude_71.hex lock_jtag2updi_avrdude_72.hex
+diff -u lock_jtag2updi_avrdude_72.hex lock_jtag2updi_avrdude_main.hex
+diff -u prodsig_jtag2updi_avrdude_71.hex prodsig_jtag2updi_avrdude_72.hex
+diff -u prodsig_jtag2updi_avrdude_72.hex prodsig_jtag2updi_avrdude_main.hex
--- prodsig_jtag2updi_avrdude_72.hex 2023-11-02 00:00:19
+++ prodsig_jtag2updi_avrdude_main.hex 2023-11-02 00:00:20
@@ -1,3 +1,3 @@
-:20000000304150535349D947362AFF420D05FFFFFF1506FFFFA3062206FFFFE0F888F9FF20
-:1D002000FFFFFFFFFFAEF4E3FC1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90F3B6
+:200000001E9329304150535349D947362AFF420D05FFFFFF1506FFFFA3062206FFFFE0F8C6
+:2000200088F9FFFFFFFFFFFFAEF4E3FC1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90F333
:00000001FF
+diff -u sernum_jtag2updi_avrdude_71.hex sernum_jtag2updi_avrdude_72.hex
+diff -u sernum_jtag2updi_avrdude_72.hex sernum_jtag2updi_avrdude_main.hex
--- sernum_jtag2updi_avrdude_72.hex 2023-11-02 00:00:19
+++ sernum_jtag2updi_avrdude_main.hex 2023-11-02 00:00:20
@@ -1,2 +1,2 @@
-:0A0000004150535349D947362AFFF7
+:0A000000304150535349D947362AC6
:00000001FF
+diff -u prodsig_jtag2updi_avrdude_main.hex sigrow_jtag2updi_avrdude_main.hex
end of testcase
askn@alicia _is1546 % All comparisons between v7.1 and v7.2 matched.
Comparison of v7.2 and main did not match.
v7.2
avrdude: processing -U prodsig:r:prodsig_jtag2updi_avrdude_72.hex:i
avrdude: reading prodsig memory ...
avrdude: jtagmkII_paged_load(.., prodsig, 61, 61)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 61
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [18] . [00] . [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6]
= [3d] . [00] . [00] . [00]
. [03] . [11] . [00] . [00]
. [f9] j [6a]
;
;
;
avrdude: processing -U sernum:r:sernum_jtag2updi_avrdude_72.hex:i
avrdude: reading sernum memory ...
avrdude: jtagmkII_read_byte(.., sernum, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [19] . [00] . [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0]
. [01] . [00] . [00] . [00]
. [04] . [11] . [00] . [00]
" [22] _ [5f] main
avrdude: processing -U prodsig:r:prodsig_jtag2updi_avrdude_main.hex:i
avrdude: reading prodsig/sigrow memory ...
avrdude: jtagmkII_paged_load(.., prodsig, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [10] . [00] . [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6]
@ [40] . [00] . [00] . [00]
. [00] . [11] . [00] . [00]
. [e8] . [fd]
;
;
;
avrdude: processing -U sernum:r:sernum_jtag2updi_avrdude_main.hex:i
avrdude: reading sernum memory ...
avrdude: jtagmkII_read_byte(.., sernum, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [11] . [00] . [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6]
. [01] . [00] . [00] . [00]
. [03] . [11] . [00] . [00]
d [64] , [2c] This is different
v7.2 sernum [0e] [05] [c0] MTYPE_FLASH and [04] [11] [00] [00] start_addr 0x1104 !!!
main sernum [0e] [05] [c6] MTYPE_PRODSIGWhat you found was a bug in the old version.
askn37
commented
10 months ago I made one mistake. In the previous comment he wrote the label STK500v2 (AVR068). JTAG2UPDI and UPDI4AVR are actually implementations of JTAGICEmkII (AVR067). The test result is correct, but the label is incorrect. I apologize.
stefanrueger
commented
10 months ago Thanks @askn37 for thorough testing. I was wondering whether the test still works OK in PR #1538?
If so, I take it that once PR #1538 is merged this Issue can be closed.
askn37
commented
10 months ago @stefanrueger
My main job is as a debugger for hire. We are also familiar with building networks and audio/video distribution. Examples include old satellite links, disaster helicopter telemetry, and secret nuclear reactor hotlines. We can also help you translate AVR documentation into your native language (https://avr.jp). The disadvantage of not being a native English speaker is the need to understand all of his publicly available AVR documents and identify differences from the originals. We are also currently working on translating the AVR_EB documentation.
That's why I'm always concerned about the smell of bug...
The rest is a comparison of how JTAGICEmkII's FWV=7 has changed from before. Issues that were previously ignored may be brought to light. However, FWV=7 is not documented. I think AVRDragon is probably implemented, but I don't have it, so my evaluation will be a guess.
askn37
commented
10 months ago @stefanrueger : https://github.com/avrdudes/avrdude/pull/1538
This document reveals what avrdude is serially outputting in the JTAGICEmkII protocol, especially when FWV=7 and PM_UPDI. Probably no one would have imagined such a combination. Either it wasn't there or it was hidden by the USB connection.
I happened to have created such an UPDI implementation here, so I can now interact directly with avrdude.
This document reveals what avrdude is serially outputting in the JTAGICEmkII protocol, especially when FWV=7 and PM_UPDI. Probably no one would have imagined such a combination. Either it wasn't there or it was hidden by the USB connection.
I happened to have created such an UPDI implementation here, so I can now interact directly with avrdude.
JTAG2UPDI has FWV=6, so it does not match this document. Originally the XMEGA PDI protocol, it has absolute addressing up to 32 bits wide. Previous versions of avrdude with FWV=6 required a trick in avrdude.conf to enable the 17th bit to be able to handle AVR_DA/DB 128KiB.
avrdude v6.3 does not support tinyAVR-2, so this test uses tinyAVR-0 instead. This is a 16bit address chip. In the end, v6.8, v7.1, and v7.2 exhibited the same behavior, so this consideration was unnecessary. (The v6.8 configuration is missing "sernum")
avrdude: Version 7.2-arduino.1
S_MCU:
boot-loader FW version: 1
firmware version: 7.53
hardware version: 1OK, are you ready?
avrdude: jtagmkII_set_xmega_params(): Sending set Xmega params command:
avrdude: jtagmkII_send(): sending 51 bytes
avrdude: send: . [1b] . [07] . [00]
3 [33] . [00] . [00] . [00]
. [0e] 6 [36] // struct xmega_device_desc {
. [02] . [00] // unsigned char whatever[2]; // cannot guess; must be 0x0002
/ [2f] // unsigned char datalen; // length of the following data, = 47
. [00] . [00] . [00] . [00] // unsigned char nvm_app_offset[4]; // NVM offset for application flash
. [00] . [00] . [00] . [00] // unsigned char nvm_boot_offset[4]; // NVM offset for boot flash
. [00] . [14] . [00] . [00] // unsigned char nvm_eeprom_offset[4]; // NVM offset for EEPROM
. [80] . [12] . [00] . [00] // unsigned char nvm_fuse_offset[4]; // NVM offset for fuses
. [8a] . [12] . [00] . [00] // unsigned char nvm_lock_offset[4]; // NVM offset for lock bits
. [00] . [13] . [00] . [00] // unsigned char nvm_user_sig_offset[4]; // NVM offset for user signature row
. [03] . [11] . [00] . [00] // unsigned char nvm_prod_sig_offset[4]; // NVM offset for production sign. row
. [00] . [00] . [00] . [01] // unsigned char nvm_data_offset[4]; // NVM offset for data memory (SRAM + IO)
. [00] . [00] . [00] . [00] // unsigned char app_size[4]; // size of application flash
. [00] . [00] // unsigned char boot_size[2]; // size of boot flash
@ [40] . [00] // unsigned char flash_page_size[2]; // flash page size
@ [40] . [00] // unsigned char eeprom_size[2]; // size of EEPROM
[20] // unsigned char eeprom_page_size; // EEPROM page size
. [00] . [10] // unsigned char nvm_base_addr[2]; // IO space base address of NVM controller
. [00] . [00] // unsigned char mcu_base_addr[2]; // IO space base address of MCU control
. [8c] . [1c] // } // crc16-ccitt'application' and 'boot' have no memory settings, so nvm_app_offset and nvm_boot_offset will be zero. It has been ignored in avrdude.conf for many years as it is not particularly needed in the XMEGA generation. However, the UPDI generation is different. This will cause problems later....
Side note: For UPDI4AVR, expand the response here to include UPDI_SIB_256. avrdude simply ignores it.
avrdude: AVR device initialized and ready to accept instructions
avrdude: jtagmkII_read_byte(.., signature, 0x0, ...)
avrdude: jtagmkII_program_enable(): Sending enter progmode command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: send: . [1b] . [08] . [00] . [01] . [00] . [00] . [00] . [0e] . [14] c [63] . [fd]
avrdude: jtagmkII_recv():
avrdude: recv: . [1b]
avrdude: recv: . [08]
avrdude: recv: . [00]
avrdude: recv: $ [24]
avrdude: recv: . [00]
avrdude: recv: . [00]
avrdude: recv: . [00]
avrdude: recv: . [0e]
avrdude: recv: . [80] . [02] . [83] . [00]
t [74] i [69] n [6e] y [79] A [41] V [56] R [52] [20]
P [50] : [3a] 0 [30] D [44] : [3a] 0 [30] - [2d] 3 [33]
M [4d] 2 [32] [20] ( [28] 0 [30] 2 [32] . [2e] 5 [35]
9 [39] B [42] 1 [31] 4 [34] . [2e] 0 [30] ) [29] . [00]
avrdude: recv: B [42]
avrdude: recv: & [26]
avrdude: jtagmkII_recv(): got message seqno 8 (command_sequence == 8)
avrdude: recv: . [80] . [02] . [83] . [00]
t [74] i [69] n [6e] y [79] A [41] V [56] R [52] [20]
P [50] : [3a] 0 [30] D [44] : [3a] 0 [30] - [2d] 3 [33]
M [4d] 2 [32] [20] ( [28] 0 [30] 2 [32] . [2e] 5 [35]
9 [39] B [42] 1 [31] 4 [34] . [2e] 0 [30] ) [29] . [00]
Raw message:
0x80 0x02 0x83 0x00 0x74 0x69 0x6e 0x79 0x41 0x56 0x52 0x20 0x50 0x3a 0x30 0x44
0x3a 0x30 0x2d 0x33 0x4d 0x32 0x20 0x28 0x30 0x32 0x2e 0x35 0x39 0x42 0x31 0x34
0x2e 0x30 0x29 0x00
OKRead the signature byte by byte.
avrdude: jtagmkII_read_byte(.., signature, 0x1, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0b] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b4] // CMND_READ_MEMORY + MTYPE_SIGN_JTAG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [00] . [11] . [00] . [00] // 0x1100 absolute address (attribute IO)
. [15] . [c4]MTYPE_SIGN_JTAG and absolute address were commanded. Initially it is the same address as nvm_user_sig_offset. So it seems correct not to add an offset.
avrdude: Device signature = 0x1e9123 (probably t202)
Repeat one more time to save the signature to file.
avrdude: processing -U sig:r:block_sig_updi4avr_avrdude_72.hex:i
avrdude: reading signature memory ...
avrdude: jtagmkII_read_byte(.., signature, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b4] // CMND_READ_MEMORY + MTYPE_SIGN_JTAG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [00] . [11] . [00] . [00] // 0x1100 absolute address (attribute IO)
8 [38] . [b4]This is also 1-byte mode oriented....
avrdude: processing -U fuses:r:block_fuses_updi4avr_avrdude_72.hex:i
avrdude: reading fuses memory ...
avrdude: jtagmkII_read_byte(.., fuses, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [10] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b2] // CMND_READ_MEMORY + MTYPE_FUSE_BITS
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [80] . [12] . [00] . [00] // 0x1280 absolute address (attribute IO)
. [87] . [0a]OK.
An absolute address is sent even though it is MTYPE_FUSE_BITS. In other words, do not add the nvm_fuse_offset offset here. Probably because it's in 1-byte mode. It must be so....
avrdude: reading lock memory ...
avrdude: jtagmkII_read_byte(.., lock, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [19] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b3] // CMND_READ_MEMORY + MTYPE_LOCK_BITS
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [8a] . [12] . [00] . [00] // 0x1280 absolute address (attribute IO)MTYPE_LOCK_BITS was specified but an absolute address was commanded. In other words, do not add nvm_lock_offset. Same process as MTYPE_FUSE_BITS. OK.
avrdude: reading prodsig memory:
avrdude: jtagmkII_paged_load(.., prodsig, 61, 61)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 61
avrdude: jtagmkII_paged_load(): Sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: Send: . [1b] . [1a] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
= [3d] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_prod_sig_offset == 0x1103
c [63] . [b0]Block mode was used here for the first time. Since the specified address is zero, we must add the nvm_prod_sig_offset offset. Then, unless you are in 1-byte mode, adding an offset should be correct. surely.
avrdude: reading sernum memory ...
avrdude: jtagmkII_read_byte(.., sernum, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [1b] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [04] . [11] . [00] . [00] // 0x1104 absolute address (attribute IO)
< [3c] . [7f]MTYPE_XMEGA_FLASH was specified. Although it is unnatural, since it is in 1-byte mode, it also accepts absolute addresses.
avrdude: reading userrow/usersig memory ...
avrdude: jtagmkII_paged_load(.., userrow, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] % [25] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c5] // CMND_READ_MEMORY + MTYPE_USERSIG
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_user_sig_offset == 0x1300
. [b7] n [6e]Since it is MTYPE_USERSIG and a block read, add nvm_user_sig_offset to the offset. There is no contradiction.
avrdude: reading eeprom memory ...
avrdude: jtagmkII_paged_load(.., eeprom, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] & [26] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] " [22] // CMND_READ_MEMORY + MTYPE_EEPROM
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_eeprom_offset == 0x1400
. [c9] b [62]Since it is MTYPE_EEPROM and a block read, add nvm_eeprom_offset to the offset. Not MTYPE_EEPROM_XMEGA. There is no contradiction.
avrdude: reading flash memory ...
avrdude: jtagmkII_paged_load(.., flash, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] ( [28] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
@ [40] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset 0x0000 is nvm_????
. [e5] . [1f]Now you (JTAGICEmkII 'UPDI' adapter) are in trouble!
MTYPE_XMEGA_FLASH and block mode were ordered. But the addressing is zero. But tinyAVR's 16bit flash address is 0x8000. For megaAVR-0 it should be 0x4000. But so far, such address offsets have not been taught. Do you remember? Both nvm_app_offset and nvm_boot_offset were indeed zero!
24-bit addressing can implicitly add 0x800000 to convert to SPM/ELPM. However, NVMCTRL_ADDRESS of tinyAVR/megaAVR cannot be used because it is 16bit. The flash area is located within the IO area displayed by ST/LD.
Yes, if that's true, this should be a set of MTYPE_BOOT_FLASH and nvm_boot_offset. 0x4000 or 0x8000 are valid results. However, if this mistake is common to you, we recommend using the clever JTAGICEmkII 'UPDI' adapter. You can tell the difference between tinyAVR and megaAVR by reading UPDI_SIB yourself. Otherwise, you can use 24-bit addresses, so the offset will be 0x800000. It works well.
This depends on the implementation of the JTAGICEmkII 'UPDI' adapter.
Originally, this is why boot and application memory settings were needed. This has always been in xmega_device_desc. But avrdude has been ignoring it for a long time or has completely forgotten about it. Because no one was using it.
Now let's look at terminal mode. In most cases this is a byte-oriented interface.
avrdude: processing -t interactive terminal
avrdude> dump prodsig
>>> dump prodsig 0x0 0x3d
avrdude: jtagmkII_read_byte(.., prodsig, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [03] . [11] . [00] . [00] // 0x1103 absolute address (attribute IO)
. [c1] . [e4]Unlike "reading prodsig memory", "dump prodsig" is byte-oriented. Addresses contain absolute values. So adding nvm_prod_sig_offset is a mistake.
avrdude: processing -t interactive terminal
avrdude> dump usersig
>>> dump userrow 0x0 0x20
avrdude: jtagmkII_paged_load(.., userrow, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c5] // CMND_READ_MEMORY + MTYPE_USERSIG
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_user_sig_offset == 0x1300
. [0d] . [ff]usersig, eeprom, and flash are properly in block mode. The correct answer is to add an offset to the commanded address.
avrdude: processing -t interactive terminal
avrdude> read flash
>>> read flash 0x0 0x100
avrdude: jtagmkII_paged_load(.., flash, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
@ [40] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset 0x0000 is nvm_????
. [14] ^ [5e]"read flash" still commands MTYPE_XMEGA_FLASH and zero address. Therefore, I will complete it using the method explained earlier.
If you read this far without getting bored, you should understand why the address rotation problem occurs. That is, the sum of the address field of the READ/WRITE packet and the starting address stored in jtagmkII_set_xmega_params is incorrect. Assuming that this mechanism worked correctly until v7.2, let's analyze the behavior of avrdude_main.
avrdude: Version 7.2-20231031 (76cbf91a)
S_MCU:
boot-loader FW version: 1
firmware version: 7.53
hardware version: 1avrdude: prod_sig_offset addr 0x01100
avrdude: jtagmkII_set_xmega_params(): Sending set Xmega params command:
avrdude: jtagmkII_send(): sending 51 bytes
avrdude: send: . [1b] . [06] . [00]
3 [33] . [00] . [00] . [00]
. [0e] 6 [36] // struct xmega_device_desc {
. [02] . [00] // unsigned char whatever[2]; // cannot guess; must be 0x0002
/ [2f] // unsigned char datalen; // length of the following data, = 47
. [00] . [00] . [00] . [00] // unsigned char nvm_app_offset[4]; // NVM offset for application flash
. [00] . [00] . [00] . [00] // unsigned char nvm_boot_offset[4]; // NVM offset for boot flash
. [00] . [14] . [00] . [00] // unsigned char nvm_eeprom_offset[4]; // NVM offset for EEPROM
. [80] . [12] . [00] . [00] // unsigned char nvm_fuse_offset[4]; // NVM offset for fuses
. [8a] . [12] . [00] . [00] // unsigned char nvm_lock_offset[4]; // NVM offset for lock bits
. [00] . [13] . [00] . [00] // unsigned char nvm_user_sig_offset[4]; // NVM offset for user signature row
. [00] . [11] . [00] . [00] // unsigned char nvm_prod_sig_offset[4]; // NVM offset for production sign. row
. [00] . [00] . [00] . [01] // unsigned char nvm_data_offset[4]; // NVM offset for data memory (SRAM + IO)
. [00] . [00] . [00] . [00] // unsigned char app_size[4]; // size of application flash
. [00] . [00] // unsigned char boot_size[2]; // size of boot flash
@ [40] . [00] // unsigned char flash_page_size[2]; // flash page size
@ [40] . [00] // unsigned char eeprom_size[2]; // size of EEPROM
[20] // unsigned char eeprom_page_size; // EEPROM page size
. [00] . [10] // unsigned char nvm_base_addr[2]; // IO space base address of NVM controller
. [00] . [00] // unsigned char mcu_base_addr[2]; // IO space base address of MCU control
. [8c] { [7b] // } // crc16-ccittxmega_device_desc looks like everything is correct except for the nvm_prod_sig_offset address which has been corrected. If not, I'd be in trouble.
Read the signature byte by byte.
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0a] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b4] // CMND_READ_MEMORY + MTYPE_SIGN_JTAG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [00] . [11] . [00] . [00] // 0x1100 absolute address (attribute IO)
. [15] . [c4]It's okay, same as before.
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [09] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [01] . [0f] . [00] . [01] // 0x0100:0f01 absolute address (attribute IO)
. [93] . [bd]The new "Read Chip Silicon Revision" uses MTYPE_XMEGA_FLASH and absolute addresses. However, nvm_data_offset == 0x01000000 is already added to the address. This has never happened in the past. tinyAVR has 16-bit addressing, so even if it overflows, it will just happen to be the same address and will be missed.
However, this does not work with extended implementations that use the "data" memory setting to pass the exact SRAM starting address to the JTAGICEmkII adapter. (The current UPDI4AVR implementation requires it when writing his USERROW with a locking device.)
avrdude: processing -U fuses:r:block_fuses_updi4avr_avrdude_main.hex:i
avrdude: reading fuses memory ...
avrdude: jtagmkII_paged_load(.., fuses, 10, 10)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 10
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [10] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
. [0a] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [00] . [00] . [00] . [00] // 0x0 absolute address (attribute IO)
. [9c] . [c5]Surprisingly, the fuses memory type has changed from MTYPE_FUSE_BITS to MTYPE_XMEGA_FLASH. This is never normal. The specified address is also 0x0, so it won't be the correct address unless you add nvm_fuse_offset, but since the memory type is wrong, the JTAGICEmkII adapter will return the wrong memory. Compatibility has been broken.
avrdude: processing -U lock:r:block_lock_updi4avr_avrdude_main.hex:i
avrdude: reading lock memory ...
avrdude: jtagmkII_read_byte(.., lock, 0x0, ...)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [11] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [b3] // CMND_READ_MEMORY + MTYPE_LOCK_BITS
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [8a] . [12] . [00] . [00] // 0x1280 absolute address (attribute IO)
. [db] . [8b]It's okay, same as before.
avrdude: processing -U prodsig:r:block_prodsig_updi4avr_avrdude_main.hex:i
avrdude: reading prodsig/sigrow memory ...
avrdude: jtagmkII_paged_load(.., prodsig, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [12] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
= [3d] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_prod_sig_offset == 0x1103
. [bf] . [02]It's okay, same as before.
avrdude: processing -U sernum:r:block_sernum_updi4avr_avrdude_main.hex:i
avrdude: reading sernum memory ...
avrdude: jtagmkII_read_byte(.., sernum, 0x0, ...)
avrdude: in_sigrow addr 0x01103
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [13] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [03] . [11] . [00] . [00] // 0x1103 absolute address (attribute IO)
z [7a] . [0c]Here, the former MTYPE_XMEGA_FLASH has been changed to MTYPE_PRODSIG. This is a correct improvement. Since it is in byte mode, nvm_prod_sig_offset is not added. The result is a valid address.
avrdude: processing -U usersig:r:block_usersig_updi4avr_avrdude_main.hex:i
avrdude: reading userrow/usersig memory ...
avrdude: jtagmkII_paged_load(.., userrow, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [1d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c5] // CMND_READ_MEMORY + MTYPE_USERSIG
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_user_sig_offset == 0x1300
. [ec] . [f7]It's okay, same as before.
avrdude: processing -U eeprom:r:block_eeprom_updi4avr_avrdude_main.hex:i
avrdude: reading eeprom memory ...
avrdude: jtagmkII_paged_load(.., eeprom, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [1e] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] " [22] // CMND_READ_MEMORY + MTYPE_EEPROM
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_eeprom_offset == 0x1400
. [92] . [fb]It's okay, same as before.
avrdude: processing -U flash:r:block_flush_updi4avr_avrdude_main.hex:i
avrdude: reading flash memory ...
avrdude: jtagmkII_paged_load(.., flash, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] [20] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
@ [40] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset 0x0000 is nvm_????
. [9d] . [9f]It's okay, same as before. As before, UPDI_SIB speculation works as intended.
avrdude: processing -t interactive terminal
avrdude> dump prodsig
>>> dump prodsig 0x0 0x40
avrdude: jtagmkII_read_byte(.., prodsig, 0x0, ...)
avrdude: is_sigrow addr 0x01100
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0e] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] � [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [00] . [11] . [00] . [00] // 0x1103 absolute address (attribute IO)
. [1d] � [f1]It's okay, same as before.
avrdude: processing -t interactive terminal
avrdude> dump sernum
>>> dump sernum 0x0 0xa
avrdude: jtagmkII_read_byte(.., sernum, 0x0, ...)
avrdude: in_sigrow addr 0x01103
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] � [c6] // CMND_READ_MEMORY + MTYPE_PRODSIG
. [01] . [00] . [00] . [00] // single byte read (same as terminal mode)
. [03] . [11] . [00] . [00] // 0x1103 absolute address (attribute IO)
� [c1] � [e4]It's okay, same as before. However, the result is different from "reading sernum memory". This is correct.
avrdude: processing -t interactive terminal
avrdude> dump usersig
>>> dump userrow 0x0 0x20
avrdude: jtagmkII_paged_load(.., userrow, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c5] // CMND_READ_MEMORY + MTYPE_USERSIG
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_user_sig_offset == 0x1300
. [0d] � [ff]It's okay, same as before.
avrdude: processing -t interactive terminal
avrdude> dump usersig
>>> dump userrow 0x0 0x20
avrdude: jtagmkII_paged_load(.., userrow, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] � [c5] // CMND_READ_MEMORY + MTYPE_USERSIG
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset is nvm_user_sig_offset == 0x1300
. [0d] � [ff]It's okay, same as before.
avrdude: processing -t interactive terminal
avrdude> dump eeprom
>>> dump eeprom 0x0 0x40
avrdude: jtagmkII_paged_load(.., eeprom, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0e] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] " [22] // CMND_READ_MEMORY + MTYPE_EEPROM
[20] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [14] . [00] . [00] // offset is nvm_eeprom_offset == 0x1400 -> 0x2800
. [87] . [15]Incorrect. Add MTYPE_EEPROM and nvm_eeprom_offset since it is block mode. However, since the address field is not relative zero, it ends up reading from twice the address. Compatibility has been broken.
avrdude: processing -t interactive terminal
avrdude> read flash
>>> read flash 0x0 0x100
avrdude: jtagmkII_paged_load(.., flash, 64, 64)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 64
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: send: . [1b] . [0d] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0] // CMND_READ_MEMORY + MTYPE_XMEGA_FLASH
@ [40] . [00] . [00] . [00] // block read (relative memory mode)
. [00] . [00] . [00] . [00] // offset 0x0000 is nvm_????
. [14] ^ [5e]"read flash" still commands MTYPE_XMEGA_FLASH and zero address. Therefore, I will complete it using the method explained earlier.
This is a test result using avrdude_main with UPDI4AVR and may differ from other JTAGICEmkII + FWV=7 + UPDI implementations. However, compatibility was broken in the following items. It's quite possible that other implementations are similar.
avrdude: Version 7.2-20231031 (76cbf91a)
S_MCU:
boot-loader FW version: 1
firmware version: 7.53
hardware version: 1reading chip silicon revision : Although it is in byte mode with MTYPE_XMEGA_FLASH, nvm_data_offset was already added to the address field. Unable to read from correct IO memory due to address overflow.
reading fuses memory : Since MTYPE_XMEGA_FLASH and block mode were ordered, nvm_fuse_offset cannot be added correctly. Either bytes/blocks should be MTYPE_FUSE_BITS. As with 'dump fuses', byte-oriented and absolute addressing is recommended.
dump eeprom : Although it is MTYPE_EEPROM and block mode, no relative address is specified. The result will be twice the address.
Please refer to the above.
stefanrueger
commented
10 months ago @MCUdude @mcuee: Which programmer expects -c jtag2updi and has FW 7 or above?
MCUdude
commented
10 months ago Which programmer expects -c jtag2updi and has FW 7 or above?
@stefanrueger none that I'm aware of. For reference, I've gathered the FW version of the Arduino Nano Every, Thinary Nano Every and a DIY jtag2updi:
This is the output from my official Arduino Nano Every:
$ ./avrdude -cjtag2updi -patmega4809 -P /dev/cu.usbmodem14101 -r -v
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
avrdude: touching serial port /dev/cu.usbmodem14101 at 1200 baud
avrdude: waiting for new port... using same port /dev/cu.usbmodem14101
Using Port : /dev/cu.usbmodem14101
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkII
AVR Part : ATmega4809
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
[...]
Programmer Type : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 6.00
S_MCU HW version: 1
S_MCU FW version: 6.00
Serial number : 00:00:00:00:00:00
avrdude: silicon revision: 0.1
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9651 (probably m4809)
avrdude done. Thank you.And this is the output from from the Thinary Nano Every (Atmega4808 based):
$ ./avrdude -cjtag2updi -patmega4808 -P /dev/cu.usbserial-1410 -r -v
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
avrdude: touching serial port /dev/cu.usbserial-1410 at 1200 baud
avrdude: waiting for new port... using same port /dev/cu.usbserial-1410
Using Port : /dev/cu.usbserial-1410
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 0a:0b:0c:0d:0e:0f
Device ID: Thinary mkII
AVR Part : ATmega4808
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
[...]
Programmer Type : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 6.00
S_MCU HW version: 1
S_MCU FW version: 6.00
Serial number : 0a:0b:0c:0d:0e:0f
avrdude: silicon revision: 0.1
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9650 (probably m4808)
avrdude done. Thank you.And this is from a DIY jtag2updi I don't know when I flashed with the latest firmware available. Probably a year ago:
$ ./avrdude -cjtag2updi -patmega4808 -P /dev/cu.usbserial-1410 -v
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : /dev/cu.usbserial-1410
Using Programmer : jtag2updi
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkII
AVR Part : ATmega4808
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
[...]
Programmer Type : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 6.00
S_MCU HW version: 1
S_MCU FW version: 6.00
Serial number : 00:00:00:00:00:00
avrdude: silicon revision: 0.1
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9650 (probably m4808)
avrdude done. Thank you.So I don't know of any jtag2updi programmers out there that report themselves as being FW 7.
And when looking at the "official" jtag2updi firmware, there are no traces of FW 7 being mentioned anywhere:
mcuee
commented
10 months ago So I don't know of any jtag2updi programmers out there that report themselves as being FW 7.
Same here. It does not exist as of now.
mcuee
commented
10 months ago Basically jtag2updi FW needs to be updated to support AVR EA/EB. Maybe then it will be called FW 7.
BTW, I do not think JTAGICE mkII and AVR Dragon support UPDI.
stefanrueger
commented
10 months ago @mcuee @MCUdude Thanks! Now the other question is which programmers use -c jtag2pdi (so XMEGA parts) use FW 7 or above?
MCUdude
commented
10 months ago My Dragon uses the JTAG2 protocol use FW 7. And it seems like the JTAGmkII does as well:
$ ./avrdude -cdragon_pdi -patxmega128a3u -v
avrdude: Version 7.2-20230720
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/hans/Downloads/avrdude-terminal/src/avrdude.conf
User configuration file is /Users/hans/.avrduderc
Using Port : usb
Using Programmer : dragon_pdi
avrdude: usbdev_open(): found AVRDRAGON, serno: 00A200000F1A
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 1
S_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 2
Serial number: 00:a2:00:00:0f:1a
Device ID: AVRDRAGON
AVR Part : ATxmega128A3U
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
[...]
Programmer Type : DRAGON_PDI
Description : Atmel AVR Dragon in PDI mode
M_MCU HW version: 1
M_MCU FW version: 7.39
S_MCU HW version: 2
S_MCU FW version: 7.39
Serial number : 00:a2:00:00:0f:1a
Vtarget : 3.3 V
avrdude: silicon revision: 0.6
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9742 (probably x128a3u)
avrdude done. Thank you.OK, summarising: there are no programmers that use jtag2 for UPDI parts with FW > 6. The only jtag2 programmers with FW > 6 cater for XMEGA parts. So, the following lines https://github.com/avrdudes/avrdude/blob/96b081b2f9800b119a88c27bcaba11c5aa32fa16/src/jtagmkII.c#L1288-L1291
really should be replaced by
(PDATA(pgm)->fwver>=0x700 && (p->prog_modes&PM_PDI)? jtagmkII_set_xmega_params: jtagmkII_set_devdescr)(pgm, p);[EDIT: strikethrough]
Comments? @askn37 @mcuee @MCUdude
[EDIT: OK, for the time being, let's keep using set_xmega_params() for FW >= 7.00 and UPDI parts]
MCUdude
commented
10 months ago I'm fine with that as long as it doesn't break anything.
In the really old days, the jtag2updi project just used "vanilla" avrdude 6.3 using the jtagmkii_pdi implementation.
It looks like FW version 6 was chosen just to make Avrdude select jtagmkII_set_devdescr(). However, I'm not sure if jtagmkII_set_xmega_params() would be a requirement if we're would ever see AVR-EA and AVR-EB support. @askn37, which has created updi4avr should have a word I think.
#------------------------------------------------------------
# jtag2updi programmer definitions
#------------------------------------------------------------
programmer
id = "jtag2updi";
desc = "JTAGv2 to UPDI bridge";
type = "jtagmkii_pdi";
connection_type = serial;
baudrate = 115200;
;@askn37 Thanks for your thorough analysis. Looks like FWV=7 only happens with PM_PDI parts, and as such it makes sense that the XMEGA parameters are captured and communication, for example the application and boot offsets (unique to XMEGAs).
Now, seeing that FW=7 + UPDI does not occur with supported AVRDUDE programmers, which project should have authority to extend jtag2updi? There might well be another so far unsupported programmer that has backfitted AVRDUDE behaviour in a different way. And what do we do if somehow an official Microchip successor project for jtagmkII comes about?
I still think it would be better if the updi4avr project submitted a updi4avr.c driver that can be used with -c updi4avr.
"-vvvv" character dump in terminal mode breaks above 0x80. Must be replaced with "."
This is almost certainly a failure of isprint(c) in the corresponding OS. c can be -1 or the range of unsigned char, so characters between 0x80 and 0xff should be allowed. Linux handles this definitely OK. I have now unified the handling of communication traces and pushed a commmit to PR #1538. @mcuee and @MCUdude could you test the traces for
msg_trace2()I have checked posix serial send and receive.
MCUdude
commented
10 months ago @stefanrueger I only have a mac at hand:
Usbhid send and receive (-vvvvv)
https://gist.github.com/MCUdude/4f6e5609928fda35da15ba3c1797b7d5
Usbdev send and reveive (-vvvvv)
https://gist.github.com/MCUdude/dd9e41e04e37cd6168e49b1837f4192b
stefanrueger
commented
10 months ago @MCUdude Brilliant. Will wait for @mcuee's windows runs.
stefanrueger
commented
10 months ago @askn37 I do not see how eeprom access differs between v7.2 and PR #1538 for FW=7 + UPDI. How so?
| reading fuses memory : [...] byte-oriented and absolute addressing is recommended
I think this has happened in the last commit to PR #1538. Please check
| reading chip silicon revision : Although it is in byte mode with MTYPE_XMEGA_FLASH, nvm_data_offset was already added
| dump eeprom : [...] The result will be twice the address.
What do you suggest? Please tell us in a git diff.
mcuee
commented
10 months ago I think this communication trace feature is very useful improvement to debug low level protocol.
The following debug logs are generated using the github action binaries (mingw64 and MSVC64). https://github.com/avrdudes/avrdude/actions/runs/6739037907
Usbdev send and reveive (-vvvvv)
1) usbasp MinGW build with libusb-1.0 API
2) usbasp MSVC build with avrdude-libusb (libusb-0.1 API)
askn37
commented
10 months ago avrdude: Built Version 7.2-20231102 (9c894e15) builting now... Therefore, this information is already outdated.
-avrdude: Version 7.2-arduino.1
+avrdude: Version 7.2-20231031 (76cbf91a)
avrdude> dump eeprom
>>> dump eeprom 0x0 0x40
avrdude: jtagmkII_paged_load(.., eeprom, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
-avrdude: send: . [1b] . [0d] . [00]
-. [0a] . [00] . [00] . [00]
-. [0e] . [05] " [22]
- [20] . [00] . [00] . [00]
-. [00] . [00] . [00] . [00]
-b [62] � [c3]
+avrdude: send: . [1b] . [0e] . [00]
+. [0a] . [00] . [00] . [00]
+. [0e] . [05] " [22]
+ [20] . [00] . [00] . [00]
+. [00] . [14] . [00] . [00]
+. [87] . [15]76cbf91a: This version incorrectly wrote the EEPROM address value directly in the offset field.
-avrdude: Version 7.2-20231031 (76cbf91a)
+avrdude: Version 7.2-20231102 (9c894e15)
avrdude> dump eeprom
>>> dump eeprom 0x0 0x40
avrdude: jtagmkII_paged_load(.., eeprom, 32, 32)
avrdude: jtagmkII_paged_load(): block_size at addr 0 is 32
avrdude: jtagmkII_paged_load(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
-avrdude: send: . [1b] . [0e] . [00]
-. [0a] . [00] . [00] . [00]
-. [0e] . [05] " [22]
- [20] . [00] . [00] . [00]
-. [00] . [14] . [00] . [00]
-. [87] . [15]
+avrdude: ser_send: . [1b] . [0d] . [00]
+. [0a] . [00] . [00] . [00]
+. [0e] . [05] " [22]
+ [20] . [00] . [00] . [00]
+. [00] . [00] . [00] . [00]
+b [62] . [c3]9c894e15: This version reverted to the same behavior as v7.2. It's not a bug anymore.
mcuee
commented
10 months ago Serial send and receive in windows (-vvvv)
1) MinGW build with libserialport, using -c urclock.
2) MSVC build without libserialport, using -c urclock.
mcuee
commented
10 months ago Unfortunately I can not test this one.
Serial send and receive in windows over ethernet (-vvvv) --- these are the net_send() and net_recv() functions
mcuee
commented
10 months ago Usbhid send and receive (-vvvvv) --- one more v the code uses msg_trace2()
1) MinGW build with hidapi
2) MSVC build with hidapi
askn37
commented
10 months ago avrdude: Version 7.2-20231102 (9c894e15)
avrdude: jtagmkII_read_byte(): sending read memory command:
avrdude: jtagmkII_send(): sending 10 bytes
avrdude: ser_send: . [1b] . [09] . [00]
. [0a] . [00] . [00] . [00]
. [0e] . [05] . [c0]
. [01] . [00] . [00] . [00]
. [01] . [0f] . [00] . [01]
. [93] . [bd]
avrdude: jtagmkII_recv():
avrdude: ser_recv: . [1b]
avrdude: ser_recv: . [09]
avrdude: ser_recv: . [00]
avrdude: ser_recv: . [02]
avrdude: ser_recv: . [00]
avrdude: ser_recv: . [00]
avrdude: ser_recv: . [00]
avrdude: ser_recv: . [0e]
avrdude: ser_recv: . [82] . [02]
avrdude: ser_recv: l [6c]
avrdude: ser_recv: . [da]
avrdude: jtagmkII_recv(): got message seqno 9 (command_sequence == 9)
avrdude: jtagmkII_recv: . [82] . [02]
Raw message:
0x82 0x02
memory contents:
0x02
avrdude: jtagmkII_read_chip_rev(): received chip silicon revision: 0x02
avrdude: silicon revision: 0.2
avrdude: AVR device initialized and ready to accept instructionsThis is still a disadvantage for me.
/* Description of AVR067 */
MTYPE_IO_SHADOW = 0x30 // cached IO registers?
MTYPE_SRAM = 0x20 // target's SRAM or [ext.] IO registers
MTYPE_EEPROM = 0x22 // EEPROM, what way?
MTYPE_EVENT = 0x60 // ICE event memory
MTYPE_SPM = 0xA0 // flash through LPM/SPM
MTYPE_FLASH_PAGE = 0xB0 // flash in programming mode
MTYPE_EEPROM_PAGE = 0xB1 // EEPROM in programming mode
MTYPE_FUSE_BITS = 0xB2 // fuse bits in programming mode
MTYPE_LOCK_BITS = 0xB3 // lock bits in programming mode
MTYPE_SIGN_JTAG = 0xB4 // signature in programming mode
MTYPE_OSCCAL_BYTE = 0xB5 // osccal cells in programming mode
MTYPE_CAN = 0xB6 // CAN mailbox
MTYPE_XMEGA_FLASH = 0xC0 // xmega (app.) flash (AVR067: XMEGA_APPLICATION_FLASH)
MTYPE_BOOT_FLASH = 0xC1 // xmega boot flash
MTYPE_EEPROM_XMEGA = 0xC4 // xmega EEPROM in debug mode
MTYPE_USERSIG = 0xC5 // xmega user signature (AVR067: XMEGA_USER_SIGNATURE)
MTYPE_PRODSIG = 0xC6 // xmega production signature (AVR067: XMEGA_CALIBRATION_SIGNATURE)Can someone clearly explain why the IO data memory bus is configured with MTYPE_XMEGA_FLASH=0xC0? This label is originally intended to refer to the code address bus after APPCODE. It must be a coincidence that I happen to be able to read the data bus.
In case you forgot, the AVR is a Harvard architecture, so the code address bus (word granularity) and data address bus (byte granularity) are completely different. Please use them with strict distinction. The same is true for PDI, UPDI, and JTAG. MTYPE is a guideline for that purpose. Don't take it lightly!
mcuee
commented
10 months ago @stefanrueger
Just want to add some debug logs with similar testing devices as @MCUdude, but tested using latest PR #1538 under Windows with MSYS2 mingw64 build wth traces.
Which programmer expects -c jtag2updi and has FW 7 or above?
@stefanrueger none that I'm aware of. For reference, I've gathered the FW version of the Arduino Nano Every, Thinary Nano Every and a DIY jtag2updi:
This is the output from my official Arduino Nano Every:
My debug log. I got slightly newer FW version compared to Hans: S_MCU FW version: 6.07.
You can also see that -r function works fine.
And this is the output from from the Thinary Nano Every (Atmega4808 based):
My debug log under Windows with MSYS2 mingw64 binary (with libserialport)
Same FW version as Hans. S_MCU FW version: 6.00
And this is from a DIY jtag2updi I don't know when I flashed with the latest firmware available. Probably a year ago:
This is my debug log under Windows using MSYS2 ming64 build (with libserialport). Same FW version as Hans. DIY jtag2updi, using a CH340 Uno Clone.
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkIIOne more searial trace for Windows with MSYS2 mingw64 build (with libserialport) using -c serialupdi.
Take note I have to use -b 57600 as this is a known issue with MSYS2 mingw compiler.
mcuee
commented
10 months ago One more usbdev traces for Windows with MSYS2 mingw64 build (with libusb-1.0+libusb-compat-0.1 API) using -c avrispmkii and ATxemga32A4u.
mcuee
commented
10 months ago Can someone clearly explain why the IO data memory bus is configured with MTYPE_XMEGA_FLASH=0xC0? This label is originally intended to refer to the code address bus after
APPCODE. It must be a coincidence that I happen to be able to read the data bus.
@askn37 I think you might have a point.
@stefanrueger
How do I know if the reading of io is correct. The following data look suspicious.
0090 1e 95 41 --> looks like signature.
The following output is from latest PR #1538.
PS>pwd
Path
----
C:\work\avr\avrdude_test\avrdude_bin\github_bin\pr1538\avrdude-mingw-x86_64
PS>.\avrdude -c avrispmkii -p x32a4u -qqt
avrdude> part
AVR Part : ATxmega32A4U
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
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 1 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 1 0 0 0 0x00 0x00
prodsig sigrow 0 0 0 0 no 52 1 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
io 0 0 0 0 no 4096 1 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 1024 32 0 0 0 0x00 0x00
flash 0 0 0 0 no 36864 256 0 0 0 0x00 0x00
application 0 0 0 0 no 32768 256 0 0 0 0x00 0x00
apptable 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
boot 0 0 0 0 no 4096 256 0 0 0 0x00 0x00
usersig 0 0 0 0 no 256 256 0 0 0 0x00 0x00
avrdude> read fuse1
0000 00 |. |
avrdude> read fuse2
0000 63 |c |
avrdude> read fuse4
0000 1e |. |
avrdude> read fuse5
0000 3f |? |
avrdude> read fuse0
0000 55 |U |
avrdude> read lock
0000 ff |. |
avrdude> read sigrow
0000 0d 40 7b 0a 40 7f ff 01 38 55 30 31 35 32 ff ff | @{ @...8U0152..|
0010 03 ff 05 00 16 00 ff ff ff ff cf 07 24 40 ff ff |............$@..|
0020 00 00 00 ff ff ff ff ff ff ff ff ff ff ff 5e 09 |..............^ |
0030 ff ff 02 15 |.... |
avrdude> read prodsig
0000 0d 40 7b 0a 40 7f ff 01 38 55 30 31 35 32 ff ff | @{ @...8U0152..|
0010 03 ff 05 00 16 00 ff ff ff ff cf 07 24 40 ff ff |............$@..|
0020 00 00 00 ff ff ff ff ff ff ff ff ff ff ff 5e 09 |..............^ |
0030 ff ff 02 15 |.... |
avrdude> read signature
0000 1e 95 41 |..A |
avrdude> read eeprom 0 0x10
0000 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 |The quick brown |
avrdude> read flash 0 0x10
0000 fd c0 00 00 18 c1 00 00 16 c1 00 00 14 c1 00 00 |................|
avrdude> read application 0 0x10
0000 fd c0 00 00 18 c1 00 00 16 c1 00 00 14 c1 00 00 |................|
avrdude> read boot 0 0x10
0000 00 c0 00 91 78 00 05 fd 6a c0 f0 92 80 06 08 e1 |....x...j.......|
avrdude> read apptable
0000 d4 cb d0 d0 d5 fd b3 a3 0d 0a 0d 00 c7 eb bd ab |........ .....|
0010 bf a8 b2 e5 c8 eb b2 e5 b2 db bd f8 d0 d0 b2 e2 |................|
0020 ca d4 0d 00 bf a8 b0 b2 d7 b0 ca a7 b0 dc 0d 00 |.. ........... .|
0030 c7 eb b0 ce b3 f6 bf a8 d4 d9 d6 d8 d0 c2 b2 e5 |................|
0040 c8 eb b2 e5 b2 db bd f8 d0 d0 b2 e2 ca d4 0d 00 |.............. .|
0050 43 61 72 64 20 69 6e 66 6f 72 6d 61 74 69 6f 6e |Card information|
0060 3a 0d 00 20 20 20 20 00 53 44 48 43 00 53 44 00 |: . .SDHC.SD.|
0070 4d 4d 43 20 48 69 67 68 20 44 65 6e 73 69 74 79 |MMC High Density|
0080 00 4d 4d 43 00 53 44 49 4f 0d 00 53 44 20 43 4f |.MMC.SDIO .SD CO|
0090 4d 42 4f 00 55 6e 6b 6e 6f 77 0d 00 0d 0a 20 20 |MBO.Unknow . |
00a0 20 20 25 64 20 4d 42 0d 0a 00 4d 6f 75 6e 74 20 | %d MB .Mount |
00b0 64 69 73 6b 20 28 66 5f 6d 6f 75 6e 74 29 2e 2e |disk (f_mount)..|
00c0 2e 0d 00 5b 46 41 49 4c 5d 20 72 65 73 20 25 64 |. .[FAIL] res %d|
00d0 0d 0a 00 5b 4f 4b 5d 0d 00 43 72 65 61 74 65 20 | .[OK] .Create |
00e0 61 20 66 69 6c 65 20 28 66 5f 6f 70 65 6e 29 2e |a file (f_open).|
00f0 2e 2e 0d 00 57 72 69 74 65 20 74 6f 20 74 65 73 |.. .Write to tes|
avrdude> read usersig
0000 55 aa 55 aa 71 75 69 63 6b 20 62 72 6f 77 6e 20 |U.U.quick brown |
0010 66 6f 78 20 6a 75 6d 70 73 20 6f 76 65 72 20 74 |fox jumps over t|
0020 68 65 20 6c 61 7a 79 20 64 6f 67 0a 54 68 65 20 |he lazy dog The |
0030 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 |quick brown fox |
0040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0080 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
00f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
avrdude> read data
avrdude error: (read) cannot read memory data of size 0
avrdude> read io
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 2f 00 |............../.|
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0050 01 00 00 00 7b 02 00 00 00 00 00 00 00 00 00 01 |....{...........|
0060 00 00 40 0a 00 12 7a 00 00 00 40 0d 00 a1 07 00 |..@ ..z...@ ....|
0070 00 00 00 00 00 00 00 00 13 00 00 00 00 00 00 00 |................|
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0090 1e 95 41 04 00 00 00 00 00 00 00 00 00 00 00 00 |..A.............|
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
avrdude> quitMy Dragon uses the JTAG2 protocol use FW 7. And it seems like the JTAGmkII does as well:
@MCUdude
I can confirm that AVR Drago uses the JTAG2 protocol with FW 7. But I can not connect to ATxmega32A4U. I remember AVR Dragon has some limitations when it comes to PDI programming. Or maybe my connection is not stable.
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 1
S_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 2Run log with latest PR #1538 with trace function, MSYS2 mingw64 build with libusb-1.0+libusb-compat-0.1 (WinUSB driver).
PS>.\avrdude -c dragon_pdi -p x32a4u -vvvv
avrdude: Version 7.2-20231102 (3eaa9f2)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is C:\work\avr\avrdude_test\avrdude_bin\github_bin\pr1538\avrdude-mingw-x86_64\avrdude.conf
Using Port : usb
Using Programmer : dragon_pdi
avrdude: jtagmkII_dragon_open_pdi()
avrdude: usbdev_open(): found AVRDRAGON, serno: 00A200001487
avrdude: jtagmkII_getsync()
avrdude: jtagmkII_getsync() attempt 1 of 10: sending sign-on command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: usbdev_send: . [1b] . [00] . [00] . [01] . [00] . [00] . [00] . [0e] . [01] . [f3] . [97]
avrdude: jtagmkII_recv():
avrdude: jtagmkII_recv(): got message seqno 0 (command_sequence == 0)
avrdude: jtagmkII_recv: . [86] . [01] . [ff] ' [27] . [07] . [01] . [ff] ' [27] . [07] . [02] . [00] . [a2] . [00] . [00] . [14] . [87] A [41] V [56] R [52] D [44] R [52] A [41] G [47] O [4f] N [4e] . [00]
Raw message:
0x86 0x01 0xff 0x27 0x07 0x01 0xff 0x27 0x07 0x02 0x00 0xa2 0x00 0x00 0x14 0x87
0x41 0x56 0x52 0x44 0x52 0x41 0x47 0x4f 0x4e 0x00
Sign-on succeeded
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 1
S_MCU:
boot-loader FW version: 255
firmware version: 7.39
hardware version: 2
Serial number: 00:a2:00:00:14:87
Device ID: AVRDRAGON
avrdude: jtagmkII_getsync(): using a 298-byte device descriptor
avrdude: jtagmkII_setparm()
avrdude: jtagmkII_setparm() sending set parameter command (parm emulator_mode 0x03, 1 bytes):
avrdude: jtagmkII_send(): sending 3 bytes
avrdude: usbdev_send: . [1b] . [01] . [00] . [03] . [00] . [00] . [00] . [0e] . [02] . [03] . [06] $ [24] 1 [31]
avrdude: jtagmkII_recv():
avrdude: jtagmkII_recv(): got message seqno 1 (command_sequence == 1)
avrdude: jtagmkII_recv: . [ae]
Raw message:
0xae
unknown message 0xae
avrdude jtagmkII_setparm() [jtagmkII.c:2542] error: bad response to set parameter emulator_mode: Unknown JTAG ICE mkII result code 0xae
avrdude main() [main.c:1280] error: unable to open port usb for programmer dragon_pdi
avrdude done. Thank you.
As the title suggests, after one hardship, another one.
This issue currently occurs when the following combinations are met:
The issue does not occur in the currently released 7.2.
Discovered OS:
A case where a problem occurs.
For normal operation
Comparison between the two
avrdude_conf_fail.txt avrdude_conf_good.txt
Additional Information
I mainly use a self-made implementation using "jtagmkii_updi", and that's where I first discovered the problem. Naturally, I had doubts about my implementation at first, so I also tried his jtag2updi for comparison, and it reproduced the problem.
The difference between the two is whether S_MCU_FW is 6 (jtag2updi) or 7 (updi4avr). The former uses "jtagmkII_set_devdescr" and the latter uses "jtagmkII_set_xmega_params". I don't know of any other implementation that uses this with "jtagmkii_updi"/"jtagmkii_pdi". It probably doesn't matter.
Important things