Eeprom file written correctly with avrdude 7.1 generates error with 7.2 #1508
Labels
bug
Something isn't working
Comments
|
Can you post the entire Avrdude output, so we can see what kind of programmer you're using and other Avrdude-related information? |
|
HEX FILE one.eep.hex OUTPUT FROM 7.2 OUTPUT FROM 7.1 |
|
Hello,
this reminds me off a problem with older versions that
results from EEPROM written in pages (4 Bytes). (Atmega328P)
Writing a singe byte did not work. The neighbors of the page
always been written.
I do not know if this relates. I have not investigated further
Martin
Am 09.10.2023 um 10:35 schrieb surfblink:
… Overview
An eeprom file, which is correctly written to an atmega328p by avrdude
6.3 7.0 and 7.1, generates a verification error when written with
avrdude 7.2. Looking at the eeprom in -t mode shows that the eeprom has
not been correctly written.
Example error
The original eeprom file is relatively large but a similar error
can be reproduced with this small hex file.
With 7.2 this hex file is incorrectly written, but with 7.1 no error
:02000200AABB97
:00000001FF
I tried a few more examples
Add a line and it is correctly written with 7.2 and 7.1
:02000000DDCC55
:02000200AABB97
:00000001FF
But this file is also correctly written with 7.2 and 7.1
:02000400AABB95
:00000001FF
And finally this is the line from the original file which caused the
error with 7.2 but not 7.1 7.0 and 6.3
:10003400FFFFF00AC4019000F1095C00B008EB0A6C
:00000001FF
Is is possible to confirm this behaviour (outside of my setup)?
Kind regards and thanks,
Tristan
—
Reply to this email directly, view it on GitHub
<#1508>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTXTRQWQFNA6FUWP4QLTITX6OZONAVCNFSM6AAAAAA5YNWKF6VHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZTENJWGI3TENI>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
----------------------------------------------------------------
Martin Pischky, Oisseler Strasse 1C, 30559 Hannover, Germany
http://www.pischky.de ***@***.***
tel: +49 511 7000665 mobile: +49 151 11592222
----------------------------------------------------------------
|
|
No issues with the hex file using usbasp programmer, using both avrdude 7.2 release and git main. Need to dig out my USBtinyISP to carry out the test. |
|
Edit -- ignore this. I can reproduce the issue once I erase the EEPROM contents first. |
|
Edit -- ignore this. I can reproduce the issue. |
|
Hmm, I can reprodcue the issue after erasing the EEPROM contents using usbasp and then test again. |
mcuee
added
bug
|
It is easier to use terminal mode to demonstrate the problem. Looks like we have a regression in avrdude 7.2 for USBtinyISP from avrdude 7.1. |
|
Good this is reproducible. This seems to be specific to |
Looks like it is an isue unique to |
|
Note to myself: use I have some old binary files kept in my computer. Now I zoomed the issue to be between PR#1273 (good, 14-Jan-2023) and PR #1286 (bad, 5-Mar-2023). I will further zoom down the commit tomorrow using the method similar to
PR $1320 is also bad.
PR #1309 is also bad.
PR #1286 is already bad. |
|
Other info. #1282 is good and #1309 is bad. #1318 is also bad.
|
|
I've traced the issue down to this commit: a3b7072 Does not work: Works: |
|
It seems like adding diff --git a/src/avrdude.conf.in b/src/avrdude.conf.in
index 68bf49db..436b7965 100644
--- a/src/avrdude.conf.in
+++ b/src/avrdude.conf.in
@@ -8206,6 +8206,7 @@ part
min_write_delay = 3600;
max_write_delay = 3600;
mode = 0x41;
+ readback = 0xff 0xff;
delay = 20;
blocksize = 4;
readsize = 256;EDIT: And I just tried with an AVRISPmkII as well (stk500v2.c also utilizes |
|
Well traced! Atmel's ATmega328P.atdf file says about the part's eeprom So, wondering whether the .atdf has it wrong or IIRC the memory I suspect values |
|
Sorry, but that doesn't work reliably: However, I power cycled the USBtiny programmer, and I was able to properly program and verify on the second attempt. However, with |
|
OK, we need to figure out what should happen. Best to find documentation about eeprom/flash
avrdude -p*/At | grep eeprom.mode >/tmp/m
avrdude -p*/At | grep eeprom.readback >/tmp/r
paste /tmp/[mr] | cut -f2,5,10 >/tmp/j
cut -f2- /tmp/j | sort | uniq -c
147 0x00 0x00 0x00
8 0x04 0x00 0xff
4 0x04 0x80 0x7f
16 0x04 0xff 0xff
155 0x41 0x00 0x00
3 0x41 0xff 0xffThat is a lot of parts. The three parts with eeprom mode 0x41 and readback 0xff 0xff don't actually have an .atdf file: Given all this, and assuming STK500 and STK500v2 programmers work with the difficult file in git main, I'd suggest diff --git a/src/usbtiny.c b/src/usbtiny.c
index 2efaaec8..1adb2577 100644
--- a/src/usbtiny.c
+++ b/src/usbtiny.c
@@ -721,9 +721,9 @@ static int usbtiny_paged_write(const PROGRAMMER *pgm, const AVRPART *p, const AV
delay = 0;
if (! m->paged) {
- unsigned int poll_value;
- // Does this chip not support paged writes?
- poll_value = (m->readback[1] << 8) | m->readback[0];
+ unsigned int poll_value = (m->readback[1] << 8) | m->readback[0];
+ if(!poll_value)
+ poll_value = 0xffff;
if (usb_control(pgm, USBTINY_POLL_BYTES, poll_value, 0 ) < 0)
return -1;
delay = m->max_write_delay;That should do the trick. |
|
PR #1511 works for me. Please check as well. Thanks. |
|
Thank you for addressing this issue. I believe I have built PR #1511 I have included the default help output so I would grateful if you could check that I am running the required version. Sadly, it does not work for my (a generic 2313A based) usbtiny. Both the example hex file and the actual hex (that highlighted the issue to me give) verification errors. |
|
@surfblink You need to checkout the PR's branch usbtiny-readback before building and installing: git clone git@github.com:stefanrueger/avrdude pr1511
cd pr1511
git checkout usbtiny-readback
# build and install for your OS |
|
Thank you for you help with building the correct version. avrdude version 7.2-20231010 (64f4646), https://github.com/avrdudes/avrdude Success Both the example file and the original hex file are written without verification errors. Thank you fixing this so efficiently. Much appreciated. Outputs below. |
|
@surfblink Thank you for reporting. for going to the trouble of identifying a minimum eeprom file that exposes the problem and for confirming the PR works. This issue will close automatically when the PR is merged (may take a few days). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
An eeprom file, which is correctly written to an atmega328p by avrdude 6.3 7.0 and 7.1, generates a verification error when written with avrdude 7.2. Looking at the eeprom in -t mode shows that the eeprom has not been correctly written.
Example error
The original eeprom file is relatively large but a similar error
can be reproduced with this small hex file.
With 7.2 this hex file is incorrectly written, but with 7.1 no error
I tried a few more examples
Add a line and it is correctly written with 7.2 and 7.1
But this file is also correctly written with 7.2 and 7.1
And finally this is the line from the original file which caused the
error with 7.2 but not 7.1 7.0 and 6.3
Is is possible to confirm this behaviour (outside of my setup)?
Kind regards and thanks,
Tristan
The text was updated successfully, but these errors were encountered: