Use byte-wise read/write when page size is 1 in terminal cache #1121

stefanrueger · 2022-10-11T14:34:14Z

Supposed to fix Issue #1116

mcuee · 2022-10-12T00:09:34Z

I think the pull request is correct but it does not sort out the wrong warning message issue as in #1116.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121
Usage: avrdude_pr1121.exe [options]
Options:
...
avrdude version 7.0-20221011 (48919f5), URL: <https://github.com/avrdudes/avrdude>

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121 -p atmega4808 -c jtag2updi -P COM13 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  ff ff ff ff 67 74 20 69  6d 20 6b 6f 6d 70 6c 65  |....gt im komple|

avrdude> write eeprom 0x0 0xaa 0xaa 0xaa 0xaa
>>> write eeprom 0x0 0xaa 0xaa 0xaa 0xaa
avrdude> flush
>>> flush
avrdude_pr1121.exe: synching cache to device... 
avrdude_pr1121.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_pr1121.exe: writeCachePage() eeprom write error at addr 0x0000
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa aa aa aa 67 74 20 69  6d 20 6b 6f 6d 70 6c 65  |....gt im komple|

avrdude> write eeprom 0x0 0x55 0x55 0x55 0x55
>>> write eeprom 0x0 0x55 0x55 0x55 0x55
avrdude> flush
>>> flush
avrdude_pr1121.exe: synching cache to device... 
avrdude_pr1121.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_pr1121.exe: writeCachePage() eeprom write error at addr 0x0000
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  55 55 55 55 67 74 20 69  6d 20 6b 6f 6d 70 6c 65  |UUUUgt im komple|

avrdude> quit
>>> quit
avrdude_pr1121.exe: synching cache to device... 
avrdude_pr1121.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_pr1121.exe: writeCachePage() eeprom write error at addr 0x0000

mcuee · 2022-10-12T11:24:42Z

My Arduino Nano Every with ATmega4809 has issues with EEPROM writing. This PR does not change the behavior.

PS C:\work\avr\avrdude_test\avrdude_bin> mode COM12 baud=12 dtr=on > nul && mode COM12 baud=12 dtr=off > nul
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121 -p atmega4809 -c jtag2updi -P COM12 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |

avrdude> write eeprom 0 0xff 0xff 0xff 0xff
>>> write eeprom 0 0xff 0xff 0xff 0xff
avrdude> flush
>>> flush
avrdude_pr1121.exe: synching cache to device... 
avrdude_pr1121.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_pr1121.exe: writeCachePage() eeprom write error at addr 0x0000
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  ff ff ff ff 71 75 69 63  6b 20 62 72 6f 77 6e 20  |....quick brown |

avrdude> quit
>>> quit
avrdude_pr1121.exe: synching cache to device... 
avrdude_pr1121.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_pr1121.exe: writeCachePage() eeprom write error at addr 0x0000
PS C:\work\avr\avrdude_test\avrdude_bin> mode COM12 baud=12 dtr=on > nul && mode COM12 baud=12 dtr=off > nul
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -p atmega4809 -c jtag2updi -P COM12 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |

avrdude> write eeprom 0 0xff 0xff 0xff 0xff
>>> write eeprom 0 0xff 0xff 0xff 0xff
avrdude> flush
>>> flush
avrdude_git.exe: synching cache to device... 
avrdude_git.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_git.exe: writeCachePage() eeprom write error at addr 0x0000
avrdude> quit
>>> quit
avrdude_git.exe: synching cache to device... 
avrdude_git.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE

avrdude_git.exe: writeCachePage() eeprom write error at addr 0x0000

mcuee · 2022-10-12T11:29:19Z

From #1069 I can see that @MCUdude and @avrfreak have facilities to test jtag2updi as well.

@MCUdude and @avrfreak, please try this PR as well to see if it makes any difference for your jtag2udpi results with EEPROM read/write in terminal mode, when you got chance.

mcuee · 2022-10-12T11:51:39Z

@stefanrueger
Somehow this causes more problem for the optiboot_dx bootloader.

avrdude 7.0 release -- not able to read EEPROM
Current git main-- issues with read due to regression mentioned in #1120.
This PR #1121 -- not able to read EEPROM
Closed PR #1110 with a_div = 1 mod -- read EEPROM correctly.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq -t
                 Vtarget                      : 3.31 V
                 PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> write eeprom 0 0xaa 0x55 0xaa 0x55
>>> write eeprom 0 0xaa 0x55 0xaa 0x55
avrdude> flush
>>> flush
avrdude_git.exe: synching cache to device... done
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa 55 aa 55 ff ff ff ff  ff ff ff ff ff ff ff ff  |.U.U............|

avrdude> quit
>>> quit

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM6 -b 115200 -p avr128db48 -qq -t
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa aa 55 55 aa aa 55 55  ff ff ff ff ff ff ff ff  |..UU..UU........|

avrdude> quit
>>> quit


PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121 -c arduino -P COM6 -b 115200 -p avr128db48 -qq -t
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
avrdude_pr1121.exe: loadCachePage() eeprom read error at addr 0x0000
avrdude_pr1121.exe (dump): error reading eeprom address 0x00000 of part AVR128DB48
                           read operation not supported on memory type eeprom
