jtagmkII_set_devdescr() sends wrong eecr value to physical programmer (EEPROM access fails?)

stefanrueger commented 2 years ago

While reviewing how eecr is used in AVRDUDE's code I came across two peculiarities:

The documentation in avrdude.conf promises to treat an unset value with the default of 0x3c, which should be 0x3f
jtagmkII_set_devdescr() in jtagmkII.c sends the value straight from avrdude.conf without recognising unset 0 means 0x3f

Don't know which parts/programmers etc are affected, but if the sent wrong EECR address sent by AVRDUDE is used by the programmer this might lead to problems for EEPROM access. I will fix both peculiarities with my next PR in the next few days (the main job of that PR will be a subtle but important update of the PROGRAMMER interface, stay tuned).

MCUdude commented 2 years ago

I'm not sure if it is a coincidence or not, but the jtag2updi programmer can't read or write EEPROM in terminal mode.

But IIRC, my AVR Dragon can, and that's using the jtagmkii protocol as well...

stefanrueger commented 2 years ago

Try setting eecr = 0x3f for the part in avrdude.conf. If that makes a difference then it's likely brought about by this issue.

stefanrueger commented 2 years ago

It is always a possibility that the FW of any programmer using this interface ignores the eecr value sent by AVRDUDE or operates a logic of "if it's 0 it'll be 0x3f". I don't think there is a part with EECR register where the register address differs from 0x3f

Edit: there are two different values: 0x3c and 0x3f, see below

mcuee commented 2 years ago

I'm not sure if it is a coincidence or not, but the jtag2updi programmer can't read or write EEPROM in terminal mode.

But IIRC, my AVR Dragon can, and that's using the jtagmkii protocol as well...

I tend to think that there are some slightly different implementations of jtag2updi itself and the behavior may be a bit different. 1) main implementation: https://github.com/ElTangas/jtag2updi (issue with EEPROM in terminal mode?) 2) Arduino's port using SAM D11: https://github.com/arduino/ArduinoCore-megaavr/tree/master/firmwares/MuxTO (seems to be problematic with EEPROM in general) 3) Nano 4808 implementation (maybe similar to 1): https://github.com/Thinary/ThinaryArduino/tree/master/Thinary-megaavr (seems to perform better, even in terminal mode)

Reference:

https://github.com/avrdudes/avrdude/issues/1069

mcuee commented 2 years ago

It is always a possibility that the FW of any programmer using this interface ignores the eecr value sent by AVRDUDE or operates a logic of "if it's 0 it'll be 0x3f".

From the search that jtag3.c is doing that. https://github.com/avrdudes/avrdude/search?q=eecr

https://github.com/avrdudes/avrdude/blob/affe4cb50a42c34a873be9bde8b5e650032cdcb5/src/jtag3.c#L1368-L1369

    if (p->eecr == 0)
      p->eecr = 0x3f;       /* matches most "modern" mega/tiny AVRs */

I don't think there is a part with EECR register where the register address differs from 0x3f

@stefanrueger It seems to me the old one may not, eg: AT90S1200. http://ww1.microchip.com/downloads/en/DeviceDoc/DOC0838.PDF

Page 10 shows EECR address is 0x3c.

Same for AT90S2313, ATTiny2313, ATmega8535, ATmega8/16/32/64/128, etc.

So the codes in jtag3.c is not really correct either.

mcuee commented 2 years ago

Ref: https://github.com/avrdudes/avrdude/blob/main/src/avrdude.conf.in#L119

#       eecr             = <num> ;               # mem addr of EECR reg only when != 0x3c

Since the traditional AVRs use 0x3c and modern AVRs use 0x3f, looks like the above comment needs to be changed. And we can not just leave the entry not populated if jtagmkII.c and jtag3.c really use the value.

stefanrueger commented 2 years ago

@mcuee Yes, you are right. The atdf sheets tell us that there are two different EECR register addresses (on parts with EECR register): 143 parts with 0x3f, 42 parts with 0x3c: AT90PWM161 AT90PWM81 ATmega128A ATmega128 ATmega162 ATmega16A ATmega16 ATmega32A ATmega32 ATmega64A ATmega64 ATmega8515 ATmega8535 ATmega8A ATmega8 ATtiny12 ATtiny13A ATtiny13 ATtiny15 ATtiny1634 ATtiny2313A ATtiny2313 ATtiny24A ATtiny24 ATtiny25 ATtiny261A ATtiny261 ATtiny26 ATtiny4313 ATtiny43U ATtiny441 ATtiny44A ATtiny44 ATtiny45 ATtiny461A ATtiny461 ATtiny841 ATtiny84A ATtiny84 ATtiny85 ATtiny861A ATtiny861. (Actually, the atdf list ATtiny12 ATtiny15 with eecr=0x1c, but I am pretty sure the atdf is wrong here and means 0x3c; the atdf sheet just forgot the 0x20 register offset.)

So, where does that leave AVRDUDE?

avrdude.conf rarely sets eecr, and if it does it's 0x3f (see avrdude -p*/st | grep eecr), the rest appear as eecr = 0x00
The eecr parameter is only used in two places jtag3.c and jtagmkII.c
- jtag3_initialize() that you pointed out above uses the default value of 0x3f if unset
- jtagmkII_set_devdescr() that uses the (mostly unset!) values from avrdude.conf

Of the above parts that have eecr = 0x3c nine parts also have a JTAG interface: ATmega128 ATmega128A ATmega16 ATmega162 ATmega16A ATmega32 ATmega32A ATmega64 ATmega64A

So, ... this raises the questions: Will AVRDUDE correctly read/write EEPROM with a -c programmer that

Uses jtag3.c or jtagmkII.c with any of the nine parts above (ATmega128, ...)?
Uses jtagmkII.c with any "classic" part other than the five parts that avrdude -p*/st | grep eecr outputs?

stefanrueger commented 2 years ago

Here my suggestions: Assuming the connected physical JTAG3/mkII programmers use the eecr parameter that AVRDUDE sends we should populate it correctly in avrdude.conf. I can do so in the next weeks in the context of a (semi) automated avrdude.conf rewrite that I had planned anyway.

Correctly means we should also try to figure out first from the documentation of the physical programmers whether they need the memory address (0x3c or 0x3f) or the register address (0x1c or 0x1f) that is offset by -0x20. Could you figure that out @mcuee? I don't know which programmer hardware uses jtag3 or jtagmkII. The result of that would need to be reflected in the code of jtag3.c (that already subtracts 0x20) and the code of jtagmkII.c that currently uses the avrdude.conf value unaltered.

Other than that, maybe also a good idea to continue to use 0x3f as default value (and make jtagmkII.c ti use that default, too).

stefanrueger commented 2 years ago

Fun fact. These have two EECR registers, presumably a multi-chip part, where the other chip also has an EEPROM? ATA5700M322 ATA5702M322 ATA5781 ATA5782 ATA5783 ATA5787 ATA5790N ATA5791 ATA5831 ATA5832 ATA5833 ATA5835 ATA8210 ATA8215 ATA8510 ATA8515

dl8dtl commented 2 years ago

I don't think these very special devices are something to take much care about, unless someone really pops up who wants to use them. I've never seen them "in the wild".

mcuee commented 2 years ago

Related issues with regard to EEPROM and JTAGICE mkii or JTAG ICE 3 related programmer.

https://github.com/avrdudes/avrdude/issues/1052 (maybe not the same issue)
https://github.com/avrdudes/avrdude/issues/1009 (fixed by #1013) (not the same issue).
https://github.com/avrdudes/avrdude/issues/1069 (most likely not the same issue)

mcuee commented 2 years ago

