JTAG is not able to write 1s to EEPROM

[mcuee]

#1071 (comment)

From @dl8dtl

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

I think avrdude documentation needs to reflect this one.

[MCUdude]

We should perhaps confirm this by testing the JTAG1's EEPROM write capabilities in AVR studio 4 before stating that writing 1's to the EEPROM isn't possible. If it is correct, it's a major bug!

[mcuee]

@MCUdude

@dl8dtl mentioned this as a generic AVR JTAG programmer limitation, not limited to JTAG ICE 1. My test results show that JTAG1 and AVR Dragon (JTAG2) have the issue under avrdude.

We should test JTAG ICE 1 under AVR Studio 4 (not supported by Microchip Studio), and other JTAG programmers under Microchip Studio (eg: JTAGICE mkii, AVR Dragon, JTAGICE 3, Atmel-ICE, Power Debugger, etc),

I see that you have access to AVR Dragon and Atmel-ICE, please help to test this out under Microchip Studio when you got some time. It will be great that you can check out the two test cases mentioned here.

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

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]

I just tried to use AVR JTAGICE 1 under Atmel Studio 4.18 and indeed it has the issue of unable to write 1s to EEPRM.

Initial value: 0x54--> 0b 0101 0100
To write value: 0x5A --> 0b 0101 1010
Result: 0x50 --> 0b 0101 0000

Initial programming (empty EEPROM to entest.eep) is okay.

Detecting on 'COM4'...
JTAG ICE found on COM4
Getting revisions.. HW: 0xc3, SW Major: 0x80, SW Minor: 0x00 .. OK

OK
Reading EEPROM input file.. OK
Setting device parameters for jtag programming ..OK
Entering programming mode.. OK
Programming EEPROM ..       OK
Reading EEPROM ..       OK
EEPROM contents is equal to file.. OK
Leaving programming mode.. OK

Second program failed.

Entering programming mode.. OK
Programming EEPROM ..       OK
Reading EEPROM ..       OK
WARNING: EEPROM address 0x0000 is 0x50 (should be 0x5A).. FAILED!
Leaving programming mode.. OK

hex files used for the test:

MINGW64 /c/work/avr/avrdude_test/avrdude_bin/hex
$ head entest.eep
:020000040000FA
:2000000054686520717569636B2062726F776E20666F78206A756D7073206F76657220740E
:200020006865206C617A7920646F670A54686520717569636B2062726F776E20666F78207C
:200040006A756D7073206F76657220746865206C617A7920646F670A5468652071756963FD
:200060006B2062726F776E20666F78206A756D7073206F76657220746865206C617A7920D4
:20008000646F670A54686520717569636B2062726F776E20666F78206A756D7073206F76B5
:2000A000657220746865206C617A7920646F670A54686520717569636B2062726F776E20FE
:2000C000666F78206A756D7073206F76657220746865206C617A7920646F670A54686520C2
:2000E000717569636B2062726F776E20666F78206A756D7073206F76657220746865206C16
:20010000617A7920646F670A54686520717569636B2062726F776E20666F78206A756D7038

$ head detest_256B.eep
:020000040000FA
:200000005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656E86
:20002000205461786920717565722064757263682042617965726E0A5A206A6167742069C3
:200040006D206B6F6D706C65747420766572776168726C6F7374656E205461786920717533
:2000600065722064757263682042617965726E0A5A206A61677420696D206B6F6D706C652A
:20008000747420766572776168726C6F7374656E20546178692071756572206475726368FB
:2000A0002042617965726E0A5A206A61677420696D206B6F6D706C657474207665727761CA
:2000C00068726C6F7374656E205461786920717565722064757263682042617965726E0A5D
:2000E0005A206A61677420696D206B6F6D706C65747420766572776168726C6F7374656EA6
:00000001FF

Writing Result:

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c usbasp -qqp m128 -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|

[mcuee]

BTW, JTAG1 has also a separated issue with the terminal mode as mentioned in #1054.

• AVR JTAG ICE (mki) can not program EEPROM in terminal mode #1054

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c jtag1 -P COM4 -qqp m128 -t
avrdude> d ee 0x0 0x10
>>> d ee 0x0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude>  write eeprom 0x0 "hello world!"
>>> write eeprom 0x0 "hello world!"
avrdude.exe (write): error writing 0x68 at 0x00000 cell=0xff
avrdude.exe (write): error writing 0x65 at 0x00001 cell=0xff
avrdude.exe (write): error writing 0x6c at 0x00002 cell=0xff
avrdude.exe (write): error writing 0x6c at 0x00003 cell=0xff
avrdude.exe (write): error writing 0x6f at 0x00004 cell=0xff
avrdude.exe (write): error writing 0x20 at 0x00005 cell=0xff
avrdude.exe (write): error writing 0x77 at 0x00006 cell=0xff
avrdude.exe (write): error writing 0x6f at 0x00007 cell=0xff
avrdude.exe (write): error writing 0x72 at 0x00008 cell=0xff
avrdude.exe (write): error writing 0x6c at 0x00009 cell=0xff
avrdude.exe (write): error writing 0x64 at 0x0000a cell=0xff
avrdude.exe (write): error writing 0x21 at 0x0000b cell=0xff
avrdude.exe (write): error writing 0x00 at 0x0000c cell=0xff
avrdude> quit
>>> quit

[mcuee]

