Closed mcuee closed 1 year ago
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!
@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.
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
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|
BTW, JTAG1 has also a separated issue with the terminal mode as mentioned in #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
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.
@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?
@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.
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…
@MCUdude Great info. Thanks. Hopefully you can ask the Microchip developer to carry out the simple test to confirm.
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.
@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.
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.
@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 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).
This may get fixed by #1106.
closed with PR #1106
https://github.com/avrdudes/avrdude/issues/1071#issuecomment-1220886097
From @dl8dtl
I think avrdude documentation needs to reflect this one.