avrdude> quit
>>> quit

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1110v1mod2.exe -c arduino -P COM6 -b 115200 
-p avr128db48 -qq -t
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa 55 aa 55 ff ff ff ff  ff ff ff ff ff ff ff ff  |.U.U............|

avrdude> quit
>>> quit

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude7 -C .\avrdude7.conf -c arduino -P COM6 -b 115200 
-p avr128db48 -qq -t

avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
error reading eeprom address 0x00000 of part AVR128DB48
read operation not supported on memory type "eeprom"
avrdude> quit
>>> quit

avrfreak · 2022-10-12T11:56:00Z

Given that jtag2updi has specific problems when programming eeprom in avrdx, and various other issues, I have given up on jtag2updi.

I purchased a PG164100 (SNAP) debugger for just $34 USD. I use it as a UPDI programmer with avrdude.
It works very well and is extremely fast. I should have done this in the first place rather than waste days on trying to make jtag2updi work for my needs.

There is one problem that is Avrdude related (nothing to do with the SNAP Programmer).
You can't access the device if it is locked.
AVRDUDE does not allow chip erase to clear the lock bits, IIRC it does page erase only.

mcuee · 2022-10-12T12:01:22Z

Given that jtag2updi has specific problems when programming eeprom in avrdx, and various other issues, I have given up on jtag2updi.

No problem. It seems to me jtag2updi is less popular now and searialupdi may gain popularity.
Ref:
https://github.com/MCUdude/MegaCoreX
https://github.com/SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

I purchased a PG164100 (SNAP) debugger for just $34 USD. I use it as a UPDI programmer with avrdude. It works very well and is extremely fast. I should have done this in the first place rather than waste days on trying to make jtag2updi work for my needs.

Yes I will agree that SNAP or PICKit 4 is the way to go for the future if you want the best compatibility with future AVR pars (as well as PICs). I actually bought an SNAP as well but i have not used much yet.

There is one problem that is Avrdude related (nothing to do with the SNAP Programmer). You can't access the device if it is locked. AVRDUDE does not allow chip erase to clear the lock bits, IIRC it does page erase only.

Please help to create nother issue to see if this can be fixed. Thanks.

avrfreak · 2022-10-12T12:30:26Z

Please help to create nother issue to see if this can be fixed. Thanks.

Here it is:
https://github.com/avrdudes/avrdude/issues/1124

stefanrueger · 2022-10-12T15:04:05Z

The problem here is that -c jtag2updi fails on paged eeprom write. This may be a limitation of the programmer but could be a bug in jtagmkII.c, cf the output tagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE.

avrdude -U falls back on bytewise access when carrying out paged access. I just pushed a commit that emulates this fallback.

@mcuee Please feel free to test --- I hope it works now with your programmer.

mcuee · 2022-10-13T00:11:01Z

The problem here is that -c jtag2updi fails on paged eeprom write. This may be a limitation of the programmer but could be a bug in jtagmkII.c, cf the output tagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE.

avrdude -U falls back on bytewise access when carrying out paged access. I just pushed a commit that emulates this fallback.

@stefanrueger

Yes it is good now. No problem with the error message as it is the limitation of the onboard jtag2updi FW.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4808 -c jtag2updi -P COM13 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  ff ff ff ff 67 74 20 69  6d 20 6b 6f 6d 70 6c 65  |....gt im komple|

avrdude> write eeprom 0x0 0xaa 0x55 0xaa 0x55
>>> write eeprom 0x0 0xaa 0x55 0xaa 0x55
avrdude> flush
>>> flush
avrdude_pr1121v1.exe: synching cache to device... 
avrdude_pr1121v1.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE
done
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  aa 55 aa 55 67 74 20 69  6d 20 6b 6f 6d 70 6c 65  |.U.Ugt im komple|

avrdude> write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff
>>> write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff
avrdude> flush
>>> flush
avrdude_pr1121v1.exe: synching cache to device... 
avrdude_pr1121v1.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE
done
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  55 aa 55 aa ff ff ff 69  6d 20 6b 6f 6d 70 6c 65  |U.U....im komple|

avrdude> quit
>>> quit

mcuee · 2022-10-13T00:15:27Z

@stefanrueger
And it even fixed my Arduino Nano Every EEPROM write problem.

Arduini Nano Every avrdude EEPROM writing issue. arduino/ArduinoCore-megaavr#120

PS C:\work\avr\avrdude_test\avrdude_bin> mode COM12 baud=12 dtr=on > nul && mode COM12 baud=12 dtr=off > nul
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4809 -c jtag2updi -P COM12 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |

avrdude> write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff
>>> write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff
avrdude> flush
>>> flush
avrdude_pr1121v1.exe: synching cache to device... 
avrdude_pr1121v1.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE
done
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  55 aa 55 aa ff ff ff 63  6b 20 62 72 6f 77 6e 20  |U.U....ck brown |