Unfortunately my AVR Dragon (jtagmkii based) does not see to work well under JTAG mode. I may accidently bricked the m16a board with wrong fuse when I was trying to use usbasp to change the EESAVE fuse setting using AVRDUDESS GUI (forgot to read the fuse first). I will try to carry out tests on other boards.

My initial tests showed that it can probably program empty EEPROM (not tested). Then it may have similar issues as #1009 (can only write 0's to EEPROM).

Initial contents: 54 68 (0101 0100; 0110 1000) Trying to prog: 5A 20 (0101 1010; 0010 0000) Results: 50 20 (0101 0000; 0010, 0000)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m16a -t

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

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

avrdude.exe: Device signature = 0x1e9403 (probably m16a)
avrdude> d ee
>>> d ee

Reading | ################################################## | 100% 0.37s

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  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|
0050  61 7a 79 20 64 6f 67 0a  54 68 65 20 71 75 69 63  |azy dog The quic|
0060  6b 20 62 72 6f 77 6e 20  66 6f 78 20 6a 75 6d 70  |k brown fox jump|
0070  73 20 6f 76 65 72 20 74  68 65 20 6c 61 7a 79 20  |s over the lazy |
0080  64 6f 67 0a 54 68 65 20  71 75 69 63 6b 20 62 72  |dog The quick br|
0090  6f 77 6e 20 66 6f 78 20  6a 75 6d 70 73 20 6f 76  |own fox jumps ov|
00a0  65 72 20 74 68 65 20 6c  61 7a 79 20 64 6f 67 0a  |er the lazy dog |
00b0  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
00c0  66 6f 78 20 6a 75 6d 70  73 20 6f 76 65 72 20 74  |fox jumps over t|
00d0  68 65 20 6c 61 7a 79 20  64 6f 67 0a 54 68 65 20  |he lazy dog The |
00e0  71 75 69 63 6b 20 62 72  6f 77 6e 20 66 6f 78 20  |quick brown fox |
00f0  6a 75 6d 70 73 20 6f 76  65 72 20 74 68 65 20 6c  |jumps over the l|

avrdude> quit
>>> quit

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m16a -U eeprom:w:.\hex\de.eep:i

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

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

avrdude.exe: Device signature = 0x1e9403 (probably m16a)
avrdude.exe: reading input file .\hex\de.eep for eeprom
avrdude.exe: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 1.82s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against .\hex\de.eep

Reading | ################################################## | 100% 0.50s

avrdude.exe: verification error, first mismatch at byte 0x0000
             0x50 != 0x5a
avrdude.exe: verification error; content mismatch
avrdude.exe: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m16a -e

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

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

avrdude.exe: Device signature = 0x1e9403 (probably m16a)
avrdude.exe: erasing chip
avrdude.exe: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m16a -t

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

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

avrdude.exe: Device signature = 0x1e9403 (probably m16a)

avrdude> d ee
>>> d ee

Reading | ################################################## | 100% 0.35s

0000  50 20 60 20 61 74 20 61  69 20 62 62 6d 70 6c 20  |P ` at ai bbmpl |
0010  64 64 20 20 60 70 65 60  60 20 6c 66 61 70 20 64  |dd  `pe`` lfap d|
0020  20 44 20 68 61 20 71 20  64 62 20 00 54 60 61 20  | D ha q db .T`a |
0030  20 40 61 61 61 20 62 02  4a 20 6a 20 66 64 20 20  | @aaa b.J j fd  |
0040  68 20 69 60 61 20 6c 64  64 70 20 74 60 60 20 60  |h i`a lddp t`` `|
0050  60 72 68 20 60 64 65 0a  00 40 61 20 61 20 61 61  |`rh `de .@a a aa|
0060  61 20 20 60 65 72 62 20  20 42 60 20 60 70 6c 00  |a  `erb  B` `pl.|
0070  52 20 6a 60 65 70 20 60  68 20 20 6c 61 70 68 20  |R j`ep `h  laph |
0080  64 64 20 02 44 60 65 20  60 70 68 63 63 20 60 62  |dd .D`e `phcc `b|
0090  20 54 60 20 60 20 70 20  60 70 20 60 71 20 63 60  | T` ` p `p `q c`|
00a0  20 42 20 70 60 60 20 08  40 20 68 20 64 64 20 08  | B p`` .@ h dd .|
00b0  44 20 61 20 61 70 68 61  60 20 20 72 65 72 66 20  |D a apha`  rerf |
00c0  60 62 68 20 62 74 65 60  20 00 61 70 61 20 20 74  |`bh bte` .apa  t|
00d0  60 60 20 64 61 72 61 20  20 42 61 08 44 60 64 00  |`` dara  Ba.D`d.|
00e0  50 20 68 61 63 20 20 60  6d 20 6a 20 64 60 68 20  |P hac  `m j d`h |
00f0  60 74 20 70 61 20 67 60  60 72 20 64 60 64 20 6c  |`t pa g``r d`d l|

PS C:\work\avr\avrdude_test\avrdude_bin> cat .\hex\de.eep
:020000040000FA
:200000005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656E86
:20002000205461786920717565722064757263682042617965726E0A5A206A6167742069C3
:200040006D206B6F6D706C65747420766572776168726C6F7374656E205461786920717533
:2000600065722064757263682042617965726E0A5A206A61677420696D206B6F6D706C652A
:20008000747420766572776168726C6F7374656E20546178692071756572206475726368FB
:2000A0002042617965726E0A5A206A61677420696D206B6F6D706C657474207665727761CA
:2000C00068726C6F7374656E205461786920717565722064757263682042617965726E0A5D
:2000E0005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656EA6
:20010000205461786920717565722064757263682042617965726E0A5A206A6167742069E2
:200120006D206B6F6D706C65747420766572776168726C6F7374656E205461786920717552
:2001400065722064757263682042617965726E0A5A206A61677420696D206B6F6D706C6549
:20016000747420766572776168726C6F7374656E205461786920717565722064757263681A
:200180002042617965726E0A5A206A61677420696D206B6F6D706C657474207665727761E9
:2001A00068726C6F7374656E205461786920717565722064757263682042617965726E0A7C
:2001C0005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656EC5
:2001E000205461786920717565722064757263682042617965726E0A5A206A616774206902
:00000001FF

PS C:\work\avr\avrdude_test\avrdude_bin> cat .\hex\en.eep
:020000040000FA
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:20010000617A7920646F670A54686520717569636B2062726F776E20666F78206A756D7038
:2001200073206F76657220746865206C617A7920646F670A54686520717569636B20627279
:200140006F776E20666F78206A756D7073206F76657220746865206C617A7920646F670A0E
:2001600054686520717569636B2062726F776E20666F78206A756D7073206F7665722074AD
:200180006865206C617A7920646F670A54686520717569636B2062726F776E20666F78201B
:2001A0006A756D7073206F76657220746865206C617A7920646F670A54686520717569639C
:2001C0006B2062726F776E20666F78206A756D7073206F76657220746865206C617A792073
:2001E000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F7654
:00000001FF

mcuee commented 2 years ago

Not so sure if I break the AVR Dragon JTAG side or not but I can not use it to communicate with my other ATmega32A based board (JTAG ICE1 works well). Now it can not communicate with the ATmega32A (using AVRdude or using Atmel Studio) on the JATG port (ISP port no issue). So I guess I can not test with the AVR Dragon to check for now.

Then I also got an AVR Dragon clone but it does not have JTAG port. The ISP port works.

@MCUdude Please help to check out whether you can use your JTAG capable programmer (eg: AVR Dragon) to see if they can program the affected chips or not when you got time. Thanks.

1) Uses jtag3.c or jtagmkII.c with any of the nine parts that have eecr = 0x3c which also have a JTAG interface: ATmega128 ATmega128A ATmega16 ATmega162 ATmega16A ATmega32 ATmega32A ATmega64 ATmega64A

