Closed mcuee closed 1 year ago
I am not so sure if #379 is similar or not. I do not have access to RF AVR parts.
@MCUdude
Please help to check with your programmers and XMEGA parts to see if you have the same issues or not. Thanks.
I can confirm that this is an issue with the Power Debugger as well:
$ ./avrdude -cpowerdebugger_pdi -patxmega128a3u -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9742 (probably x128a3u)
avrdude> read usersig
Reading | ################################################## | 100% 0.42 s
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
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> write usersig 0 0x10
Writing | -------------------------------------------------- | 0% 0.00 s
avrdude error: (write) verification error writing 0x10 at 0x00000 cell=0xff
avrdude>
However, userrow/usersig works with UPDI targets:
$ ./avrdude -cpkobn_updi -patmega4809 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9651 (probably m4809)
avrdude> read usersig
Reading | ################################################## | 100% 0.26 s
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
avrdude> write usersig 0 "Hello World!"
Writing | ################################################## | 100% 0.19 s
avrdude> read usersig
Reading | ################################################## | 100% 0.26 s
0000 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 ff ff ff |Hello World!....|
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
avrdude> quit
avrdude done. Thank you.
@stefanrueger has the comment here, which may explain why UPDI parts like ATmega4809 works.
#------------------------------------------------------------
# AVR8X mega family common values
#------------------------------------------------------------
part parent ".avr8x"
desc = "AVR8X mega family common values";
id = ".avr8x_mega";
family_id = "megaAVR";
# Dedicated UPDI pin, no HV
hvupdi_variant = 1;
memory "userrow"
size = 64;
page_size = 64;
offset = 0x1300;
readsize = 256;
;
memory "usersig"
alias "userrow";
;
;
However, the simple patch from the comment by @stefanrueger does not work yet becaue of the cache size.
PS C:\work\avr\avrdude_test\avrdude_sr> git diff
diff --git a/src/avr.c b/src/avr.c
index ea80f4c..070ad30 100644
--- a/src/avr.c
+++ b/src/avr.c
@@ -1375,6 +1375,8 @@ int avr_memtype_is_flash_type(const char *memtype) {
strcmp(memtype, "flash") == 0 ||
strcmp(memtype, "application") == 0 ||
strcmp(memtype, "apptable") == 0 ||
+ strcmp(memtype, "usersig") == 0 ||
+ strcmp(memtype, "userrow") == 0 ||
strcmp(memtype, "boot") == 0);
}
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1360mod -C .\avrdude_pr1360.conf -c avrispmkii -p x32a4u -t
avrdude_pr1360mod: AVR device initialized and ready to accept instructions
avrdude_pr1360mod: device signature = 0x1e9541 (probably x32a4u)
avrdude> dump usersig
Reading | -------------------------------------------------- | 0% 0.00 s
avrdude_pr1360mod error: usersig cache address 0xe0400 out of range [0, 0x8fff]
avrdude_pr1360mod error: (dump) error reading usersig address 0x00000 of part ATxmega32A4U
read operation not supported on memory type usersig
avrdude> write usersig 0 0xaa
Caching | -------------------------------------------------- | 0% 0.00 s
avrdude_pr1360mod error: usersig cache address 0xe0400 out of range [0, 0x8fff]
avrdude_pr1360mod error: (write) error writing 0xaa at 0x00000, rc=-1
write operation not supported on memory type usersig
avrdude> quit
avrdude_pr1360mod done. Thank you.
@mcuee The curiosity is getting the better of me: If you do similar changes for the ATxmega32A4U's usersig
memory, can it be written to then?
@mcuee The curiosity is getting the better of me: If you do similar changes for the ATxmega32A4U's
usersig
memory, can it be written to then?
I think it has already the memory definition.
#------------------------------------------------------------
# ATxmega32A4U
#------------------------------------------------------------
part parent ".xmega-a"
desc = "ATxmega32A4U";
id = "x32a4u";
variants =
"ATxmega32A4U-AN: TQFP44, Fmax=32 MHz, T=[0 C, 105 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-ANR: TQFP44, Fmax=32 MHz, T=[0 C, 105 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-AU: TQFP44, Fmax=32 MHz, T=[-40 C, 85 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-AUR: TQFP44, Fmax=32 MHz, T=[-40 C, 85 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-CU: BGA49, Fmax=32 MHz, T=[-40 C, 85 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-CUR: VFBGA49, Fmax=N/A, T=[N/A, N/A], Vcc=[N/A, N/A]",
"ATxmega32A4U-M7: VQFN44, Fmax=32 MHz, T=[-40 C, 105 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-MH: QFN44, Fmax=32 MHz, T=[-40 C, 85 C], Vcc=[1.6 V, 3.6 V]",
"ATxmega32A4U-MHR: VQFN44, Fmax=32 MHz, T=[-40 C, 85 C], Vcc=[1.6 V, 3.6 V]";
mcuid = 239;
n_interrupts = 127;
boot_section_size = 4096;
signature = 0x1e 0x95 0x41;
usbpid = 0x2fe4;
memory "eeprom"
size = 1024;
page_size = 32;
offset = 0x8c0000;
readsize = 256;
;
memory "flash"
size = 0x9000;
page_size = 256;
offset = 0x800000;
readsize = 256;
;
memory "application"
size = 0x8000;
page_size = 256;
offset = 0x800000;
readsize = 256;
;
memory "apptable"
size = 4096;
page_size = 256;
offset = 0x807000;
readsize = 256;
;
memory "boot"
size = 4096;
page_size = 256;
offset = 0x808000;
readsize = 256;
;
memory "fuse4"
initval = 0xfe;
;
memory "usersig"
size = 256;
page_size = 256;
offset = 0x8e0400;
readsize = 256;
;
;
@stefanrueger
I think we only need to fix the following issue. But I do not know how to fix it myself.
usersig cache address 0xe0400 out of range [0, 0x8fff]
becaue of the cache size
Good shout! So, for the terminal this needs more programming to bring usersig
into the flash
memory cache regime. What about the command line? -U usersig:w:file
userrow/usersig works with UPDI targets
Interesting. The terminal does not cache these memories, so the UPDI programmer probably is able to do bytewise r/w?
becaue of the cache size
Good shout! So, for the terminal this needs more programming to bring
usersig
into theflash
memory cache regime. What about the command line?-U usersig:w:file
That works fine. So I change the title to terminal mode.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avrispmkii -p x32a4u -U usersig:w:entest_64B.hex:i
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9541 (probably x32a4u)
avrdude: Note: programmer supports page erase for Xmega devices.
Each page will be erased before programming it, but no chip erase is performed.
To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file entest_64B.hex for usersig
with 64 bytes in 1 section within [0, 0x3f]
using 1 page and 192 pad bytes
avrdude: writing 64 bytes usersig ...
Writing | ################################################## | 100% 0.02 s
avrdude: 64 bytes of usersig written
avrdude: verifying usersig memory against entest_64B.hex
Reading | ################################################## | 100% 0.01 s
avrdude: 64 bytes of usersig verified
avrdude done. Thank you.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c avrispmkii -p x32a4u -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9541 (probably x32a4u)
avrdude> dump usersig
Reading | ################################################## | 100% 0.41 s
0000 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 |The 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> quit
avrdude done. Thank you.
The memories below all have more than 9 bytes, so are potentially of the kind that might not deal gracefully with bytewise read/write. AVRDUDE has implemented a terminal cache for only 5 of these. Of the other five memories only two are writeable and need special cache treatment b/c somehow programmers cannot do bytewise read/write.
Number of avrdude parts that have this particular memory
Memory | exotic | TPI | ISP | PDI | UPI | Cache |
---|---|---|---|---|---|---|
application | 50 | ✓ | ||||
apptable | 50 | ✓ | ||||
boot | 50 | ✓ | ||||
eeprom | 2 | 186 | 50 | 91 | ✓ | |
flash | 4 | 8 | 188 | 50 | 91 | ✓ |
prodsig | 50 | 91 | read only | |||
sernum | 91 | read only | ||||
sigrow | 2 | read only | ||||
userrow | 91 | ❌ | ||||
usersig | 50 | ❌ |
@stefanrueger
In this case, using -c dryrun
is not able to reproduce the issue. I am not sure if you can enhance -c dryrun
so that it can reproduce the issue.
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dryrun -p x32a4u -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9541 (probably x32a4u)
avrdude> dump usersig
Reading | ################################################## | 100% 0.30 s
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 00 00 00 |................|
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0070 00 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
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> write usersig 0 0xaa
Writing | ################################################## | 100% 0.00 s
avrdude> dump usersig
Reading | ################################################## | 100% 0.27 s
0000 aa 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 00 00 00 |................|
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0070 00 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
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> quit
avrdude done. Thank you.
-c dryrun is not able to reproduce the issue
That's fair enough. Terminal code uses bytewise access to memories only, and was traditionally not able to deal with paged memories. When the terminal implemented a cache that translates bytewise access to paged access for paged memories, the usersig
memory was not dealt with. It is "simply" a case of providing a cache for that memory in terminal. There is no way a programmer (which is what dryrun is) can have that level of detail about AVRDUDE working.
Somehow avrdude can only read but not write user signature row of the XMEGA part, tested with AVRISP mkII and ATxmega32A4U.