avrdude> quit
>>> quit
avrdude_pr1121v1.exe: jtagmkII_program_disable(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_close(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_close(): timeout/error communicating with programmer (status -1)

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4809 -c jtag2updi -P COM12 -b115200 -qqt
PS C:\work\avr\avrdude_test\avrdude_bin> mode COM12 baud=12 dtr=on > nul && mode COM12 baud=12 dtr=off > nul
PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4809 -c jtag2updi -P COM12 -b115200 -qqt
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
0000  55 aa 55 aa ff ff ff 63  6b 20 62 72 6f 77 6e 20  |U.U....ck brown |

avrdude> quit
>>> quit

mcuee · 2022-10-13T00:25:09Z

As for the optiboot_dx bootloader, it is the same behavior but I think that bootloader is anyway not working for EEPROM so you can ignore it.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -c arduino -P COM6 -b 115200 -p avr128db48 -qq -t
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
avrdude_pr1121v1.exe: loadCachePage() eeprom read error at addr 0x0000
avrdude_pr1121v1.exe (dump): error reading eeprom address 0x00000 of part AVR128DB48
                             read operation not supported on memory type eeprom
avrdude> quit
>>> quit

MCUdude · 2022-10-13T19:04:56Z

Here are the results of my tests with this PR. There are so many logs I decided to just write down the end result instead.

Note that the JTAG2UPDI will time out in terminal mode if not built with -D DISABLE_HOST_TIMEOUT. These are the commands I've been using (modified to match programmer and target):

./avrdude -cjtag2updi -patmega4808 -Ueeprom:r:-:I

echo "Hello World\n" | ./avrdude -cjtag2updi -patmega4808 -Ueeprom:w:-:r

echo "read eeprom 0 ..." | ./avrdude -cjtag2updi -patmega4808 -t

echo "write eeprom 0x10 \"The quick brown fox\"" | ./avrdude -cjtag2updi -patmega4808 -t

I'll provide test results for optiboot_x and optiboot_dx a little later and edit this post.

JTAG2UPDI	ATmega4808	AVR128DA32
Read from EEPROM (`-U`)	✅	✅
Write to EEPROM (`-U`)	❗️Writes content but erases the EEPROM page first, resulting in data loss	❌
Read from EEPROM (`-t`)	✅	✅
Write to EEPROM (`-t`)	✅	✅

SerialUPDI	ATmega4808	AVR128DA32
Read from EEPROM (`-U`)	✅	✅
Write to EEPROM (`-U`)	❗️Writes content but erases the EEPROM page first, resulting in data loss	✅
Read from EEPROM (`-t`)	✅	✅
Write to EEPROM (`-t`)	✅	✅

MCUdude · 2022-10-13T21:24:52Z

(Avrdude, git main)

optiboot_x / optiboot_dx	ATmega4808	AVR128DA32
Read from EEPROM (`-U`)	✅	❌
Write to EEPROM (`-U`)	❗️Writes content but erases the EEPROM page first, resulting in data loss	❌
Read from EEPROM (`-t`)	✅	❗️Reads data somehow, but returns duplicates (See output below)
Write to EEPROM (`-t`)	❗️ Writes content but duplicates it at a different address (See output below)	❌

Here's what the duplicate data for the ATmega4808 looks like:

$ echo "read eeprom 0 ..." | ./avrdude -carduino -patmega4808 -t

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9650 (probably m4808)
>>> read eeprom 0 ... 

Reading | ################################################## | 100% 0.05s

0000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0010  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0020  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0030  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0040  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0050  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0060  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0070  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0080  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0090  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00a0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00b0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00c0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00d0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00e0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00f0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|


avrdude done.  Thank you.



$ echo "write eeprom 0x20 1 2" | ./avrdude -carduino -patmega4808 -t

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9650 (probably m4808)
>>> write eeprom 0x20 1 2 

Caching | ################################################## | 100% 0.01s

avrdude: synching cache to device... done

avrdude done.  Thank you.


$ echo "read eeprom 0 ..." | ./avrdude -carduino -patmega4808 -t

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9650 (probably m4808)
>>> read eeprom 0 ... 

Reading | ################################################## | 100% 0.05s

0000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0010  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0020  01 02 aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0030  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0040  01 02 aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0050  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0060  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0070  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0080  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
0090  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00a0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00b0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00c0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00d0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00e0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
00f0  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|


avrdude done.  Thank you.

Here's what the duplicate data for the AVR128DA32 looks like:

./avrdude -cserialupdi -pavr128da32 -t

avrdude: UPDI link initialization OK
avrdude: NVM type 2: 24-bit, word oriented write
avrdude: Entering NVM programming mode
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9709 (probably avr128da32)
avrdude> write eeprom 0x20 1 2
>>> write eeprom 0x20 1 2 

Caching | ################################################## | 100% 0.02s

avrdude> quit
>>> quit 
avrdude: synching cache to device... 
Writing | ################################################## | 100% 0.09s
avrdude: Leaving NVM programming mode

avrdude done.  Thank you.


$ echo "read eeprom 0 ..." | ./avrdude -carduino -pavr128da32 -t

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9709 (probably avr128da32)
>>> read eeprom 0 ... 

Reading | ################################################## | 100% 3.01s

0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0040  01 01 02 02 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0100  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0110  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0120  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0130  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0150  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0160  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0170  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0180  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0190  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude done.  Thank you.


$ echo "read eeprom 0 ..." | ./avrdude -cserialupdi -pavr128da32 -t

avrdude: UPDI link initialization OK
avrdude: NVM type 2: 24-bit, word oriented write
avrdude: Entering NVM programming mode
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9709 (probably avr128da32)
>>> read eeprom 0 ... 

Reading | ################################################## | 100% 3.96s

0000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  01 02 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0100  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0110  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0120  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0130  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0150  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0160  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0170  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0180  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0190  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
01f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude: Leaving NVM programming mode

avrdude done.  Thank you.

However, these are the results I'm getting for AVR128DA32 when using Avrdude 6.3 and the avrdude.conf file shipped with DxCore:

optiboot_dx + Avrdude 6.3	AVR128DA32
Read from EEPROM (`-U`)	✅
Write to EEPROM (`-U`)	❌ Avrdude succeeds, but no data is actually written
Read from EEPROM (`-t`)	❌
Write to EEPROM (`-t`)	❌

stefanrueger · 2022-10-14T01:07:43Z

@MCUdude Cool testing and very clear tables. Identifies where the current code base has weaknesses. Really useful.

Will have a look later (will be a few days, though). Note that this PR #1121 and the previous related one #1106 only concern themselves with terminal mode, and address that terminal mode rarely worked for flash writes (see underlying Issue #1020).

mcuee · 2022-10-14T01:27:11Z

(Avrdude, git main)

optiboot_x / optiboot_dx	ATmega4808	AVR128DA32
Read from EEPROM(-U)	✅	❌
Write to EEPROM(-U)	❗️Writes content but erasesthe EEPROM page first, resulting in data loss	❌
Read from EEPROM(-t)	✅	❗️Reads data somehow, but returns duplicates(See output below)
Write to EEPROM(-t)	❗️ Writes content but duplicatesit at a different address(See output below)	❌

@MCUdude
Wow, you have done a very comprehensive test. Thanks.

Can you redo the test with -t with this PR and not git main? I wonder if this PR #1121 will help or not.

mcuee · 2022-10-14T01:35:45Z

@stefanrueger

Based on the test results from @MCUdude and my test results, this PR does help the terminal mode for jtag2updi and serialupdi. As for the normal CLI mode, probably more things can be done, but in another PR.

As for optiboot_x and optiboot_dx, maybe more things need to be done as well in #1120.

MCUdude · 2022-10-14T06:17:24Z

Can you redo the test with -t with this PR and not git main? I wonder if this PR #1121 will help or not.

I'm pretty sure I did all the tests with this PR, and my stating that I used git main was incorrect. I'll have to double-check when I'm home.

mcuee · 2022-10-14T06:53:44Z

Can you redo the test with -t with this PR and not git main? I wonder if this PR #1121 will help or not.

I'm pretty sure I did all the tests with this PR, and my stating that I used git main was incorrect. I'll have to double-check when I'm home.

I see. I also felt strange that you tested with git main. -U results will not be changed but I was hoping that it helps optiboot_dx in terminal mode.

mcuee · 2022-10-14T14:24:35Z

Summary of my test results, using optiboot_dx and AVR128DB48.

optiboot_dx	PR #1121	git main	PR #1110 mod with a_div=1
Read from EEPROM(-U)	❌	❌	✅
Write to EEPROM(-U)	❌	❌	❌
Read from EEPROM(-t)	❌	❗️returns duplicates	✅
Write to EEPROM(-t)	❌	❌	❌

git main terminal mode read problem -- read duplicate.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c pkobn_updi -p avr128db48 -qq -t
                 Vtarget                      : 3.31 V
                 PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude> dump eeprom 0 0x40
>>> dump eeprom 0 0x40
0000  aa 55 aa 55 ff ff ff ff  ff ff ff ff ff ff ff ff  |.U.U............|
0010  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |
0020  66 6f 78 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |fox.............|
0030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> quit
>>> quit

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c arduino -P COM6 -b 115200 -p avr128db48 -qq -t
avrdude> dump eeprom
>>> dump eeprom
0000  aa aa 55 55 aa aa 55 55  ff ff ff ff ff ff ff ff  |..UU..UU........|
0010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0020  54 54 68 68 65 65 20 20  71 71 75 75 69 69 63 63  |TThhee  qquuiicc|
0030  6b 6b 20 20 62 62 72 72  6f 6f 77 77 6e 6e 20 20  |kk  bbrroowwnn  |
0040  66 66 6f 6f 78 78 00 00  ff ff ff ff ff ff ff ff  |ffooxx..........|
0050  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
0090  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00e0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

avrdude> quit
>>> quit

MCUdude · 2022-10-14T15:54:37Z

Can you redo the test with -t with this PR and not git main? I wonder if this PR #1121 will help or not.

I'm pretty sure I did all the tests with this PR, and my stating that I used git main was incorrect. I'll have to double-check when I'm home.

I see. I also felt strange that you tested with git main. -U results will not be changed but I was hoping that it helps optiboot_dx in terminal mode.

Damnit, I pulled this PR, but I forgot to git checkout into it. This means that my tests were done with git main and not this PR. I'll have to re-run the tests with this PR later.

stefanrueger · 2022-10-14T17:12:25Z

@MCUdude I don't think you need to re-run the tests. This PR will not have changed what -U does. And I predict the changes of this PR for the terminal are only noticeable for parts that

have a page size of 1 for EEPROM
or where the programmer paged_load() and paged_write() functions throw error but where the byte-wise functions work

The problem with optiboot-x and -dx is that -c arduino no longer works the same way it did. We will fix this for #1120 once I get a clear picture what byte/word addresses are needed to be sent for which parts in -c arduino

mcuee · 2022-10-15T00:31:42Z

Damnit, I pulled this PR, but I forgot to git checkout into it. This means that my tests were done with git main and not this PR. I'll have to re-run the tests with this PR later.

@MCUdude
No problem. The good thing is that now we have the same testing results for the AVR DA/DB parts using optiboot_dx. I was initially questioning my test results but now I think the bootloader is fine. We just need to fix the issue #1120 as mentioned by @stefanrueger once he has the information available.

mcuee · 2022-10-15T00:37:02Z

@MCUdude I don't think you need to re-run the tests. This PR will not have changed what -U does. And I predict the changes of this PR for the terminal are only noticeable for parts that

have a page size of 1 for EEPROM

or where the programmer paged_load() and paged_write() functions throw error but where the byte-wise functions work

@stefanrueger
I think this PR is good and can be merged.

mcuee · 2022-10-15T01:53:51Z

@MCUdude I don't think you need to re-run the tests. This PR will not have changed what -U does. And I predict the changes of this PR for the terminal are only noticeable for parts that

have a page size of 1 for EEPROM

or where the programmer paged_load() and paged_write() functions throw error but where the byte-wise functions work

@stefanrueger

Just wondering if you can create a PR to deal with the above two situations for the -U as well. Thanks.

My Arduino Nano Every can not write EEPROM using -U due to the second issue.

Ref: arduino/ArduinoCore-megaavr#120

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -p atmega4809 -c jtag2updi -P COM12 
-b115200 -U eeprom:w:.\hex2\detest_256B.eep:i && echo OK

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

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

avrdude_git.exe: Device signature = 0x1e9651 (probably m4809)
avrdude_git.exe: reading input file .\hex2\detest_256B.eep for eeprom
avrdude_git.exe: writing 256 bytes eeprom ...

Writing |                                                    
| 0% 0.00savrdude_git.exe: jtagmkII_paged_write(): bad response to write memory command: RSP_ILLEGAL_MEMORY_TYPE
Writing | #############                                      
| 25% 0.01savrdude_git.exe: jtagmkII_write_byte(): fatal timeout/error communicating with programmer (status -1)
 ***failed;

MCUdude · 2022-10-15T18:18:42Z

I can confirm that this PR resolves issue #1120 (JTAG2UPDI + ATmega4808 and SerialUPDI + ATmega4808), but it does not resolve the issue with AVR-Dx'es, see error below. In other words, my "test tables" with this PR looks like this:

JTAG2UPDI	ATmega4808	AVR128DA32
Read from EEPROM (`-U`)	✅	✅
Write to EEPROM (`-U`)	✅	❌
Read from EEPROM (`-t`)	✅	✅
Write to EEPROM (`-t`)	✅	✅

SerialUPDI	ATmega4808	AVR128DA32
Read from EEPROM (`-U`)	✅	✅
Write to EEPROM (`-U`)	✅	✅
Read from EEPROM (`-t`)	✅	✅
Write to EEPROM (`-t`)	✅	✅

$ echo "Hello World" | ./avrdude -cjtag2updi -pavr128da32 -Ueeprom:w:-:r

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9709 (probably avr128da32)
avrdude: reading input file <stdin> for eeprom
avrdude: writing 12 bytes eeprom ...

Writing |                                                    | 0% 0.00savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ####                                               | 8% 0.02savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ########                                           | 16% 0.02savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #############                                      | 25% 0.03savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #################                                  | 33% 0.03savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #####################                              | 41% 0.04savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #########################                          | 50% 0.04savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #############################                      | 58% 0.05savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | #################################                  | 66% 0.06savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ######################################             | 75% 0.06savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ##########################################         | 83% 0.07savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ##############################################     | 91% 0.07savrdude: jtagmkII_write_byte(): bad response to write memory command: RSP_ILLEGAL_MCU_STATE
 ***failed;  
Writing | ################################################## | 100% 0.08s

avrdude: 12 bytes of eeprom written
avrdude: verifying eeprom memory against <stdin>

Reading | ################################################## | 100% 0.09s

avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x48
avrdude: verification error; content mismatch

avrdude done.  Thank you.

mcuee · 2022-10-16T00:43:58Z

@MCUdude

Since this PR deals with #1116 (terminal mode), so it is okay even with AVR128DA32. Therefore it is good to go.

The -U issue is captured in #1128. Actually I think it is the same as #1069.

JTAG2UPDI	ATmega4808	AVR128DA32
Read from EEPROM (-U)	✅	✅
Write to EEPROM (-U)	✅	❌
Read from EEPROM (-t)	✅	✅
Write to EEPROM (-t)	✅	✅

mcuee · 2022-10-16T06:09:56Z

This PR also helps optiboot (with bigboot EEPROM support) for classic AVRs. Please refer to the test results in #1129.

Better Optiboot EEPROM support for classic AVRs in terminal mode #1129

stefanrueger · 2022-10-16T20:42:19Z

Thanks for comments and tests in this PR and all other open PRs, in particular, @mcuee and @MCUdude. I think I will merge all recent PRs and we take it from there to fix further error messages and look at which -U combos can be fixed. (this particular PR only deals with -t, the terminal).

My medium-term plans are to finally integrate my own programmer urclock for very slim bootloaders, publish the bootloader, and then come back to other AVRDUDE problems.

mcuee · 2022-10-16T23:28:25Z

My medium-term plans are to finally integrate my own programmer urclock for very slim bootloaders, publish the bootloader, and then come back to other AVRDUDE problems.

That will be great. After that, maybe a new avrdude release is good to have.

mcuee · 2022-10-17T06:52:26Z

By the way, I build a jtag2updi using the Arduino Uno clone, and now it seems to perform better without the error messages compared to my Nano 4808 on-board jtag2updi.

-U now works very well.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4808 -c jtag2updi -P COM6 
-b 115200 -U eeprom:w:.\hex\entest_256B.eep:i

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

Reading | ################################################## | 100% 0.10s

avrdude_pr1121v1.exe: Device signature = 0x1e9650 (probably m4808)
avrdude_pr1121v1.exe: reading input file .\hex\entest_256B.eep for eeprom
avrdude_pr1121v1.exe: writing 256 bytes eeprom ...

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

avrdude_pr1121v1.exe: 256 bytes of eeprom written
avrdude_pr1121v1.exe: verifying eeprom memory against .\hex\entest_256B.eep

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

avrdude_pr1121v1.exe: 256 bytes of eeprom verified

avrdude_pr1121v1.exe done.  Thank you.

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4808 -c jtag2updi -P COM6 
-b 115200 -U eeprom:w:.\hex\detest_256B.eep:i

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

Reading | ################################################## | 100% 0.10s

avrdude_pr1121v1.exe: Device signature = 0x1e9650 (probably m4808)
avrdude_pr1121v1.exe: reading input file .\hex\detest_256B.eep for eeprom
avrdude_pr1121v1.exe: writing 256 bytes eeprom ...

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

avrdude_pr1121v1.exe: 256 bytes of eeprom written
avrdude_pr1121v1.exe: verifying eeprom memory against .\hex\detest_256B.eep

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

avrdude_pr1121v1.exe: 256 bytes of eeprom verified

avrdude_pr1121v1.exe done.  Thank you.

However, -t did not work at all due to communication error. Strange.

Edit: I think it is probably due to the fast time out.

erasing locked AVR32DA28 - impossible ElTangas/jtag2updi#66 (comment)

Note: You must build jtag2updi with DISABLE_HOST_TIMEOUT defined for terminal mode to work.

I have to use the trick from @MCUdude mentioned below and it works fine now. No more strange error messages.

Better Optiboot EEPROM support for classic AVRs in terminal mode #1129 (comment)

C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_pr1121v1 -p atmega4808 -c jtag2updi -P COM6 -b 115200 -qq -t
avrdude> dump eeprom 0 0x10
>>> dump eeprom 0 0x10
avrdude_pr1121v1.exe: jtagmkII_recv(): checksum error
avrdude_pr1121v1.exe: jtagmkII_paged_load(): timeout/error communicating with programmer (status -4)
avrdude_pr1121v1.exe: jtagmkII_recv(): checksum error
avrdude_pr1121v1.exe: jtagmkII_paged_load(): timeout/error communicating with programmer (status -4)
avrdude_pr1121v1.exe: jtagmkII_recv(): checksum error
avrdude_pr1121v1.exe: jtagmkII_paged_load(): timeout/error communicating with programmer (status -4)
avrdude_pr1121v1.exe: jtagmkII_recv(): checksum error
avrdude_pr1121v1.exe: jtagmkII_paged_load(): timeout/error communicating with programmer (status -4)
avrdude_pr1121v1.exe: jtagmkII_paged_load(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_paged_load(): fatal timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_read_byte(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_read_byte(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_read_byte(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_read_byte(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_read_byte(): fatal timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: loadCachePage() eeprom read error at addr 0x0000
avrdude_pr1121v1.exe (dump): error reading eeprom address 0x00000 of part ATmega4808
                             read operation not supported on memory type eeprom
avrdude> quit
>>> quit
avrdude_pr1121v1.exe: jtagmkII_program_disable(): timeout/error communicating with programmer (status -1)
avrdude_pr1121v1.exe: jtagmkII_close(): timeout/error communicating with programmer (status -1)

C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude_pr1121v1 -p atmega4808 
-c jtag2updi -P COM6 -b 115200 -qq -t
avrdude> >>> dump eeprom 0 0x10
0000  54 68 65 20 71 75 69 63  6b 20 62 72 6f 77 6e 20  |The quick brown |

avrdude>
C:\work\avr\avrdude_test\avrdude_bin> echo "write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff" | 
.\avrdude_pr1121v1 -p atmega4808 -c jtag2updi -P COM6 -b 115200 -qq -t
avrdude> >>> write eeprom 0x0 0x55 0xaa 0x55 0xaa 0xff 0xff 0xff
avrdude> avrdude_pr1121v1.exe: synching cache to device... done

C:\work\avr\avrdude_test\avrdude_bin> echo "dump eeprom 0 0x10" | .\avrdude_pr1121v1 -p atmega4808 
-c jtag2updi -P COM6 -b 115200 -qq -t
avrdude> >>> dump eeprom 0 0x10
0000  55 aa 55 aa ff ff ff 63  6b 20 62 72 6f 77 6e 20  |U.U....ck brown |

avrdude>

MCUdude · 2022-10-17T08:25:59Z

By the way, I build a jtag2updi using the Arduino Uno clone, and now it seems to perform better with the error message compared to my Nano 4808 on-board jtag2updi.

The firmware running on the 4809 Nano Every and 4808 "Nano Every" is, IIRC, quite old, and there have been numerous bug fixes to the jtag2updi project since.

mcuee · 2022-10-17T09:53:55Z

By the way, I build a jtag2updi using the Arduino Uno clone, and now it seems to perform better with the error message compared to my Nano 4808 on-board jtag2updi.

The firmware running on the 4809 Nano Every and 4808 "Nano Every" is, IIRC, quite old, and there have been numerous bug fixes to the jtag2updi project since.

@MCUdude
It is good that "Nano Every ATmega4808" from 3rd parties have the UPDI pin is available and I can use external UPDI programmers. BTW, do you happen to know the schematics for this "Nano Every ATmega4808"? I guess it does not support firmware upgrade.

Unfortunately I do not see that UPDI pin exposed by Arduino for the official Nano Every board (ATmega4809) based on the schematics.
https://docs.arduino.cc/static/1d097e7f46445e1d9a88348af88dcb4f/schematics.pdf

It does support FW upgrade but the FW is rather old.
https://github.com/arduino/ArduinoCore-megaavr/tree/master/firmwares/MuxTO

MCUdude · 2022-10-17T10:20:43Z

@mcuee the Nano 4808 doesn not have public schematics as far as I know. However, there is som information here: https://www.avrfreaks.net/forum/nano-every-use-atmega4808

The chip that handles jtag2updi has been identified to be a Nuvoton N76E003AQ20. I'm not sure how it can be upgraded. The ported jtag2updi program is also not public.

mcuee · 2022-10-17T12:06:23Z

@mcuee the Nano 4808 doesn not have public schematics as far as I know. However, there is som information here: https://www.avrfreaks.net/forum/nano-every-use-atmega4808

The chip that handles jtag2updi has been identified to be a Nuvoton N76E003AQ20. I'm not sure how it can be upgraded. The ported jtag2updi program is also not public.

I see. No point trying to figure out how to fix the on-board jtag2updi programmer in this case. Anyway, it has the updi pin available and I can use the Uno based jtag2updi to program the ATmega4808. I have quite some Uno clones anyway (they are pretty cheap).

Next step is to build a serialjtag programmer from USB to TTL converter. I have less USB to TTL converters but they are even cheaper than the Uno clones.

llinjupt · 2023-03-02T15:29:13Z

Hi All,

I don't think this patch would fix avrdx serials EEPROM writing issue. When the eeprom page size is 1, avrdude calls jtagmkII_byte_write instead of jtagmkII_paged_write to handle EEPROM writing.

To my surprise there is a variable named need_progmode in jtagmkII_write_byte and when it's flash or eeprom this vairable will be set as 0 and jtagmkII_program_disable will be called. But in jtagmkII_paged_write, it always leave progmode enabled.

After checking jtag2updi code, I learned that it always check if it is progmode before writing. So I tried to add page_size for AVR128DA48 in avrdude.conf to make avrdude call jtagmkII_paged_write and it worked.

part parent ".avrdx"
    desc                   = "AVR128DA48";
    id                     = "avr128da48";
    family_id              = "    AVR";
    mcuid                  = 368;
    n_interrupts           = 58;
    signature              = 0x1e 0x97 0x08;

    memory "eeprom"
        size               = 512;
        page_size          = 2;    // add this line 
        offset             = 0x1400;
        readsize           = 256;
    ;

    memory "flash"
        size               = 0x20000;
        page_size          = 512;
        offset             = 0x800000;
        readsize           = 256;
    ;
;

and it went well:

.\avrdude -c jtag2updi -p avr128da48 -P COM105 -b 115200 -U eeprom:w:"F:\BiTForest\ATMEL\AVRDUDESS-2.14-portable_7.1\e.bin":r

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9708 (probably avr128da48)
avrdude: reading input file F:\BiTForest\ATMEL\AVRDUDESS-2.14-portable_7.1\e.bin for eeprom
         with 512 bytes in 1 section within [0, 0x1ff]
         using 256 pages and 0 pad bytes
avrdude: writing 512 bytes eeprom ...

Writing | ################################################## | 100% 12.13 s

avrdude: 512 bytes of eeprom written
avrdude: verifying eeprom memory against F:\BiTForest\ATMEL\AVRDUDESS-2.14-portable_7.1\e.bin

Reading | ################################################## | 100% 1.05 s

avrdude: 512 bytes of eeprom verified

avrdude done.  Thank you.

I wonder why need to quit progmode in jtagmkII_write_byte. And I hope this info helps.

stefanrueger · 2023-03-03T01:08:11Z

| I don't think this patch would fix avrdx serials EEPROM writing issue.

@llinjupt Correct. This PR only deals with the terminal mode (avrdude -t). The big (non-working) Cross in above comment #1121 (comment) refers to upload mode -U. That has not been addressed in this PR.

Thanks for commenting and for your insights. Given the 20 year-old history of AVRDUDE, support for new AVR parts, new programming interfaces, and new physical programmers have been added sometimes in a haphazard way.

The idea is that avrdude.conf describes the part with needed parameters as close as possible to the data sheet and that the code base then relies on part properties. Sometimes changing avrdude.conf brings about the desired change for a particular problem, but that is not a good idea if that entry is incompatible with data sheets. Also, changing avrdude.conf may spell disaster elsewhere where another part of the code relies on the previous avrdude.conf entry.

Perhaps best to change the code base to make the functions work correctly.

Sooo, could I invite you to specify the observed wrong behaviour, create an issue if necessary, add to the issue, and keep exploring the code. It may well be that jtagmkII_write_byte does not work for the dx class of parts. Think about which parts are affected, how jtagmkII_write_byte() could detect it deals with these (perhaps by checking part->prog_mode & PM_UPDI?) and then figure out how to change the code to correctly read/write EEPROM? If you have the programmers and parts, your input would be very welcome.

Use byte-wise read/write when page size is 1 in terminal cache

48919f5

mcuee added the bug Something isn't working label Oct 11, 2022

stefanrueger added 2 commits October 12, 2022 15:53

Fall back on bytewise r/w if paged access fails for avr cache

8a3864d

Rename variable for clarity in avrcache.c

714c2fb

This was referenced Oct 13, 2022

AVRDUDE not erasing locked UPDI device #1124

Closed

Arduini Nano Every avrdude EEPROM writing issue. arduino/ArduinoCore-megaavr#120

Closed

mcuee mentioned this pull request Oct 14, 2022

Cannot access EEPROM on some bootloader/part combinations #970

Closed

This was referenced Oct 15, 2022

jtag2updi can not write EEPROM in terminal mode #1116

Closed

jtag2updi EEPROM write issue for AVR Dx parts in CLI mode #1128

Closed

This was referenced Oct 16, 2022

avrdude 7.0 jtag2updi not working with EEPROM #1069

Closed

Better Optiboot EEPROM support for classic AVRs in terminal mode #1129

Closed

stefanrueger linked an issue Oct 17, 2022 that may be closed by this pull request

jtag2updi can not write EEPROM in terminal mode #1116

Closed

stefanrueger merged commit 8e879cf into avrdudes:main Oct 17, 2022

Use byte-wise read/write when page size is 1 in terminal cache #1121

Use byte-wise read/write when page size is 1 in terminal cache #1121

Conversation

stefanrueger commented Oct 11, 2022

mcuee commented Oct 12, 2022 • edited Loading

mcuee commented Oct 12, 2022 • edited Loading

mcuee commented Oct 12, 2022

mcuee commented Oct 12, 2022 • edited Loading

avrfreak commented Oct 12, 2022

mcuee commented Oct 12, 2022 • edited Loading

avrfreak commented Oct 12, 2022

stefanrueger commented Oct 12, 2022

mcuee commented Oct 13, 2022

mcuee commented Oct 13, 2022 • edited Loading

mcuee commented Oct 13, 2022

MCUdude commented Oct 13, 2022

MCUdude commented Oct 13, 2022

stefanrueger commented Oct 14, 2022

mcuee commented Oct 14, 2022 • edited Loading

mcuee commented Oct 14, 2022

MCUdude commented Oct 14, 2022

mcuee commented Oct 14, 2022

mcuee commented Oct 14, 2022 • edited Loading

MCUdude commented Oct 14, 2022

stefanrueger commented Oct 14, 2022

mcuee commented Oct 15, 2022

mcuee commented Oct 15, 2022 • edited Loading

mcuee commented Oct 15, 2022 • edited Loading

MCUdude commented Oct 15, 2022 • edited Loading

mcuee commented Oct 16, 2022 • edited Loading

mcuee commented Oct 16, 2022 • edited Loading

stefanrueger commented Oct 16, 2022

mcuee commented Oct 16, 2022 • edited Loading

mcuee commented Oct 17, 2022 • edited Loading

MCUdude commented Oct 17, 2022

mcuee commented Oct 17, 2022

MCUdude commented Oct 17, 2022

mcuee commented Oct 17, 2022

llinjupt commented Mar 2, 2023

stefanrueger commented Mar 3, 2023

mcuee commented Oct 12, 2022 •

edited

Loading

mcuee commented Oct 12, 2022 •

edited

Loading

mcuee commented Oct 12, 2022 •

edited

Loading

mcuee commented Oct 12, 2022 •

edited

Loading

mcuee commented Oct 13, 2022 •

edited

Loading

mcuee commented Oct 14, 2022 •

edited

Loading

mcuee commented Oct 14, 2022 •

edited

Loading

mcuee commented Oct 15, 2022 •

edited

Loading

mcuee commented Oct 15, 2022 •

edited

Loading

MCUdude commented Oct 15, 2022 •

edited

Loading

mcuee commented Oct 16, 2022 •

edited

Loading

mcuee commented Oct 16, 2022 •

edited

Loading

mcuee commented Oct 16, 2022 •

edited

Loading

mcuee commented Oct 17, 2022 •

edited

Loading