2) Uses jtagmkII.c with any "classic" part other than the five parts that avrdude -p*/st | grep eecr outputs?

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -p*/st | grep eecr
.pt     AT90CAN128      eecr    0x3f
.pt     AT90CAN64       eecr    0x3f
.pt     AT90CAN32       eecr    0x3f
.pt     ATmega165       eecr    0x3f
.pt     ATmega406       eecr    0x3f

mcuee commented 2 years ago

@stefanrueger

For the second test, I am not so sure if dragon_isp (ISP mode) counts or not (it does use jtagmkII.c). If it counts, then avrdude works fine (tested using ATmega32A, verified with usbasp as well).

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_isp -p m32a -U eeprom:w:.\hex\de.eep:i -v

avrdude.exe: Version 7.0-20220815 (a4bfa82)
             Copyright (c) Brian Dean, http://www.bdmicro.com/
             Copyright (c) Joerg Wunsch

             System wide configuration file is "C:/work/avr/avrdude_test/avrdude_bin/avrdude.conf"

             Using Port                    : usb
             Using Programmer              : dragon_isp
avrdude.exe: usbdev_open(): Found AVRDRAGON, serno: 00A200001487
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
             AVR Part                      : ATmega32A
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PA0
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             Serial program mode           : yes
             Parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                               Block Poll               Page                       Polled
               Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom                  4    10    64    0 no       1024    4      0  9000  9000 0xff 0xff
               flash                  33     6    64    0 yes     32768  128    256  4500  4500 0xff 0xff
               lfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               hfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               lock                    0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
               calibration             0     0     0    0 no          4    1      0     0     0 0x00 0x00

             Programmer Type : DRAGON_ISP
             Description     : Atmel AVR Dragon in ISP mode
             Vtarget         : 4.9 V
             SCK period      : 8.00 us

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

Reading | ################################################## | 100% 0.17s

avrdude.exe: Device signature = 0x1e9502 (probably m32a)
avrdude.exe: reading input file .\hex\de.eep for eeprom
             with 512 bytes in 1 section within [0, 0x1ff]
             using 128 pages and 0 pad bytes
avrdude.exe: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 18.34s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against .\hex\de.eep

Reading | ################################################## | 100% 13.70s

avrdude.exe: 512 bytes of eeprom verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -qqp m32a 
-U eeprom:v:.\hex\de.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_isp -qqp m32a 
-U eeprom:w:.\hex\en.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -qqp m32a
 -U eeprom:v:.\hex\en.eep:i && echo OK
OK

stefanrueger commented 2 years ago

not so sure if dragon_isp (ISP mode) counts or not (it does use jtagmkII.c)

You can verify by inserting an fprintf(stderr, ...) line in your local copy of AVRDUDE just before https://github.com/avrdudes/avrdude/blob/a4bfa8247df8ddb447980e42a347035742046500/src/jtagmkII.c#L962 to see whether the eecr is sent to the programmer.

dl8dtl commented 2 years ago

The Dragon in ISP mode is basically a wrapped STK500v2 protocol, so it doesn't use the JTAG settings.

stefanrueger commented 2 years ago

If eecr = 0 is sent to the programmer and it works then the programmer either ignores this or defaults to the right value.

dl8dtl commented 2 years ago

ISP mode doesn't need to know about EECR, as ISP uses its own SPI command to access EEPROM.

My guess is that in JTAG mode, the ICE firmware accesses the EEPROM through the EECR address itself, that's why it needs to know about it.

stefanrueger commented 2 years ago

Yes, we'd need to know/find out which -c ... programmer and which physical programmer will utilise the jtagmkII_set_devdescr() call so we can test where things go wrong

dl8dtl commented 2 years ago

Only JTAG programmers use it, but I don't remember offhand whether device descriptions are still around in the newer (JTAG3/CMSIS-DAP) protocols.

In JTAG2, they were normally supposed to contain quite detailed information about the device (see AVaRICE), but for AVRDUDE that doesn't need to run a debugging protocol, I decided to derive most of the device description from information that is already known from other configuration data. EECR was probably the only relevant part of the device description that could not be deduced from elsewhere.

mcuee commented 2 years ago

Yes, we'd need to know/find out which -c ... programmer and which physical programmer will utilise the jtagmkII_set_devdescr() call so we can test where things go wrong

@stefanrueger Based on @dl8dtl's reply, only test case 1 is valid as the test needs to use JTAG interface.

1) Uses jtag3.c or jtagmkII.c with any of the nine parts that have eecr = 0x3c which also have a JTAG interface: ATmega128 ATmega128A ATmega16 ATmega162 ATmega16A ATmega32 ATmega32A ATmega64 ATmega64A

For jtagmkII.c, the physical programmers will be either AVR JTAGICE mkii or AVR Dragon, in JTAG mode.

For jtag3.c (may or may not be affected), take note PICKit 4 and SNAP can not be used because of #1052. Therefore the physical programmer (must be in JTAG mode) will be JTAGICE 3, Atmel AVR XplainedPro in JTAG mode, Atmel-ICE, Power Debugger.

stefanrueger commented 2 years ago

It's not only eecr: the support for register addresses in avrdude.conf is a bit unsystematic:

idr (aka ocdr) is given as in/out address (set for 25 parts)
eeecr is given as ld/st address (0x20 higher, set for 5 parts)
rampz is given as in/out address (set for 11 parts, but 16 JPAG enabled ISP parts have memory above 64 kiB)
spmcr is given as ld/st address (0x20 higher, set for 27 parts)

In contrast to this AN 067 seems to say that eecr and rampz should be addresses in SRAM I/O space (are these in/out addresses or ld/st addresses?) . Either way, not only is avrdude.conf unsystematic about the address type, it does not appear to match up with the expectation of AN 067. Also curious why AN 067 wants eecr as unsigned short rather than unsigned char. Does that subsume a padding byte, as eecr is the last element? (OK, the last question is one for Atmel to answer, not for us).

Here the corresponding code https://github.com/avrdudes/avrdude/blob/a4bfa8247df8ddb447980e42a347035742046500/src/jtagmkII.c#L959-L962

As @dl8dtl says a lot of the fields are not set (because AVRDUDE does not need them set), but if rampz is needed, then eind might also be needed? Since avrdude.conf captures these register addresses I wonder

Whether they should be of the same type (eg, always with the 0x20 offset, ie, memory addresses for ld/st)
How complete they should be for JTAG-enabled parts (does the FW have default values?)

BTW, the stats about coverage were gathered through commands like

$ avrdude -p*/st | grep idr | wc
$ avrdude -p*/d | awk '{ x=strtonum($7); if(x>65536) print; }' | grep ISP.JTAG | wc

stefanrueger commented 2 years ago

@mcuee Yes, this is an intriguing testing problem: find a programmer/part/-c ... combination so that we can verify/test what happens when https://github.com/avrdudes/avrdude/blob/a4bfa8247df8ddb447980e42a347035742046500/src/jtagmkII.c#L959-L962 is run

stefanrueger commented 2 years ago

... or https://github.com/avrdudes/avrdude/blob/a4bfa8247df8ddb447980e42a347035742046500/src/jtag3.c#L1368-L1374 for that matter

mcuee commented 2 years ago

I got my ATmega16A breakout board working again (after using JTAG ICE 1 to set the clock fuse to the right one).

Edit: need to update the test results on the ATmega16A. My AVR Dragon seems to have issues with the board now. The results show that both EEPROM read/write are bad, with or without changing the eecr value. This does not seem to be consistent with yesterday's results.

 MINGW64 /c/work/avr/avrdude_test/avrdude_bin