Hmm, I need to read the documentation in more detail. It has already mentioned the above limitation.

https://avrdudes.github.io/avrdude/7.0/avrdude_39.html#Troubleshooting

Problem: Page-mode programming the EEPROM (using the -U option) does not erase EEPROM cells before writing, and thus cannot overwrite any previous value != 0xff.
Solution: None. This is an inherent feature of the way JTAG EEPROM programming works, and is documented that way in the Atmel AVR datasheets. In order to successfully program the EEPROM that way, a prior chip erase (with the EESAVE fuse unprogrammed) is required. This also applies to the STK500 and STK600 in high-voltage programming mode.

[mcuee]

@MCUdude and @dl8dtl

Shall I close this issue? Or shall we improve the documentation to clearly mention this limitation about JTAG programmers and not just in the troubleshooting section?

[mcuee]

@MCUdude
I can see that Atmel-ICE can perform a bit differently compared to JTAG ICE 1 and JTAGICE mkii based on your test results below regarding Flash Write in terminal mode. Please help to test for EEPROM writing in terminal mode as well when you got time. Thanks.

• Write flash rarely works in terminal mode for classic AVRs #1020 (comment)

[MCUdude]

I just borrowed the Atmel ICE, and I've just returned it. I may ask to do some more testing with it though.

I doubt it will be able to write 1s to EEPROM in terminal mode. It can't co it when writing a file without performing a chip and EEPROM erase first. I contacted a Microchip developer, and got the following answer:

Q: Is it correct that JTAG2-compatible programmers (i.e the AVR Dragon) and JTAG3/Atmel ICE only can write 0's to EEPROM and not 1's? It's like this when using Avrdude, but the EDBG documentation I've read doesn't explicitly specifies this behaviour.

A: Sounds like a bug to me – this rule applies of course to FLASH, not EEPROM. But EDBG is not “JTAG2-compatible”… and feature-set is usually a function of the silicon, not the debugger anyway…

Q: I know the JTAG3/Atmel ICE can write 1's to Xmega's and AVRs with UPDI, but only when utilizing an "Atomic write" (See issue #1009 and PR #1013). However, I can't find a similar feature on AVRs with JTAG.

A: Correct – atomic (erase-and-write) was added for XMEGA. Not sure why this split was made…

Q: Does this means that it's impossible to write 1's to the EEPROM using a JTAG interface without running a chip erase first?

A: Not convinced, but not sure. SomeoneTM would probably have to find the RTL to know for sure – there are many subtle differences between the different entry modes (ISP/HVSP/JTAG) on those old parts – only from XMEGA onwards was there proper separation between physical and logical interfaces…

[mcuee]

@MCUdude
Great info. Thanks. Hopefully you can ask the Microchip developer to carry out the simple test to confirm.

[mcuee]

BTW, I was trying to find the ATmega128A datasheet on the JTAG side. I do not see limitation mentioned in the datasheet with regard to EEPROM.

https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8151-8-bit-AVR-ATmega128A_Datasheet.pdf

For high voltage parallel programming (ST500/STK600), it is rather clear.
Section 31.7.3. Chip Erase
The Chip Erase will erase the Flash and EEPROM memories plus Lock bits. The Lock bits are not reset
until the program memory has been completely erased. The Fuse bits are not changed. A Chip Erase
must be performed before the Flash and/or EEPROM are reprogrammed

Edit to add: EEPROM is also clear.
Section: 31.10.19. Programming the EEPROM
Before programming the EEPROM a Chip Erase must be performed. See Performing Chip Erase on page 410.

1. Enter JTAG instruction PROG_COMMANDS.
2. Enable EEPROM write using programming instruction 4a.
3. Load address high byte using programming instruction 4b.
4. Load address low byte using programming instruction 4c.
5. Load data using programming instructions 4d and 4e.
6. Repeat steps 4 and 5 for all data bytes in the page.
7. Write the data using programming instruction 4f.
8. Poll for EEPROM write complete using programming instruction 4g, or wait for tWLRH (refer to table
   Parallel Programming Characteristics, VCC = 5V ±10% in chapter Parallel Programming
   Characteristics).
9. Repeat steps 3 to 8 until all data have been programmed.
   Note that the PROG_PAGELOAD instruction can not be used when programming the EEPROM
   Related Links
   Parallel Programming Characteristics on page 419.

[mcuee]

@MCUdude
Maybe you can point out the above info from the datasheet to the Microchip developer and see if he or she has further comments. Thanks.

[mcuee]

In the end, I think avrdude documentation already mentions the limitation (classic AVR chip limitation in JTAG mode). Still we may need to improve the documentation to mention the chips and JTAG programmers affected.

[MCUdude]

@mcuee I don't want to bother the Microchip developers more than necessary. I think we have the answers we need, and we can test using AVR studio 4 just to be sure when it comes to JTAG + EEPROM.

[mcuee]

I don't want to bother the Microchip developers more than necessary. I think we have the answers we need, and we can test using AVR studio 4 just to be sure when it comes to JTAG + EEPROM.

I agree. In terms of JTAG and EEPROM, I think it is rather clear. And the current AVR documentation is not wrong. The only thing is that we may want to improvement the documentation a bit further to mention the JTAG programmers and Chips (Classic AVRs with JTAG).

[mcuee]

This may get fixed by #1106.

• Provide cached byte-wise read/write API #1106

[stefanrueger]

closed with PR #1106