Comments (11)
Hello, as usual, I would ask for verbose output ('-vvvv') for each of these commands, I need to see the exact communication happening. I must say this looks very, very weird and I don't think I could replicate it easily...
from avrdude.
OK, here the output of $ avrdude -vvvq -p 64ea28 -c serialupdi
when the target is an AVR16EB28
avrdude: Version 7.3-20240520 (a3e4c808)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /usr/local/etc/avrdude.conf
User configuration file is /home/srueger/.avrduderc
Using port : /dev/ttyUSB0
Using programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
AVR Part : AVR64EA28
Programming modes : SPM, UPDI
Memory Size Pg size Offset
-----------------------------------------
eeprom 512 8 0x1400
flash 65536 128 0x800000
fuses 16 1 0x1050
fuse0/wdtcfg 1 1 0x1050
fuse1/bodcfg 1 1 0x1051
fuse2/osccfg 1 1 0x1052
fuse5/syscfg0 1 1 0x1055
fuse6/syscfg1 1 1 0x1056
fuse7/codesize 1 1 0x1057
fuse8/bootsize 1 1 0x1058
lock 4 1 0x1040
prodsig/sigrow 128 128 0x1100
signature 3 1 0x1100
tempsense 4 1 0x1104
sernum 16 1 0x1110
userrow/usersig 64 64 0x1080
io 4160 1 0
sram 6144 1 0x6800
sib 32 1 0
Variants Package F max T range V range
---------------------------------------------------------------
AVR64EA28 SOIC28 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
AVR64EA28-I/SP SPDIP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
AVR64EA28-I/SS SSOP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x35, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x41, 0x30, 0x2e, 0x35, 0x39, 0x42, 0x31, 0x44, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:5D:1-3M2 (A0.59B1D.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:5
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (A0.59B1D.0)
avrdude: NVM type 5: 24-bit, page oriented
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: entering NVM programming mode
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: UPDI writing key
avrdude: sending 2 bytes [0x55, 0xe0]
avrdude: sending 8 bytes [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
avrdude: LDCS from 0x07
avrdude: sending 2 bytes [0x55, 0x87]
avrdude: received 1 bytes [0x10]
avrdude: key status: 0x10
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x28]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: entered NVM programming mode
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 5 bytes [0x55, 0x6a, 0x01, 0x0f, 0x00]
avrdude: received 1 bytes [0x40]
avrdude: LD8 from ptr++
avrdude: sending 2 bytes [0x55, 0x24]
avrdude: received 1 bytes [0x10]
avrdude: Received chip silicon revision 0x10
avrdude: Chip silicon revision: 1.0
avrdude: AVR device initialized and ready to accept instructions
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x)
avrdude main() [main.c:1655] error: Yikes! Invalid device signature.
avrdude main() [main.c:1657] error: expected signature for AVR64EA28 is 1E 96 20
Double check connections and try again, or use -F to override
this check.
avrdude: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude done. Thank you.
And here the output of avrdude -vvvvq -p 64ea28 -c serialupd
avrdude: Version 7.3-20240520 (a3e4c808)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /usr/local/etc/avrdude.conf
User configuration file is /home/srueger/.avrduderc
Using port : /dev/ttyUSB0
Using programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
avrdude: ser_send: . [00]
avrdude: ser_recv: . [00]
AVR Part : AVR64EA28
Programming modes : SPM, UPDI
Memory Size Pg size Offset
-----------------------------------------
eeprom 512 8 0x1400
flash 65536 128 0x800000
fuses 16 1 0x1050
fuse0/wdtcfg 1 1 0x1050
fuse1/bodcfg 1 1 0x1051
fuse2/osccfg 1 1 0x1052
fuse5/syscfg0 1 1 0x1055
fuse6/syscfg1 1 1 0x1056
fuse7/codesize 1 1 0x1057
fuse8/bootsize 1 1 0x1058
lock 4 1 0x1040
prodsig/sigrow 128 128 0x1100
signature 3 1 0x1100
tempsense 4 1 0x1104
sernum 16 1 0x1110
userrow/usersig 64 64 0x1080
io 4160 1 0
sram 6144 1 0x6800
sib 32 1 0
Variants Package F max T range V range
---------------------------------------------------------------
AVR64EA28 SOIC28 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
AVR64EA28-I/SP SPDIP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
AVR64EA28-I/SS SSOP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: ser_send: U [55] . [c3] . [08]
avrdude: ser_recv: U [55] . [c3] . [08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: ser_send: U [55] . [c2] . [80]
avrdude: ser_recv: U [55] . [c2] . [80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: ser_send: U [55] . [80]
avrdude: ser_recv: U [55] . [80]
avrdude: ser_recv: 0 [30]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [82]
avrdude: received 1 bytes [0x82]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: ser_send: U [55] . [e6]
avrdude: ser_recv: U [55] . [e6]
avrdude: ser_recv: A [41] V [56] R [52] [20] [20] [20] [20] [20] P [50] : [3a] 5 [35] D [44] : [3a] 1 [31] - [2d] 3 [33] M [4d] 2 [32] [20] ( [28] A [41] 0 [30] . [2e] 5 [35] 9 [39] B [42] 1 [31] D [44] . [2e] 0 [30] ) [29] . [00]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x35, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x41, 0x30, 0x2e, 0x35, 0x39, 0x42, 0x31, 0x44, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:5D:1-3M2 (A0.59B1D.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:5
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (A0.59B1D.0)
avrdude: NVM type 5: 24-bit, page oriented
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: ser_send: U [55] . [c3] . [08]
avrdude: ser_recv: U [55] . [c3] . [08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: ser_send: U [55] . [c2] . [80]
avrdude: ser_recv: U [55] . [c2] . [80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: ser_send: U [55] . [80]
avrdude: ser_recv: U [55] . [80]
avrdude: ser_recv: 0 [30]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: entering NVM programming mode
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [82]
avrdude: received 1 bytes [0x82]
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: ser_send: U [55] . [c8] Y [59]
avrdude: ser_recv: U [55] . [c8] Y [59]
avrdude: UPDI writing key
avrdude: sending 2 bytes [0x55, 0xe0]
avrdude: ser_send: U [55] . [e0]
avrdude: ser_recv: U [55] . [e0]
avrdude: sending 8 bytes [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
avrdude: ser_send: [20] g [67] o [6f] r [72] P [50] M [4d] V [56] N [4e]
avrdude: ser_recv: [20] g [67] o [6f] r [72] P [50] M [4d] V [56] N [4e]
avrdude: LDCS from 0x07
avrdude: sending 2 bytes [0x55, 0x87]
avrdude: ser_send: U [55] . [87]
avrdude: ser_recv: U [55] . [87]
avrdude: ser_recv: . [10]
avrdude: received 1 bytes [0x10]
avrdude: key status: 0x10
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: ser_send: U [55] . [c8] Y [59]
avrdude: ser_recv: U [55] . [c8] Y [59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: ser_send: U [55] . [c8] . [00]
avrdude: ser_recv: U [55] . [c8] . [00]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: ( [28]
avrdude: received 1 bytes [0x28]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [08]
avrdude: received 1 bytes [0x08]
avrdude: entered NVM programming mode
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 5 bytes [0x55, 0x6a, 0x01, 0x0f, 0x00]
avrdude: ser_send: U [55] j [6a] . [01] . [0f] . [00]
avrdude: ser_recv: U [55] j [6a] . [01] . [0f] . [00]
avrdude: ser_recv: @ [40]
avrdude: received 1 bytes [0x40]
avrdude: LD8 from ptr++
avrdude: sending 2 bytes [0x55, 0x24]
avrdude: ser_send: U [55] $ [24]
avrdude: ser_recv: U [55] $ [24]
avrdude: ser_recv: . [10]
avrdude: received 1 bytes [0x10]
avrdude: Received chip silicon revision 0x10
avrdude: Chip silicon revision: 1.0
avrdude: AVR device initialized and ready to accept instructions
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [08]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [08]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: ser_send: U [55] . [8b]
avrdude: ser_recv: U [55] . [8b]
avrdude: ser_recv: . [08]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [00] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [01] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: ser_send: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: U [55] . [08] . [02] . [11] . [00]
avrdude: ser_recv: . [ff]
avrdude: received 1 bytes [0xff]
avrdude: device signature = 0xffffff (probably .avr8x)
avrdude main() [main.c:1655] error: Yikes! Invalid device signature.
avrdude main() [main.c:1657] error: expected signature for AVR64EA28 is 1E 96 20
Double check connections and try again, or use -F to override
this check.
avrdude: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: ser_send: U [55] . [c8] Y [59]
avrdude: ser_recv: U [55] . [c8] Y [59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: ser_send: U [55] . [c8] . [00]
avrdude: ser_recv: U [55] . [c8] . [00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude: ser_send: U [55] . [c3] . [0c]
avrdude: ser_recv: U [55] . [c3] . [0c]
avrdude done. Thank you.
Thanks for looking into this
from avrdude.
And, just for comparison, the output when the command line is corrected to -c 16eb28
and therefore matches the target:
avrdude -vvvq -p 16eb28 -c serialupdi
avrdude: Version 7.3-20240520 (a3e4c808)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /usr/local/etc/avrdude.conf
User configuration file is /home/srueger/.avrduderc
Using port : /dev/ttyUSB0
Using programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
AVR Part : AVR16EB28
Programming modes : SPM, UPDI
Memory Size Pg size Offset
-----------------------------------------
eeprom 512 8 0x1400
flash 16384 64 0x800000
fuses 16 1 0x1050
fuse0/wdtcfg 1 1 0x1050
fuse1/bodcfg 1 1 0x1051
fuse2/osccfg 1 1 0x1052
fuse5/syscfg0 1 1 0x1055
fuse6/syscfg1 1 1 0x1056
fuse7/codesize 1 1 0x1057
fuse8/bootsize 1 1 0x1058
fusea/pdicfg 2 1 0x105a
lock 4 1 0x1040
prodsig/sigrow 128 128 0x1080
signature 3 1 0x1080
tempsense 4 1 0x1084
sernum 16 1 0x1090
bootrow 64 64 0x1100
userrow/usersig 64 64 0x1200
io 4160 1 0
sram 2048 1 0x7800
sib 32 1 0
Variants Package F max T range V range
---------------------------------------------------------------------
AVR16EB28-SSOP/SPDIP SOIC28 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
AVR16EB28-VQFN VQFN28 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x35, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x41, 0x30, 0x2e, 0x35, 0x39, 0x42, 0x31, 0x44, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:5D:1-3M2 (A0.59B1D.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:5
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (A0.59B1D.0)
avrdude: NVM type 5: 24-bit, page oriented
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: entering NVM programming mode
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: UPDI writing key
avrdude: sending 2 bytes [0x55, 0xe0]
avrdude: sending 8 bytes [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
avrdude: LDCS from 0x07
avrdude: sending 2 bytes [0x55, 0x87]
avrdude: received 1 bytes [0x10]
avrdude: key status: 0x10
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x28]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: entered NVM programming mode
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 5 bytes [0x55, 0x6a, 0x01, 0x0f, 0x00]
avrdude: received 1 bytes [0x40]
avrdude: LD8 from ptr++
avrdude: sending 2 bytes [0x55, 0x24]
avrdude: received 1 bytes [0x10]
avrdude: Received chip silicon revision 0x10
avrdude: Chip silicon revision: 1.0
avrdude: AVR device initialized and ready to accept instructions
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001080
avrdude: sending 5 bytes [0x55, 0x08, 0x80, 0x10, 0x00]
avrdude: received 1 bytes [0x1e]
avrdude: LD from 0x001081
avrdude: sending 5 bytes [0x55, 0x08, 0x81, 0x10, 0x00]
avrdude: received 1 bytes [0x94]
avrdude: LD from 0x001082
avrdude: sending 5 bytes [0x55, 0x08, 0x82, 0x10, 0x00]
avrdude: received 1 bytes [0x3f]
avrdude: device signature = 0x1e943f (probably 16eb28)
avrdude: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude done. Thank you.
And here the output when the target was switched to an AVR64EA28 (and matches with the following command line):
avrdude -vvvq -p 64ea28 -c serialupdi
avrdude: Version 7.3-20240520 (a3e4c808)
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /usr/local/etc/avrdude.conf
User configuration file is /home/srueger/.avrduderc
Using port : /dev/ttyUSB0
Using programmer : serialupdi
avrdude: opening serial port ...
avrdude: sending 1 bytes [0x00]
AVR Part : AVR64EA28
Programming modes : SPM, UPDI
Memory Size Pg size Offset
-----------------------------------------
eeprom 512 8 0x1400
flash 65536 128 0x800000
fuses 16 1 0x1050
fuse0/wdtcfg 1 1 0x1050
fuse1/bodcfg 1 1 0x1051
fuse2/osccfg 1 1 0x1052
fuse5/syscfg0 1 1 0x1055
fuse6/syscfg1 1 1 0x1056
fuse7/codesize 1 1 0x1057
fuse8/bootsize 1 1 0x1058
lock 4 1 0x1040
prodsig/sigrow 128 128 0x1100
signature 3 1 0x1100
tempsense 4 1 0x1104
sernum 16 1 0x1110
userrow/usersig 64 64 0x1080
io 4160 1 0
sram 6144 1 0x6800
sib 32 1 0
Variants Package F max T range V range
---------------------------------------------------------------
AVR64EA28 SOIC28 20 MHz [-40 C, 125 C] [1.8 V, 5.5 V]
AVR64EA28-I/SP SPDIP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
AVR64EA28-I/SS SSOP28 20 MHz [-40 C, 85 C] [1.8 V, 5.5 V]
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: UPDI link initialization OK
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending 2 bytes [0x55, 0xe6]
avrdude: received 32 bytes [0x41, 0x56, 0x52, 0x20, 0x20, 0x20, 0x20, 0x20, 0x50, 0x3a, 0x33, 0x44, 0x3a, 0x31, 0x2d, 0x33, 0x4d, 0x32, 0x20, 0x28, 0x42, 0x31, 0x2e, 0x35, 0x39, 0x46, 0x30, 0x32, 0x2e, 0x30, 0x29, 0x00]
avrdude: received SIB: [AVR P:3D:1-3M2 (B1.59F02.0)]
avrdude: Device family ID: AVR
avrdude: NVM interface: P:3
avrdude: Debug interface: D:1
avrdude: PDI oscillator: 3M2
avrdude: Extra information: (B1.59F02.0)
avrdude: NVM type 3: 24-bit, page oriented
avrdude: STCS 0x08 to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x08]
avrdude: STCS 0x80 to address 0x02
avrdude: sending 3 bytes [0x55, 0xc2, 0x80]
avrdude: LDCS from 0x00
avrdude: sending 2 bytes [0x55, 0x80]
avrdude: received 1 bytes [0x30]
avrdude: UDPI init OK
avrdude: entering NVM programming mode
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x82]
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: UPDI writing key
avrdude: sending 2 bytes [0x55, 0xe0]
avrdude: sending 8 bytes [0x20, 0x67, 0x6f, 0x72, 0x50, 0x4d, 0x56, 0x4e]
avrdude: LDCS from 0x07
avrdude: sending 2 bytes [0x55, 0x87]
avrdude: received 1 bytes [0x10]
avrdude: key status: 0x10
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x28]
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: entered NVM programming mode
avrdude: reading 1 bytes from 0x000F01
avrdude: ST_PTR to 0x000F01
avrdude: sending 5 bytes [0x55, 0x6a, 0x01, 0x0f, 0x00]
avrdude: received 1 bytes [0x40]
avrdude: LD8 from ptr++
avrdude: sending 2 bytes [0x55, 0x24]
avrdude: received 1 bytes [0x21]
avrdude: Received chip silicon revision 0x21
avrdude: Chip silicon revision: 2.1
avrdude: AVR device initialized and ready to accept instructions
avrdude: LDCS from 0x0B
avrdude: sending 2 bytes [0x55, 0x8b]
avrdude: received 1 bytes [0x08]
avrdude: LD from 0x001100
avrdude: sending 5 bytes [0x55, 0x08, 0x00, 0x11, 0x00]
avrdude: received 1 bytes [0x1e]
avrdude: LD from 0x001101
avrdude: sending 5 bytes [0x55, 0x08, 0x01, 0x11, 0x00]
avrdude: received 1 bytes [0x96]
avrdude: LD from 0x001102
avrdude: sending 5 bytes [0x55, 0x08, 0x02, 0x11, 0x00]
avrdude: received 1 bytes [0x20]
avrdude: device signature = 0x1e9620 (probably 64ea28)
avrdude: leaving NVM programming mode
avrdude: sending reset request
avrdude: STCS 0x59 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x59]
avrdude: sending release reset request
avrdude: STCS 0x00 to address 0x08
avrdude: sending 3 bytes [0x55, 0xc8, 0x00]
avrdude: STCS 0x0C to address 0x03
avrdude: sending 3 bytes [0x55, 0xc3, 0x0c]
avrdude done. Thank you.
from avrdude.
@stefanrueger sorry, but I don't have good news for you, this is something that can't really be fixed.
See, the problem is that when initiating connection with the MCU using SerialUPDI the signature is read from arbitrary location in memory. For AVR16EBxx chips SIGROW memory is at 0x1080, while for AVR64EAxx chips it's 0x1100. This is why when you specify incorrect part but with identical memory map (and most of these guys use 0x1100: https://github.com/avrdudes/avrdude/blob/main/src/avrdude.conf.in#L20263) then AVRDUDE reads the correct signature and responds with reasonable error proposing correct part.
In your case it reads from a totally different memory (0x1100 in AVR16EBxx is BOOTROW), gets meaningless data and doesn't know how to recover from this, nor is able to suggest anything else. If there was any way to ask the chip for its memory map, we could do it instead, but unfortunately, no such option is available AFAIK.
Let me know if my explanation is not clear, I will try to explain it better.
from avrdude.
@dbuchwald Great analysis. Thanks. OK, it's like writing the title of a book onto one of two different page numbers (or more than two ... depending on how many different memory layouts Microchip is going to entertain in future), which makes it a bit hard for the reader to figure out what the title of the book is.
@askn37 Do you have more insight into how, given a UPDI chip, the signature can be read unambiguously? Is there some info in the sib
that could help?
0x1080 is used as memory address for the AVR-DU and AVR-EB parts: run avrdude -p*/St | grep signature.*off | grep 0x1080 | grep -v " "
. It's 0x1100 for all other UPDI parts.
from avrdude.
AFAIK, only the AVR-DU and AVR-EB has their signature at 0x1080, and these are the only chips with NVMv4 and NVMv5. So the SIB could be read to determine the NVM version, and then figure out the correct address if Avrdude is reading the signature as 0xffffff.
BTW this is also a problem for jtag3 based programmers as well:
$ ./avrdude -cpkobn_updi -pavr64dd32 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: device signature = 0xffffff (probably .avr8x) (retrying)
avrdude: device signature = 0xffffff (probably .avr8x)
avrdude error: Yikes! Invalid device signature.
avrdude error: expected signature for AVR64DD32 is 1E 96 1A
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Hanss-MacBook-Pro:src hans$ ./avrdude -cpkobn_updi -pavr16eb32 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e943e (probably avr16eb32)
avrdude: processing -t interactive terminal
avrdude> read sib
from avrdude.
When taking a closer look at the jtag3 and serialupdi source code, it appears that these programmers reads the SIB before reading the device signature. So after a failed signature read attempt (signature does not start with 0x1e), we may use the NVM version number to find the correct offset for the signature/prodsig memory.
When trying to read an AVR16EB32 when an AVR128DA32 is connected, I'm getting this weird signature. So a check against 0x1e may be a suitable solution.
$ ./avrdude -cserialupdi -pavr16eb32 -P /dev/cu.usbserial-1410
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x242f34
avrdude error: expected signature for AVR16EB32 is 1E 94 3E
double check chip or use -F to override this check
avrdude done. Thank you.
from avrdude.
This problem of poor part selection cannot be solved unless you read UPDI_SIB before reading PROD_SIGNATURE to determine the NVM version.
Currently, the only protocols (as far as I know) that actually support this are SerialUPDI and JTAGmk3. Microchip has added modern UPDI support to these, but it is not documented. On the other hand, older protocols such as JTAGmk2 and STK600 do not define a mechanism to return UPDI_SIB to AVRDUDE and are not maintained by Microchip at all.
Older programmers will need their own extensions to add modern support. For example, JTAG2UPDI and UPDI4AVR firmware read UPDI_SIB before reading PROD_SIG to assist with subsequent operations. This is because there is no publicly known mechanism for AVRDUDE to inform firmware of the NVM version.
For UPDI4AVR only, with a small change to avrdude.conf, you can signal the NVM version and control information via unused areas in the device descriptor to support correct high-voltage programming. This is really something special.
from avrdude.
My take on the idea to base the error message on the NVM controller version is that we shouldn't do it. Given all the inconsistencies between latest AVR chips and their respective NVM controllers I wouldn't be surprised if that wasn't the last case we saw. All of these "ifs/elses" will end up being unmanageable spaghetti that nobody understands and everyone is afraid to remove even after NVM v3/v5 chips are no longer produced nor sold. I see that kind of tech debt in my work daily and I see how it gradually slows down value delivery to a grinding halt.
That being said, if you want me to implement this feature I will do so, it's just that my instinct tells me it's not a good idea.
from avrdude.
Thanks all round @dbuchwald @MCUdude @askn37 for input. I feel we definitely have to do something, if only to change the error message to add "check whether the part is correctly specified". Right now, one of the recommendations is -F
which can lead to tears as programming would proceed under wrong assumptions. It is amazing that Microchip finds new and innovative ways beyond the known reuse of signatures to make it hard to use them for part identification.
I also feel that AVRDUDE could give better advice than telling the user to specify the correct part number (the gadget housing the MCU may be difficult to open, the printing on the MCU illegible, the user may simply misremember but be convinced it is the wrong part).
When given the wrong -p
UPDI part, the UPDI programmers read (correctly, without problems and without encountering an error) three bytes, but possibly from the wrong memory (0x1100 vs 0x1080). Fun fact: as the other memory is at least in one case writable (bootrow) one could therefore spoof this MCU to be a different one. Normally, however, one wouldn't expect a valid UPDI signature in the wrong place. So, some instance outside the individual -c
programmer code (say, the avr_signature()
function in avr.c
might well check whether what the -c
programmer code read without error is a plausible signature, eg, check against known full signatures, check first byte against all known first bytes (currently only 1e
and ed
). If not, see what would happen if the specified UPDI part was a different one with another signature memory address.
Another fun fact: There must have been a similar problem in the past b/c there is code in main.c
that reads sib
and makes a comparison with the AVR_FAMILY
:
Lines 1575 to 1603 in a3e4c80
Anyone know what this was about?
from avrdude.
Anyone know what this was about?
The family ID is pretty much useless. It started out with tinyAVR
and megaAVR
, but when the AVR-DA were introduced they used " AVR" (that's four leading spaces). Later they "fixed" this error, and the later generations are now "AVR " (that's four trailing spaces). Why they couldn't use the actual family name is unclear, but it's way too late to change now.
I suggest mentioning that the user should double check the -p
part name and try again if Avrdude is able to read a signature, but it's incorrect, if trying to communicate with a UPDI part.
from avrdude.
Related Issues (20)
- "jtag2 is not a unique start of a programmer name"
- `-F` option not honored
- Add support for more AVR-DU parts HOT 2
- Add support for emscripten HOT 6
- Trouble with Raspberry pi 5 HOT 13
- linuxgpio sysfs fallback improvement to deal with shifted GPIO numbering in new kernel version HOT 1
- usbasp_write_byte in TPI mode; all writes have to be done at page level HOT 15
- cmake enabling LINUXGPIO on ubuntu 20.04 fails HOT 4
- arduino uno atmga328p HOT 2
- macOS github action failed. HOT 9
- CMake improvement -- using pkg-find to find the libraries HOT 1
- format mismatch warnings HOT 3
- Misleading error message: cannot find programmer id
- custom programmer broken in v7.3 HOT 4
- ATtiny11 does not have EEPROM
- Multi-memory files HOT 13
- AVRDUDE fails to return -1 on certain write byte errors
- UPDI with AtmelICE, how to? HOT 6
- Parallel port silently not working HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from avrdude.