$ diff -u avrdude.conf avrdude_mod.conf
--- avrdude.conf        2022-08-19 21:31:46.004273700 +0800
+++ avrdude_mod.conf    2022-08-19 21:31:30.792891900 +0800
@@ -3816,6 +3816,7 @@
     programlockpolltimeout = 5;
     idr                 = 0x31;
     spmcr               = 0x57;
+    eecr                = 0x3c;
     ocdrev              = 2;
     chip_erase          = "1010.1100--100x.xxxx--xxxx.xxxx--xxxx.xxxx";
     pgm_enable          = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";
@@ -5124,6 +5125,7 @@
     programlockpolltimeout = 5;
     idr                 = 0x31;
     spmcr               = 0x57;
+       eecr                = 0x3c;
     ocdrev              = 2;
     chip_erase          = "1010.1100--1000.0000--xxxx.xxxx--xxxx.xxxx";
     pgm_enable          = "1010.1100--0101.0011--xxxx.xxxx--xxxx.xxxx";

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m16a 
-U eeprom:w:.\empty_m16a.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c dragon_jtag -qqp m16a
 -U eeprom:w:.\entest_256B.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0xff != 0x54
avrdude.exe: verification error; content mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m16a 
-U eeprom:w:.\entest_256B.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c dragon_jtag -qqp m16a
 -U eeprom:v:.\entest_256B.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0003
             0x03 != 0x20
avrdude.exe: verification error; content mismatch
avrdude.exe: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude_mod.conf -c dragon_jtag -qqp m16a
 -U eeprom:w:.\entest_256B.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x00 != 0x54
avrdude.exe: verification error; content mismatch
avrdude.exe: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude_mod.conf -c usbasp -qqp m16a
 -U eeprom:v:.\entest_256B.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x40 != 0x54
avrdude.exe: verification error; content mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude_mod.conf -c dragon_jtag -qqp m16a
 -U eeprom:r:.\entest_256B_readback.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude_mod.conf -c usbasp -qqp m16a
 -U eeprom:v:.\entest_256B_readback.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x000d
             0x20 != 0x7f
avrdude.exe: verification error; content mismatch

mcuee commented 2 years ago

My initial tests showed that it can probably program empty EEPROM (not tested). Then it may have similar issues as https://github.com/avrdudes/avrdude/issues/1009 (can only write 0's to EEPROM).

I think this is still correct based on my new test results with ATmega32A. So in the end eecr address may not be the issue but there are other issues.

1) writing EEPROM on the empty EEPROM is okay

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a
 -U eeprom:r:.\m32a_empty.eep:i
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a
 -U eeprom:v:.\m32a_empty.eep:i && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c dragon_jtag -qqp m32a
 -U eeprom:w:.\entest_256B.eep:i && echo OK
OK
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a
 -U eeprom:v:.\entest_256B.eep:i && echo OK
OK

2) not able to write 1 (only able to write 0) to the EEPROM. So if I am trying to write all 0xff it will write nothing.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c dragon_jtag -qqp m32a 
-U eeprom:w:.\m32a_empty.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x54 != 0xff
avrdude.exe: verification error; content mismatch
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a 
-U eeprom:v:.\m32a_readback.eep:i && echo OK
avrdude.exe: file .\m32a_readback.eep is not readable. No such file or directory
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a 
-U eeprom:r:.\m32a_readback.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> head .\m32a_readback.eep
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF

PS C:\work\avr\avrdude_test\avrdude_bin> head .\entest_256B.eep
:020000040000FA
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:00000001FF

PS C:\work\avr\avrdude_test\avrdude_bin> head .\m32a_empty.eep
:20000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:20006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:20008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:2000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF

3) eecr does not seem to matter. With or without the mod, dragon_jtag is able to write EEPROM correctly on an empty EEPROM.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a 
-U eeprom:w:.\m32a_empty.eep:i
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a
 -U eeprom:w:.\entest_256B.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a 
-U eeprom:w:.\m32a_empty.eep:i
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude_mod.conf -c usbasp -qqp m32a
 -U eeprom:w:.\entest_256B.eep:i && echo OK
OK

dl8dtl commented 2 years ago

I think it was always the case that JTAG could not write 1s to EEPROM.

If eecr doesn't matter, than I don't have an idea why JTAG2 ever wanted to have it in their device descriptions.

stefanrueger commented 2 years ago

@mcuee I take it you see that the set device descriptor command is actually being carried out by, eg,

$ avrdude -vv -C avrdude.conf -c dragon_jtag -p m32a -U eeprom:w:m32a_empty.eep:i |& grep set.device.descr
avrdude: jtagmkII_set_devdescr(): Sending set device descriptor command:...

Can you make the command fail by changing idr to a wrong value, say the GPIO0 register address (GPIO to avoid bad I/O)?

stefanrueger commented 2 years ago

@mcuee ... and just to definitely know, could you please also try eecr = 0x1c, b/c we don't know for sure which of the two address types JPAG2 wants. Who knows, maybe JTAG2 needs EECR to delete the byte? :-o I know, it's a bit of a stretch of the imagination...

mcuee commented 2 years ago

I think it was always the case that JTAG could not write 1s to EEPROM.

That is interesting to know. I will check on the JTAG ICE 1 as well.

If eecr doesn't matter, than I don't have an idea why JTAG2 ever wanted to have it in their device descriptions.

Indeed that is strange.

@MCUdude Please help to check on your AVR Dragon (or JTAG ICE mkiii if you have that) as well when you have time, for chips like ATmega8/8A/16/16A/32/32A/64/64A/128/128A/162. My results with ATmega16A is not consistent.

And I see that you have access to Atmel ICE (using jtag3.c), so you can test that as well to see jow set device descriptor command is actually being carried out.

mcuee commented 2 years ago

@mcuee I take it you see that the set device descriptor command is actually being carried out by, eg,
$ avrdude -vv -C avrdude.conf -c dragon_jtag -p m32a -U eeprom:w:m32a_empty.eep:i |& grep set.device.descr
avrdude: jtagmkII_set_devdescr(): Sending set device descriptor command:...

@stefanrueger Yes. Here is the detailed log. The AVR Dragon is quite flaky so you can see the connection failed in this case.

Unfortunately it seems to me I have issues to connect to the ATmega32 board today (tried Windows and Linux) so I am not able to carry out futher tests today. Hopefully @MCUdude can help here later.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a 
-U eeprom:w:.\m32a_empty.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -vv -C .\avrdude.conf -c dragon_jtag -p m32a
 -U eeprom:v:m32a_empty.eep:i

avrdude.exe: Version 7.0-20220815 (a4bfa82)
             Copyright (c) Brian Dean, http://www.bdmicro.com/
             Copyright (c) Joerg Wunsch

             System wide configuration file is ".\avrdude.conf"

             Using Port                    : usb
             Using Programmer              : dragon_jtag
avrdude.exe: jtagmkII_dragon_open()
avrdude.exe: usbdev_open(): Found AVRDRAGON, serno: 00A200001487
avrdude.exe: jtagmkII_getsync() attempt 1 of 10: Sending sign-on command: 0x86 (26 bytes msg)
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.exe: jtagmkII_getsync(): Using a 298-byte device descriptor
avrdude.exe: jtagmkII_setparm()
avrdude.exe: jtagmkII_setparm(): Sending set parameter command (parm 0x03, 1 bytes): 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_getsync(): Sending get sync command: 0x80 (1 bytes msg)
             AVR Part                      : ATmega32A
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PA0
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             Serial program mode           : yes
             Parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                               Block Poll               Page                       Polled
               Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom                  4    10    64    0 no       1024    4      0  9000  9000 0xff 0xff
               flash                  33     6    64    0 yes     32768  128    256  4500  4500 0xff 0xff
               lfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               hfuse                   0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               lock                    0     0     0    0 no          1    1      0  2000  2000 0x00 0x00
               signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
               calibration             0     0     0    0 no          4    1      0     0     0 0x00 0x00

             Programmer Type : DRAGON_JTAG
             Description     : Atmel AVR Dragon in JTAG mode
avrdude.exe: jtagmkII_getparm()
avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x01): 0x81 (3 bytes msg)
avrdude.exe: jtagmkII_getparm()
avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x02): 0x81 (5 bytes msg)
             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:14:87
avrdude.exe: jtagmkII_getparm()
avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x06): 0x81 (3 bytes msg)
             Vtarget         : 5.0 V
avrdude.exe: jtagmkII_getparm()
avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x07): 0x81 (2 bytes msg)
             JTAG clock      : 891.7 kHz (1.1 us)

avrdude.exe: jtagmkII_setparm()
avrdude.exe: jtagmkII_setparm(): Sending set parameter command (parm 0x1b, 4 bytes): 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_set_devdescr(): Sending set device descriptor command: 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_reset(): Sending reset command: 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_read_byte(.., hfuse, 0x1, ...)
avrdude.exe: jtagmkII_program_enable(): Sending enter progmode command: 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_program_enable(): Sending enter progmode command: 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_read_byte(): Sending read memory command: 0x82 (2 bytes msg)
avrdude.exe: AVR device initialized and ready to accept instructions

Reading |                                                   
 | 0% 0.00savrdude.exe: jtagmkII_read_byte(.., signature, 0x0, ...)
avrdude.exe: jtagmkII_read_byte(): Sending read memory command: 0x82 (2 bytes msg)
avrdude.exe: jtagmkII_read_byte(.., signature, 0x1, ...)
avrdude.exe: jtagmkII_read_byte(): Sending read memory command: 0x82 (2 bytes msg)
Reading | #################                                 
 | 33% 0.01savrdude.exe: jtagmkII_read_byte(.., signature, 0x2, ...)
avrdude.exe: jtagmkII_read_byte(): Sending read memory command: 0x82 (2 bytes msg)
Reading | ################################################## | 100% 0.02s

avrdude.exe: Device signature = 0x3f3f3f
avrdude.exe: Expected signature for ATmega32A is 1E 95 02
             Double check chip, or use -F to override this check.
avrdude.exe: jtagmkII_program_disable(): Sending leave progmode command: 0xa0 (1 bytes msg)
avrdude.exe: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED
avrdude.exe: jtagmkII_close()
avrdude.exe: jtagmkII_close(): Sending GO command: 0x80 (1 bytes msg)
avrdude.exe: jtagmkII_close(): Sending sign-off command: 0x80 (1 bytes msg)

avrdude.exe done.  Thank you.

-vvvv log is also attached here for reference.

full debug log

``` PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -vvvv -C .\avrdude.conf -c dragon_jtag -p m32a -U eeprom:v:m32a_empty.eep:i sys_config = .\avrdude.conf sys_config_found = false avrdude.exe: Version 7.0-20220815 (a4bfa82) Copyright (c) Brian Dean, http://www.bdmicro.com/ Copyright (c) Joerg Wunsch System wide configuration file is ".\avrdude.conf" Using Port : usb Using Programmer : dragon_jtag avrdude.exe: jtagmkII_dragon_open() avrdude.exe: usbdev_open(): Found AVRDRAGON, serno: 00A200001487 avrdude.exe: jtagmkII_getsync() avrdude.exe: jtagmkII_getsync() attempt 1 of 10: Sending sign-on command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [00] . [00] . [01] . [00] . [00] . [00] . [0e] . [01] . [f3] . [97] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 0 (command_sequence == 0) avrdude.exe: 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.exe: jtagmkII_getsync(): Using a 298-byte device descriptor avrdude.exe: jtagmkII_setparm() avrdude.exe: jtagmkII_setparm(): Sending set parameter command (parm 0x03, 1 bytes): avrdude.exe: jtagmkII_send(): sending 3 bytes avrdude.exe: Sent: . [1b] . [01] . [00] . [03] . [00] . [00] . [00] . [0e] . [02] . [03] . [01] . [9b] E [45] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 1 (command_sequence == 1) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_getsync(): Sending get sync command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [02] . [00] . [01] . [00] . [00] . [00] . [0e] . [0f] . [e2] u [75] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 65535 (command_sequence == 2) avrdude.exe: jtagmkII_recv(): got asynchronous event avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 2 (command_sequence == 2) avrdude.exe: Recv: . [80] Raw message: 0x80 OK AVR Part : ATmega32A Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK Serial program mode : yes Parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 4 10 64 0 no 1024 4 0 9000 9000 0xff 0xff Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- flash 33 6 64 0 yes 32768 128 256 4500 4500 0xff 0xff Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- lfuse 0 0 0 0 no 1 1 0 2000 2000 0x00 0x00 Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- hfuse 0 0 0 0 no 1 1 0 2000 2000 0x00 0x00 Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- lock 0 0 0 0 no 1 1 0 2000 2000 0x00 0x00 Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00 Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- calibration 0 0 0 0 no 4 1 0 0 0 0x00 0x00 Programmer Type : DRAGON_JTAG Description : Atmel AVR Dragon in JTAG mode avrdude.exe: jtagmkII_getparm() avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x01): avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [03] . [00] . [02] . [00] . [00] . [00] . [0e] . [03] . [01] . [d3] . [99] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 65535 (command_sequence == 3) avrdude.exe: jtagmkII_recv(): got asynchronous event avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 3 (command_sequence == 3) avrdude.exe: Recv: . [81] . [01] . [02] Raw message: 0x81 0x01 0x02 parameter values: 0x01 0x02 avrdude.exe: jtagmkII_getparm() avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x02): avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [04] . [00] . [02] . [00] . [00] . [00] . [0e] . [03] . [02] . [aa] B [42] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 4 (command_sequence == 4) avrdude.exe: Recv: . [81] ' [27] . [07] ' [27] . [07] Raw message: 0x81 0x27 0x07 0x27 0x07 parameter values: 0x27 0x07 0x27 0x07 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:14:87 avrdude.exe: jtagmkII_getparm() avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x06): avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [05] . [00] . [02] . [00] . [00] . [00] . [0e] . [03] . [06] s [73] I [49] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 5 (command_sequence == 5) avrdude.exe: Recv: . [81] z [7a] . [13] Raw message: 0x81 0x7a 0x13 parameter values: 0x7a 0x13 Vtarget : 5.0 V avrdude.exe: jtagmkII_getparm() avrdude.exe: jtagmkII_getparm(): Sending get parameter command (parm 0x07): avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [06] . [00] . [02] . [00] . [00] . [00] . [0e] . [03] . [07] . [fd] . [8e] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 6 (command_sequence == 6) avrdude.exe: Recv: . [81] . [06] Raw message: 0x81 0x06 parameter values: 0x06 JTAG clock : 891.7 kHz (1.1 us) avrdude.exe: jtagmkII_setparm() avrdude.exe: jtagmkII_setparm(): Sending set parameter command (parm 0x1b, 4 bytes): avrdude.exe: jtagmkII_send(): sending 6 bytes avrdude.exe: Sent: . [1b] . [07] . [00] . [06] . [00] . [00] . [00] . [0e] . [02] . [1b] . [00] . [00] . [00] . [00] . [f0] | [7c] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 7 (command_sequence == 7) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_set_devdescr(): Sending set device descriptor command: avrdude.exe: jtagmkII_send(): sending 299 bytes avrdude.exe: Sent: . [1b] . [08] . [00] + [2b] . [01] . [00] . [00] . [0e] . [0c] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] 1 [31] W [57] . [00] . [80] . [00] . [04] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [80] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [01] . [00] . [00] . [01] . [00] . [00] . [01] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [ed] . [89] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 8 (command_sequence == 8) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_reset(): Sending reset command: avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [09] . [00] . [02] . [00] . [00] . [00] . [0e] . [0b] . [01] # [23] . [b3] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 9 (command_sequence == 9) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_read_byte(.., hfuse, 0x1, ...) avrdude.exe: jtagmkII_program_enable(): Sending enter progmode command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [0a] . [00] . [01] . [00] . [00] . [00] . [0e] . [14] . [0c] . [f6] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 65535 (command_sequence == 10) avrdude.exe: jtagmkII_recv(): got asynchronous event avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 10 (command_sequence == 10) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_program_enable(): Sending enter progmode command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [0b] . [00] . [01] . [00] . [00] . [00] . [0e] . [14] . [b3] w [77] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 11 (command_sequence == 11) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_read_byte(): Sending read memory command: avrdude.exe: jtagmkII_send(): sending 10 bytes avrdude.exe: Sent: . [1b] . [0c] . [00] . [0a] . [00] . [00] . [00] . [0e] . [05] . [b2] . [01] . [00] . [00] . [00] . [01] . [00] . [00] . [00] . [da] . [c3] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 12 (command_sequence == 12) avrdude.exe: Recv: . [82] ? [3f] Raw message: 0x82 0x3f memory contents: 0x3f avrdude.exe: AVR device initialized and ready to accept instructions Reading | | 0% 0.00savrdude.exe: jtagmkII_read_byte(.., signature, 0x0, ...) avrdude.exe: jtagmkII_read_byte(): Sending read memory command: avrdude.exe: jtagmkII_send(): sending 10 bytes avrdude.exe: Sent: . [1b] . [0d] . [00] . [0a] . [00] . [00] . [00] . [0e] . [05] . [b4] . [01] . [00] . [00] . [00] . [00] . [00] . [00] . [00] q [71] k [6b] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 13 (command_sequence == 13) avrdude.exe: Recv: . [82] ? [3f] Raw message: 0x82 0x3f memory contents: 0x3f avrdude.exe: jtagmkII_read_byte(.., signature, 0x1, ...) avrdude.exe: jtagmkII_read_byte(): Sending read memory command: avrdude.exe: jtagmkII_send(): sending 10 bytes avrdude.exe: Sent: . [1b] . [0e] . [00] . [0a] . [00] . [00] . [00] . [0e] . [05] . [b4] . [01] . [00] . [00] . [00] . [01] . [00] . [00] . [00] . [db] G [47] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 14 (command_sequence == 14) avrdude.exe: Recv: . [82] . [01] Raw message: 0x82 0x01 memory contents: 0x01 Reading | ################# | 33% 0.03savrdude.exe: jtagmkII_read_byte(.., signature, 0x2, ...) avrdude.exe: jtagmkII_read_byte(): Sending read memory command: avrdude.exe: jtagmkII_send(): sending 10 bytes avrdude.exe: Sent: . [1b] . [0f] . [00] . [0a] . [00] . [00] . [00] . [0e] . [05] . [b4] . [01] . [00] . [00] . [00] . [02] . [00] . [00] . [00] . [19] r [72] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 15 (command_sequence == 15) avrdude.exe: Recv: . [82] ? [3f] Raw message: 0x82 0x3f memory contents: 0x3f Reading | ################################################## | 100% 0.05s avrdude.exe: Device signature = 0x3f013f avrdude.exe: Expected signature for ATmega32A is 1E 95 02 Double check chip, or use -F to override this check. avrdude.exe: jtagmkII_program_disable(): Sending leave progmode command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [10] . [00] . [01] . [00] . [00] . [00] . [0e] . [15] . [2e] . [9a] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 16 (command_sequence == 16) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_reset(): Sending reset command: avrdude.exe: jtagmkII_send(): sending 2 bytes avrdude.exe: Sent: . [1b] . [11] . [00] . [02] . [00] . [00] . [00] . [0e] . [0b] . [01] } [7d] 3 [33] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 65535 (command_sequence == 17) avrdude.exe: jtagmkII_recv(): got asynchronous event avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 17 (command_sequence == 17) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_close() avrdude.exe: jtagmkII_close(): Sending GO command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [12] . [00] . [01] . [00] . [00] . [00] . [0e] . [08] % [25] Z [5a] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 65535 (command_sequence == 18) avrdude.exe: jtagmkII_recv(): got asynchronous event avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 18 (command_sequence == 18) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe: jtagmkII_close(): Sending sign-off command: avrdude.exe: jtagmkII_send(): sending 1 bytes avrdude.exe: Sent: . [1b] . [13] . [00] . [01] . [00] . [00] . [00] . [0e] . [00] . [d2] W [57] avrdude.exe: jtagmkII_recv(): avrdude.exe: jtagmkII_recv(): Got message seqno 19 (command_sequence == 19) avrdude.exe: Recv: . [80] Raw message: 0x80 OK avrdude.exe done. Thank you. ```

mcuee commented 2 years ago

I think it was always the case that JTAG could not write 1s to EEPROM.

That is interesting to know. I will check on the JTAG ICE 1 as well.

@dl8dtl

Indeed this is the case for JTAG ICE 1 as well. Thanks for the info.

0x54 --> 0b 0101 0100 0x5A --> 0b 0101 1010 Results: 0x50 --> 0b 0101 0000

Unlike AVR Dragon, the JTAG ICE 1 clone is pretty stable with JTAG connection.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c jtag1 -P COM4 -qqp m32a
 -U eeprom:w:entest_256B.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c usbasp -qqp m32a
 -U eeprom:v:entest_256B.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c jtag1 -P COM4 -qqp m32a
 -U eeprom:w:detest_256B.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x50 != 0x5a
avrdude.exe: verification error; content mismatch

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -C .\avrdude.conf -c jtag1 -P COM4 -qqp m32a -t
avrdude> d ee
>>> d ee
0000  50 20 60 20 61 74 20 61  69 20 62 62 6d 70 6c 20  |P ` at ai bbmpl |
0010  64 64 20 20 60 70 65 60  60 20 6c 66 61 70 20 64  |dd  `pe`` lfap d|
0020  20 44 20 68 61 20 71 20  64 62 20 00 54 60 61 20  | D ha q db .T`a |
0030  20 40 61 61 61 20 62 02  4a 20 6a 20 66 64 20 20  | @aaa b.J j fd  |
0040  68 20 69 60 61 20 6c 64  64 70 20 74 60 60 20 60  |h i`a lddp t`` `|
0050  60 72 68 20 60 64 65 0a  00 40 61 20 61 20 61 61  |`rh `de .@a a aa|
0060  61 20 20 60 65 72 62 20  20 42 60 20 60 70 6c 00  |a  `erb  B` `pl.|
0070  52 20 6a 60 65 70 20 60  68 20 20 6c 61 70 68 20  |R j`ep `h  laph |
0080  64 64 20 02 44 60 65 20  60 70 68 63 63 20 60 62  |dd .D`e `phcc `b|
0090  20 54 60 20 60 20 70 20  60 70 20 60 71 20 63 60  | T` ` p `p `q c`|
00a0  20 42 20 70 60 60 20 08  40 20 68 20 64 64 20 08  | B p`` .@ h dd .|
00b0  44 20 61 20 61 70 68 61  60 20 20 72 65 72 66 20  |D a apha`  rerf |
00c0  60 62 68 20 62 74 65 60  20 00 61 70 61 20 20 74  |`bh bte` .apa  t|
00d0  60 60 20 64 61 72 61 20  20 42 61 08 44 60 64 00  |`` dara  Ba.D`d.|
00e0  50 20 68 61 63 20 20 60  6d 20 6a 20 64 60 68 20  |P hac  `m j d`h |
00f0  60 74 20 70 61 20 67 60  60 72 20 64 60 64 20 6c  |`t pa g``r d`d l|

PS C:\work\avr\avrdude_test\avrdude_bin> cat .\entest_256B.eep
:020000040000FA
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:00000001FF
PS C:\work\avr\avrdude_test\avrdude_bin> cat .\detest_256B.eep
:020000040000FA
:200000005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656E86
:20002000205461786920717565722064757263682042617965726E0A5A206A6167742069C3
:200040006D206B6F6D706C65747420766572776168726C6F7374656E205461786920717533
:2000600065722064757263682042617965726E0A5A206A61677420696D206B6F6D706C652A
:20008000747420766572776168726C6F7374656E20546178692071756572206475726368FB
:2000A0002042617965726E0A5A206A61677420696D206B6F6D706C657474207665727761CA
:2000C00068726C6F7374656E205461786920717565722064757263682042617965726E0A5D
:2000E0005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656EA6
:00000001FF

mcuee commented 2 years ago

Luckily I got another ATmega128A board which seems to work fine with the AVR Dragon.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m128a -U eeprom:w:entest.eep:i

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

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

avrdude.exe: Device signature = 0x1e9702 (probably m128a)
avrdude.exe: reading input file entest.eep for eeprom
avrdude.exe: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 0.63s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against entest.eep

Reading | ################################################## | 100% 0.39s

avrdude.exe: 512 bytes of eeprom verified

avrdude.exe done.  Thank you.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -qqp m128a -U eeprom:v:entest.eep:i && echo OK
OK

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c dragon_jtag -p m128a -U eeprom:w:detest.eep:i

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

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

avrdude.exe: Device signature = 0x1e9702 (probably m128a)
avrdude.exe: reading input file detest.eep for eeprom
avrdude.exe: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 0.62s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against detest.eep

Reading | ################################################## | 100% 0.39s

avrdude.exe: verification error, first mismatch at byte 0x0000
             0x50 != 0x5a
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

mcuee commented 2 years ago

I take it you see that the set device descriptor command is actually being carried out by, eg, $ avrdude -vv -C avrdude.conf -c dragon_jtag -p m32a -U eeprom:w:m32a_empty.eep:i |& grep set.device.descr avrdude: jtagmkII_set_devdescr(): Sending set device descriptor command:...

Yes, confirmed again.

MINGW64 /c/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22000/src
$ ./avrdude -vv -C ./avrdude.conf -c dragon_jtag -p m128a -U eeprom:w:entest.eep:i |& grep set.device.descr
avrdude.exe: jtagmkII_set_devdescr(): Sending set device descriptor command: 0x80 (1 bytes msg)

mcuee commented 2 years ago

Can you make the command fail by changing idr to a wrong value, say the GPIO0 register address (GPIO to avoid bad I/O)?

@stefanrueger It seems to me avrdude is not consistent in this case.

For ATmega128/128A

    idr                 = 0x22;
    spmcr               = 0x68;
    rampz               = 0x3b;
    allowfullpagebitstream = yes;

0x22 for idr/ocdr is without offset --> if with offset it should be 0x42. 0x3b for spmcr is without offset --> if with offset it should be 0x5B. 0x68 for spmcr is already with the offset (no values without offset in the datasheet).

Ref: http://ww1.microchip.com/downloads/en/devicedoc/atmel-8151-8-bit-avr-atmega128a_datasheet.pdf


MINGW64 /c/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22000/src
$ diff -u avrdude.conf avrdude_idrmod.conf
--- avrdude.conf        2022-08-03 08:18:22.220306000 +0800
+++ avrdude_idrmod.conf 2022-08-20 13:56:08.694101500 +0800
@@ -3479,9 +3479,11 @@
     programlockpulsewidth = 0;
     programlockpolltimeout = 5;

-    idr                 = 0x22;
+#   idr                 = 0x22; /* next is to change from 0x22 to 0x62 PORTF */
+       idr                 = 0x42;
     spmcr               = 0x68;
-    rampz               = 0x3b;
+    rampz               = 0x5b;
+       eecr                = 0x3c;
     allowfullpagebitstream = yes;

     ocdrev              = 1;

$ ./avrdude -C ./avrdude_idrmod.conf -c dragon_jtag -p m128a -U eeprom:w:entest.eep:i

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

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

avrdude.exe: Device signature = 0x1e9702 (probably m128a)
avrdude.exe: reading input file entest.eep for eeprom
avrdude.exe: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 0.62s

avrdude.exe: 512 bytes of eeprom written
avrdude.exe: verifying eeprom memory against entest.eep

Reading | ################################################## | 100% 0.38s

avrdude.exe: 512 bytes of eeprom verified

avrdude.exe done.  Thank you.

$ ./avrdude -C ./avrdude_idrmod.conf -c usbasp -qqp m128a -U eeprom:v:entest.eep:i && echo OK
OK

stefanrueger commented 2 years ago

@mcuee It would be great if you could play with the idr and eecr values in the .conf file and see whether it makes a difference when you use dragon_jtag. This would tell us whether the values in jtagmkII_set_devdescr() are needed, and if they are, whether they need the 0x20 offset or not. It might well be that JTAG2 expects some values with offset and some without.

stefanrueger commented 2 years ago

Ahh, just seen @mcuee has trouble with the rig. Anyone else to try different idr and eecr values would be fab.

mcuee commented 2 years ago

Ahh, just seen @mcuee has trouble with the rig. Anyone else to try different idr and eecr values would be fab.

I got one setup which works -- AVR Dragon + ATmega128A. I tried different combinations of idr (0x22/0x42/0x62) and eecr (0x1c/0x3c/0x3f) and the conclusion is the same.

But hopefully @MCUdude or others can try out on different chips as well. For example I have very inconsistent results with the ATmega16A board and now I can not connect to ATmega32A board.

MINGW64 /c/work/avr/avrdude_test/avrdude_main/build_mingw64_nt-10.0-22000/src
$ diff -u avrdude.conf avrdude_idrmod1.conf
--- avrdude.conf        2022-08-03 08:18:22.220306000 +0800
+++ avrdude_idrmod1.conf        2022-08-20 16:27:42.316966600 +0800
@@ -3479,9 +3479,11 @@
     programlockpulsewidth = 0;
     programlockpolltimeout = 5;

-    idr                 = 0x22;
+#   idr                 = 0x22; /* next is to change from 0x22 to 0x62 PORTF */
+       idr                 = 0x62;
     spmcr               = 0x68;
-    rampz               = 0x3b;
+    rampz               = 0x5b;
+       eecr                = 0x1c;
     allowfullpagebitstream = yes;

     ocdrev              = 1;

$ ./avrdude -C ./avrdude_idrmod1.conf -c dragon_jtag -qqp m128a 
-U eeprom:w:entest.eep:i && echo OK
OK

$ ./avrdude -C ./avrdude_idrmod1.conf -c dragon_jtag -qqp m128a 
-U eeprom:w:detest.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x50 != 0x5a
avrdude.exe: verification error; content mismatch

mcuee commented 2 years ago

@stefanrueger I got another ATmega32A board working and the conclusion is the same: writing EEPROM to empty EEPROM is okay. But there is a general JTAG limitation with avrdude that JTAG is not able to write 1s to EEPROM (#1072).

1072

$ ./avrdude -C ./avrdude_idrmod1.conf -c dragon_jtag -qqp m32a -U eeprom:w:entest.eep:i && echo OK
OK

$ ./avrdude -C ./avrdude_idrmod1.conf -c usbasp -qqp m32a -U eeprom:v:entest.eep:i && echo OK
OK

$ ./avrdude -C ./avrdude_idrmod1.conf -c dragon_jtag -qqp m32a -U eeprom:w:detest.eep:i && echo OK
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x50 != 0x5a
avrdude.exe: verification error; content mismatch

mcuee commented 2 years ago

If eecr doesn't matter, than I don't have an idea why JTAG2 ever wanted to have it in their device descriptions.

@dl8dtl and @stefanrueger It seems to me that eecr and idr do not matter for JTAGICE mkii (at least for my AVR Dragon in JTAG mode, when it is working. The AVR Dragon is quite flaky in JTAG mode). Hopefully someone else can check out JTAG2 and JTAG3 on similar chips using JTAG connection to confirm.

MCUdude commented 2 years ago

@mcuee here's the result of testing the Dragon and Atmel ICE in JTAG mode with the ATmega128 and AT90CAN128 as targets. Both have JTAGEN and OCDEN enabled. I'm getting the following warning when using the Adragon in JTAG mode without OCDEN: avrdude: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

Dragon in JTAG mode:

$ ./avrdude -cdragon_jtag -patmega128 -Uflash:w:blink_128.hex:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9702 (probably m128)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file blink_128.hex for flash
avrdude: writing 1202 bytes flash ...

Writing | ################################################## | 100% 0.08s

avrdude: 1202 bytes of flash written
avrdude: verifying flash memory against blink_128.hex

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

avrdude: 1202 bytes of flash verified

avrdude done.  Thank you.

$ ./avrdude -cdragon_jtag -pat90can128 -Uflash:w:blink_can128.hex:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9781 (probably c128)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file blink_can128.hex for flash
avrdude: writing 1246 bytes flash ...

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

avrdude: 1246 bytes of flash written
avrdude: verifying flash memory against blink_can128.hex

Reading | ################################################## | 100% 0.13s

avrdude: 1246 bytes of flash verified

avrdude done.  Thank you.

Atmel ICE in JTAG mode:

$ ./avrdude -catmelice -patmega128 -Uflash:w:blink_128.hex:i

         Vtarget                      : 5.04 V
         JTAG clock megaAVR/program   : 1500 kHz
         JTAG clock megaAVR/debug     : 200 kHz
         JTAG clock Xmega             : 1000 kHz
         PDI/UPDI clock Xmega/megaAVR : 500 kHz

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9702 (probably m128)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file blink_128.hex for flash
avrdude: writing 1202 bytes flash ...

Writing | ################################################## | 100% 0.10s

avrdude: 1202 bytes of flash written
avrdude: verifying flash memory against blink_128.hex

Reading | ################################################## | 100% 0.06s

avrdude: 1202 bytes of flash verified

avrdude done.  Thank you.

$ ./avrdude -catmelice -pat90can128 -Uflash:w:blink_can128.hex:i

         Vtarget                      : 5.05 V
         JTAG clock megaAVR/program   : 1500 kHz
         JTAG clock megaAVR/debug     : 200 kHz
         JTAG clock Xmega             : 1000 kHz
         PDI/UPDI clock Xmega/megaAVR : 500 kHz

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9781 (probably c128)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file blink_can128.hex for flash
avrdude: writing 1246 bytes flash ...

Writing | ################################################## | 100% 0.10s

avrdude: 1246 bytes of flash written
avrdude: verifying flash memory against blink_can128.hex

Reading | ################################################## | 100% 0.06s

avrdude: 1246 bytes of flash verified

avrdude done.  Thank you.

Everything appears to be working just fine. Both microcontrollers are executing code, and flashing an LED every second. It's interesting that I'm getting the RSP_FAILED warning when using the Dragon on a device that's not in OCD mode, but not with Atmel ICE.

mcuee commented 2 years ago

@mcuee here's the result of testing the Dragon and Atmel ICE in JTAG mode with the ATmega128 and AT90CAN128 as targets. Both have JTAGEN and OCDEN enabled. I'm getting the following warning when using the Adragon in JTAG mode without OCDEN: avrdude: jtagmkII_program_disable(): bad response to leave progmode command: RSP_FAILED

Everything appears to be working just fine. Both microcontrollers are executing code, and flashing an LED every second. It's interesting that I'm getting the RSP_FAILED warning when using the Dragon on a device that's not in OCD mode, but not with Atmel ICE.

@MCUdude It is great that you have working setups to test JTAG using AVR Dragon and Atmel ICE. Please help to carry out the tests with EEPROM.

You can refer to the test mentioned above to see if you have the same conclusion as I for your AVR Dragon and Atmel ICE: writing to empty EEPROM (say using entest.eep) is okay and then the next write (say using detest.eep) will fail as JTAG programmers can not write 1s.

https://github.com/avrdudes/avrdude/issues/1071#issuecomment-1219492097

You can try the avrdude.conf from the git main, or you can try changing the eecr and icr value to check if they make any differeneces in your test results. If your test results are in line with mine, we can safely say eecr register does not matter for jtagmkII.c and jtag3.c. Same for idr.

MCUdude commented 2 years ago

@mcuee I tried to modify the eecr and idr values for AT90CAN128 and ATmega128, but no matter what I do, I'm not able to write 1's to the eeprom using my Atmel ICE in JTAG mode. I'm seeing the same result using my AVR Dragon in JTAG mode as well.

stefanrueger commented 2 years ago

@mcuee @MCUdude Wow, thanks for thorough testing. OK, this is not an issue then, and jtagmkII_set_devdescr() does not need the correct eecr or idr values for the part. Interesting that for some combinations of paged memory, programmer and programming mode, the bare metal write operations either

Make the memory look like NOR-memory (EEPROM+JTAG, typically flash with external programming)
Allow all states to be written (typically EEPROM, flash with using page erase or bootloaders using SPM erase page)

[Of course, in the end of the day, all bits can be written as they need be (that's the purpose of a programmer!) but writing a single bit to 1 may involve reading all flash and EEPROM, modifying the bit and then writing he whole shebang back; that in turn requires a fair bit of caching and cannot be done at the low-level writes]

stefanrueger commented 2 years ago

Closing as eecr appears not to be used.

mcuee commented 2 years ago

[Of course, in the end of the day, all bits can be written as they need be (that's the purpose of a programmer!) but writing a single bit to 1 may involve reading all flash and/or EEPROM, modifying the bit and then writing he whole shebang back; that in turn requires a fair bit of caching and cannot be done at the low-level writes]

That may be the ulitmate solution (brutal force solution) to work around the limitation of the various programmers, including JTAG. They will support chip erase and then they can write flash/EEPROM using this brutal force solution.

Referemce:

https://github.com/avrdudes/avrdude/issues/1072#issuecomment-1225316611 (EEPROM limitation for JTAG programmers).
https://github.com/avrdudes/avrdude/issues/1054 (this is a bug of avrdude) and there should be better solution than the brutal force solution)
https://github.com/avrdudes/avrdude/issues/1020#issuecomment-1225340174 (this may be a bug of avrdude and maybe there is a better solution)

Of course, whenever possible, the following proposal is better.

https://github.com/avrdudes/avrdude/issues/1020#issuecomment-1177482057

My proposal is to provide in avr.c generic avr_read_byte_cache() and avr_write_byte_cache() routines that, for programmers that have paged read/write functions,

Maintain a page-sized flash read/write cache for all parts with paged flash memory (not only classic AVRs)

Maintain a 256-byte EEPROM read/write cache (or less if the EEPROM is smaller) for all parts with EEPROM memory

Flush the respective cache (if modified) on switching a page or trying to access a byte outside the valid address range

Fall back to avr_read_byte_default() and avr_write_byte_default(), respectively, otherwise

avrdudes / avrdude

jtagmkII_set_devdescr() sends wrong eecr value to physical programmer (EEPROM access fails?) #1071

1072