bugAVR Downloader/UploaDEr - Bugs: bug #41561, AVRDUDE 6.0.1/USBasp doesn't write...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #41561: AVRDUDE 6.0.1/USBasp doesn't write first bytes of flash page

Submitter:  Michal Salaban <emes>
Submitted:  Wed 12 Feb 2014 02:29:09 AM UTC
Votes: 10
 
Category:  None Severity:  3 - Normal
Priority:  7 - High Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  Michal Salaban
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Mon 23 Nov 2015 10:46:50 AM UTC, comment #30: 

This bug has been fixed with the release of avrdude 6.2

Jim Perkins <rperkins>
Mon 16 Nov 2015 10:02:16 AM UTC, comment #29: 

Here a short HowTo for Debian dependent distributions:
======================================================

$ apt-get install libelf-dev libftdi-dev libftdi1 libhidapi-dev

$ ./bootstrap
$ ./configure
$ make
$ make install

======================================================

I will attach avrdude-6.1-20140519-x86-64.zip
When you don't want to compile then
just copy the two binaries two /usr/local/bin
The avrdude.conf copy to /etc

Then you have
avrdude: Version 6.1-20140519, compiled on Nov 16 2015 at 10:27:14

I tested it and i can program an ATMega128 with it.

(file #35471)

Karsten <kama>
Sun 15 Nov 2015 04:32:57 PM UTC, comment #28: 

Thanks.

Trying to checkout and compile the actual release fails, because the configure is missing.

$ svn co svn://svn.savannah.nongnu.org/avrdude/trunk/
...
A    trunk/avrdude/ChangeLog-2014
A    trunk/avrdude/usbtiny.c
Ausgecheckt, Revision 1361.

cd trunk/avrdude
$ ./configure
bash: ./configure: Datei oder Verzeichnis nicht gefunden


The compiled binary for Ubuntu is working.

Karsten <kama>
Sun 15 Nov 2015 03:20:11 PM UTC, comment #27: 

Hello

Even though that bug has been closed for nearly one year, I do not believe the released version of avrdude has been fixed.  My comment verifying the resolution states that  'r1343 resolved this issue'.  Looking at the first line of your attached avrdude.conf, you can see that avrdude 6.1 is revision 1294 of the avrdude source tree

  # $Id: avrdude.conf.in 1294 2014-03-12 23:03:18Z joerg_wunsch $ -*- text -*-

Furthermore you can see the same information by viewing the tags directory of the avrdude source tree.
http://svn.savannah.nongnu.org/viewvc/tags/RELEASE_6_1/?root=avrdude
This will also show that RELEASE_6_1 of the avrdude src is revision 1294.

1294 < 1343

So unless your packager of avrdude cherry pics this patch or until a new release of avrdude is produced, this bug is still active in the latest release of avrdude.

You do have the option of compiling a more recent version of avrdude .  If you are on linux there are 2 solutions listed here
http://openrcforums.com/forum/viewtopic.php?f=94&t=5036#p89779.
If on a mac then maybe you can search the web for a more recent compiled version.

Of course I could be mistaken about my understanding and hopefully Joerg will make better sense of the current situation .

Jim Perkins <rperkins>
Sun 15 Nov 2015 01:02:48 PM UTC, comment #26: 

Maybe the bug is back again, because i have the same problem now with avrdude: Version 6.1

___________________________________________________________________________

/usr/local/bin/avrdude -p m128 -P usb -c usbasp -U flash:w:main.hex:i
...
avrdude: 11440 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 11440 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.70s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0100
         0xff != 0x0d
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:FF, H:90, L:8F)

avrdude done.  Thank you.
___________________________________________________________________________

I will attach a complete log with -vvvv and the avrdude.conf

(file #35465)

Karsten <kama>
Fri 21 Nov 2014 02:23:22 AM UTC, comment #25: 

Wanted to confirm that r1343 resolved this issue.  thanks so much.

Tested on 64bit linux.  verified 4 different usbasp firmwares.  verified flash and eeprom writes.  Hardware used was a M64 in a Turnigy 9x RC transmitter.

Now how do I go about getting linux distros to pull the updated code.  I'm thinking of opening a bug report on Debian/ubuntu Redhat/fedora pointing to a fixed release.  Do you plan on releasing a .point release for this or should I just point them to r1343 as the fix ??  Any advise along this line is appreciated.

Regarding the firmware change I tacked onto this issue:  Thomas Fischl has contacted me and I'll be following up with him.  I would like to say that with avrdude r1343 the stock 2011 usbasp firmware seems to work better at higher speeds (>375khz) better than any of the other firmwares.  Sometimes, at the higher speeds, the other firmwares would report the wrong device Id when running multiple avrdude commands sequentially.  Part of this problem could be the hardware I am using, specifically the size of the capacitor on the reset line.

thanks again for resolving my problem


Jim Perkins <rperkins>
Thu 20 Nov 2014 09:22:09 AM UTC, comment #24: 

I've got a confirmation that omitting USBASP_BLOCKFLAG_LAST is
the right thing to do, so this finally ought to be fixed in
a way that makes it compatible with the existing firmware.

Fixed in r1343.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 20 Nov 2014 03:42:50 AM UTC, comment #23: 

reply to comment 20

> If I remove the USBASP_BLOCKFLAG_LAST (line 1330, function
> usbasp_spi_paged_write()), it seems to work as intended, but


I found the variable mentioned but in my src I think it is on line 798

$ grep  -d skip -n USBASP_BLOCKFLAG_LAST *;svn info| grep Revision
usbasp.c:798:      blockflags |= USBASP_BLOCKFLAG_LAST;
usbasp.h:48:#define USBASP_BLOCKFLAG_LAST     2
Revision: 1342

Jim Perkins <rperkins>
Wed 19 Nov 2014 09:34:04 PM UTC, comment #22: 

thanks for confirming the issue, verifying that it isnt board dependent, and explaining why usbasp doesnt write an entire 256 byte page at once.

Hopefully a solution will present itself that can use the new 'per page basis' but will also allow existing usbasp's to continue to operate with avrdude 6.x and beyond.

If an update to the usbasp firmware comes out of this I would like to see if it is possible to submit for review portions of a patch of the 2009 firmware.  I do not understand completely how the firmware works but believe most of the benefits of the patch were incorporated into the 2011 firmware except for the pulsing of the RST instead of the SCK in the isp.c source code for the usbasp firmware.  I sent a message out to Thomas Fischl on 11/13/12 but got no response.  Maybe the timing is better now or maybe this change is not needed.  The issue to my limited understanding is that sometimes the usbasp would hang due to unnecessary pulses of the RST

I probably shouldnt have attached this with this bug and apologize for that.  It just feels like an opportune time to possible get some attention for it.  I'd like nothing better than to ship official, stock, usbasp firmware on my devices .

Any advise would be appreciated.  Thanks

 --- isp.c.orig  2013-03-20 06:23:23.113763503 -0400
+++ isp.c       2013-03-20 08:00:01.725692472 -0400
@@ -197,9 +197,9 @@

                /* pulse RST */
                ispDelay();
-               ISP_OUT |= (1 << ISP_RST); /* RST high */
+               ISP_OUT |= (1 << ISP_SCK); /* SCK high */
                ispDelay();
-               ISP_OUT &= ~(1 << ISP_RST); /* RST low */
+               ISP_OUT &= ~(1 << ISP_SCK); /* SCK low */
                ispDelay();

                if (ispTransmit == ispTransmit_hw) {

Jim Perkins <rperkins>
Wed 19 Nov 2014 04:33:13 PM UTC, comment #21: 

(Reply to comment #15)

> the page size is 256 but the software is not writing 256
> at one time.


This is because USBasp implementation imposes a maximum block
size of 200 in the AVRDUDE code.  I don't know whether this
is strictly necessary; I cannot find this restriction in the
firmware itself.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 19 Nov 2014 04:25:27 PM UTC, comment #20: 

The issue must have been in the firmware all the time.  I
cannot really follow the logic there immediately.

The difference to before r1007 is that AVRDUDE now works on
a per-page basis throughout all programmers, rather than
on the entire device memory.

If I remove the USBASP_BLOCKFLAG_LAST (line 1330, function
usbasp_spi_paged_write()), it seems to work as intended, but
I don't know whether this might cause other odd side effects.

I'm handing this over to Thomas Fischl as he seems to be the
most knowledgable person to really fix it.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 19 Nov 2014 03:49:22 PM UTC, comment #19: 

I traced the ISP traffic with a logic analyzer, and decoded
the data stream back into ISP commands.  See the attachment
for the full trace.  The bug is that the "write memory page"
command is issued twice:


Time  393.416 ms: MOSI Load program memory page, address 0x007f,  low byte, value 0x6d
Time  393.910 ms: MOSI Load program memory page, address 0x007f, high byte, value 0x6d
Time  394.370 ms: MOSI Write program memory page, address 0x007f
Time  394.804 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  395.218 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  395.688 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  396.131 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  396.538 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  397.013 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  397.427 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  397.903 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  398.368 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  398.805 ms: MOSI Read program memory, address 0x007f, high byte, value 0x6d
Time  399.222 ms: MOSI Write program memory page, address 0x007f
Time  399.686 ms: MOSI Read program memory, address 0x007f, high byte, value 0x6d
Time  401.510 ms: MOSI Load program memory page, address 0x0080,  low byte, value 0x6f
Time  402.139 ms: MOSI Load program memory page, address 0x0080, high byte, value 0x72


After filling the page buffer, the page is being programmed at time
394.370 ms.  Then, USBasp polls the page for a response != 0xff, which
indicates the end of the write operation (time 398.805 ms).  However,
just after this, it issues another "write page" command at 399.222 ms,
but then proceeds to fill the page buffer again for the next page.

Apparently, the old devices (ATmega64/128) respond to the second page
write immediately with a poll value of "OK" (i.e., they return the
correct value), yet they are still busy programming afterwards.  In
contrast, the newer devices (like ATmega1281) correctly respond again
with 0xff for the second page write operation:


Time  391.417 ms: MOSI Load program memory page, address 0x007f,  low byte, value 0x6d
Time  391.910 ms: MOSI Load program memory page, address 0x007f, high byte, value 0x6d
Time  392.371 ms: MOSI Write program memory page, address 0x007f
Time  392.806 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  393.218 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  393.689 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  394.130 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  394.539 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  395.014 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  395.428 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  395.903 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  396.369 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  396.806 ms: MOSI Read program memory, address 0x007f, high byte, value 0x6d
Time  397.222 ms: MOSI Write program memory page, address 0x007f
Time  397.687 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  398.130 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  398.539 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  399.013 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  399.431 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  399.903 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  400.368 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  400.805 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  401.218 ms: MOSI Read program memory, address 0x007f, high byte, value 0xff
Time  401.688 ms: MOSI Read program memory, address 0x007f, high byte, value 0x6d
Time  403.640 ms: MOSI Load program memory page, address 0x0080,  low byte, value 0x6f
Time  404.155 ms: MOSI Load program memory page, address 0x0080, high byte, value 0x72


which explains why they can be programmed fine.

But obviously, the second page write operation is completely unnecessary.


(file #32475, file #32476)

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 19 Nov 2014 11:07:02 AM UTC, comment #18: 

I can confirm that ATmega64 and ATmega128 sitting in a plain
old STK500 are affected, too.  (ATmega103 doesn't work at all
with USBasp.)  So it's at least not board dependant.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 19 Nov 2014 06:33:02 AM UTC, comment #17: 

Maybe this issue is related to the hardware we are using

I did some more testing and on one of my computers I was able to vary (but not eliminate) the number of bytes that werent written correctly by slowing down the programming using the -B option to avrdude.

I was wondering if the changes made by r1007 (memory tagging) made the timing of the programming more critical.  Along the same lines I was wondering if the function USBASP_FUNC_WRITEFLASH was utilized twice (when the error happens) for a single page could be caused by timing problems.

The M64 board that I have is the same one that the OP and the other reporter has.  This is not a M64 on a breadboard.  It is part of an RC radio that was not designed to be reprogrammed.  There is circuitry on the miso and mosi lines.  those lines are used as a switch input during normal MCU execution.
http://openrcforums.com/forum/download/file.php?id=3075

We have had trouble in the past reprogramming these boards using usbasp's that had a relatively large resistor used as series limiter on the programming lines.

I wanted to put this out before you spent too much time chasing down an M64.  Tomorrow I will investigate purchasing an M64 and building a M64 on a  breadboard or finding a inexpensive dev board with an M64.  Any advice regarding an inexpensive dev board with an m64 would be appreciated.

thanks

Jim Perkins <rperkins>
Tue 18 Nov 2014 10:41:36 PM UTC, comment #16: 

Sorry I should have mentioned the tests were with avrdude 6.0.1.

Jim Perkins <rperkins>
Tue 18 Nov 2014 10:39:32 PM UTC, comment #15: 

When writing to an M64 MCU the output of -vvvv does not seem correct for a paged write when compared to other processors.  the page size is 256 but the software is not writing 256 at one time.

The relevant section of the -vvvv output is pasted here.  attached is the entire -vvvv output and the hex file that was attempted to be written.  The hex file was created to be easy to track the pages, but is not something the MCU would actually run.


avrdude: reading input file "256x2-sequential_test.hex"
avrdude: writing flash (512 bytes):

Writing | avrdude: usbasp_program_paged_write("flash", 0x0, 256)
avrdude: usbasp_transmit("USBASP_FUNC_SETLONGADDRESS", 0x00, 0x00, 0x00, 0x00)
avrdude: usbasp_transmit("USBASP_FUNC_WRITEFLASH", 0x00, 0x00, 0x00, 0x11)
          => [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07]
avrdude: usbasp_transmit("USBASP_FUNC_SETLONGADDRESS", 0xc8, 0x00, 0x00, 0x00)
avrdude: usbasp_transmit("USBASP_FUNC_WRITEFLASH", 0xc8, 0x00, 0x00, 0x12)
          => [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f] [00] [01] [02] [03] [04] [05] [06] [07] [08] [09] [0a] [0b] [0c] [0d] [0e] [0f]
#########################avrdude: usbasp_program_paged_write("flash", 0x100, 256)


(file #32470, file #32471)

Jim Perkins <rperkins>
Tue 18 Nov 2014 10:33:01 PM UTC, comment #14: 

Thanks for doing some testing.

I have completed the following tests.

SUMMARY - the issue is seems limited to the M64 MCU using any available firmware

I attempted to write to various MCU's using a Usbasp with 2011_fischl firmware.  ONLY THE M64 failed.

The M8, M328P , ATMega M2560 all worked fine


2. the problem persists trying to write to a M64 MCU using the following firmwares : 2011_fischl, 2009_fischl, 2009_fischl_patched, chinese_unknown source.

When testing the Fischl firmware I utilized the pre compiled firmware provided from within the source from http://www.fischl.de/usbasp/

I dont believe the problem is related to the firmware

Jim Perkins <rperkins>
Tue 18 Nov 2014 11:49:58 AM UTC, comment #13: 

I just tried it (SVN version) using my own USBasp device.
Uploading a large (about 100 KB) file to an ATmega2560 worked
fine:


% ./avrdude -C avrdude.conf -c usbasp -B1 -p atmega2560 -U lorem.elf

avrdude: set SCK frequency to 750000 Hz
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9801 (probably m2560)
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: set SCK frequency to 750000 Hz
avrdude: reading input file "lorem.elf"
avrdude: input file lorem.elf auto detected as ELF
avrdude: writing flash (100616 bytes):

Writing | ################################################## | 100% 53.92s

avrdude: 100616 bytes of flash written
avrdude: verifying flash memory against lorem.elf:
avrdude: load data flash data from input file lorem.elf:
avrdude: input file lorem.elf auto detected as ELF
avrdude: input file lorem.elf contains 100616 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 38.93s

avrdude: verifying ...
avrdude: 100616 bytes of flash verified

avrdude: safemode: Fuses OK (E:FE, H:19, L:E2)

avrdude done.  Thank you.


Alas, my device doesn't tell me which firmware version is
beign used.  I think it is the 2011 version, because I
remember the reason I built my USBasp was to test the TPI
stuff in AVRDUDE.

For reference, I also appended my -vvvv logfile.

(file #32458)

Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 16 Nov 2014 08:21:37 PM UTC, comment #12: 

yes the firmware is an important variable.  I am setting up a test bed so that any further tests only use the latest (2011) firmware from fischl . I did verify this error using the fisch latest firmware when this issue surfaced

I would like to comment on what firmware is out there.

1. Most Chinese manufactured usbasp use a closed source firmware.  I believe the vast majority of usbasp in use are using a closed source firmware. Ebay/Hobbyking/Amazon etc.  There is no way to accommodate this firmware.  Most of the time it is locked on the usbasp
2. Then there is the latest firmware from http://www.fischl.de/usbasp/  (the 2011 firmware )
3. The open source RC enthusiasts are particular to a modified version of the 2009 firmware which solved some issues with the 2011 firmware generating resets which restricted multiple programming sequences without unplugging and replugging the usbasp into the computer.  this modified firmware also mentions 'always emitting an extended address' but I believe the 2011 fisch firmware does that.  This is the firmware that I put on my devices.  Basically I purchase chinese usbasp and reprogram them with open source firmware
http://openrcforums.com/forum/viewtopic.php?f=109&t=1363

Jim Perkins <rperkins>
Sun 16 Nov 2014 07:32:51 PM UTC, comment #11: 

OK, r1007 introduced memory tagging.  Before, all memories
had been treated as a large block of <N> bytes (N = size of
that memory area on the chose device), regardless of whether
their contents actually came from an input file.

Now, only those regions are touched that have corresponding
bytes in the input file.  (For paged memory areas, the term
"region" here refers to the situation where at least one byte
within a memory page has been mentioned in the input file.)

Quite possible something has been broken by this rather large
change, though it would be surprising why it only affects
USBasp then.  It's also possible the change simply uncovered
a firmware issue that used to exist before, but was never
noticed with the old scheme.

I'm adding Thomas Fischl to the Cc list, maybe he can have a
look at the problem before I'll find the time to do so.

Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 16 Nov 2014 01:15:04 PM UTC, comment #10: 

Hello
I was able to narrow this issue down to rev 1007
http://svn.savannah.nongnu.org/viewvc?view=rev&root=avrdude&revision=1007

rev 1006 works as expected but rev 1007 verification errors.
both revs present themselves as 5.11cvs

This is with an M64 MCU.  I dont believe smaller MCU's are affected.

Compiled on Ubuntu 14.04.1 LTS  with libusb-1.0-0-dev and/or libusb-dev

Please note that in this case the usbasp is embedded in the RC radio so I was not able to verify the firmware that is on the usbasp.  I did reread my notes from this spring in which I verified the error on stock 2011 usbasp firmware.
http://openrcforums.com/forum/viewtopic.php?f=94&t=5036&p=89522&hilit=avrdude+6.x#p70969

thanks and let me know if I can be of more assistance

Jim Perkins <rperkins>
Sun 16 Nov 2014 09:59:02 AM UTC, comment #9: 

continuing extracting compressed files of the OP.  This is where the written hex is read back and read-flash.hex shows a recurring set of bits set to FF every 0x0100

:20010000FFFFFFFFFFFFFFFF4A6656665A66626669666D666F6673667566776679667D6629

thanks and let me know if you need anything else

(file #32445, file #32446, file #32447, file #32448)

Jim Perkins <rperkins>
Sun 16 Nov 2014 09:53:09 AM UTC, comment #8: 

Thanks for the response.
Yes you are correct we are not using TPI

I have extracted the compressed file provied by the OP.  I has the -vvv logs

(file #32441, file #32442, file #32443, file #32444)

Jim Perkins <rperkins>
Sun 16 Nov 2014 08:49:02 AM UTC, comment #7: 

Commit r1191 only affects TPI-related functions (ATtiny10 et al.),
so I don't think it's related.

Please run with -vvvv (which is supported now also on USBasp).

Joerg Wunsch <joerg_wunsch>
Group administrator
Sun 16 Nov 2014 05:42:10 AM UTC, comment #6: 

I sell usbasp to rc modelers so they can reprogram their radios, esc.s and flight controllers.  I commented on this bug when it was posted.  Now the major linux distributions are using avrdude 6.x and I had the first instance of a customer being hit by this bug.

It looks like this bug also affects mac builds
http://openrcforums.com/forum/viewtopic.php?f=95&t=6304


I believe the bug only affects MCU's that are 64k or bigger.  Maybe it is related to page size. 

going to try to narrow down which commit is the one that started the issue

this one got my attention but dont know for sure
http://svn.savannah.nongnu.org/viewvc?view=rev&root=avrdude&revision=1191

If there is something specific needed to resolve this issue I am willing to try to help

Jim Perkins <rperkins>
Wed 12 Feb 2014 09:09:39 AM UTC, comment #5: 

Downgraded to 5.11svn-20111019. It fails even more, signalling first verify mismatch at address 0x0000.

Re-reading the flash takes normal amount of time but results in a strange, single-byte (0xff) hex dump.

Downgraded to full 5.11 — worked like a charm!

Perhaps we should change the title, as it seems unrelated to windows/linux difference :)

Michal Salaban <emes>
Wed 12 Feb 2014 08:47:52 AM UTC, comment #4: 

Here's the full log from linux box.

On windows I installed libusb, but I cannot guarantee that avrdude uses it. I flash the device using gui wrapper named companion9x:
https://code.google.com/p/companion9x/downloads/detail?name=companion9xInstall_v1.52.exe

Important thing here: that software contains avrdude 5.11-Patch #7610. This is something I've just realized. Will try to downgrade my linux version.

Another interesting thing is that when I select fast mode on the programmer, the linux version randomly fails to write flash with "target doesn't answer" or "invalid signature" (0x000102 instead of 0x1e9602). The original bug, however, occurs both in fast and slow mode.

(file #30523)

Michal Salaban <emes>
Wed 12 Feb 2014 05:59:21 AM UTC, comment #3: 

Can you attach a -vvvv log?

Do you know whether the windows version uses the libusb driver, or
the HID one?

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 12 Feb 2014 02:40:17 AM UTC, comment #2: 

Thanks for posting this bug.  I have been researching this issue but did not know it was linux only.  My information including hex files and a diff of the write error is located at

http://openrcforums.com/forum/viewtopic.php?f=94&t=5036

If I can help to resolve this possible bug let me know I can help

Jim Perkins <rperkins>
Wed 12 Feb 2014 02:31:16 AM UTC, comment #1: 

BTW the programmer has already flashed a handful of atmega8 and attiny85 while connected to one of these affected PCs. No problems ever.

Michal Salaban <emes>
Wed 12 Feb 2014 02:29:09 AM UTC, original submission:  

I'm flashing a RC model transmitter, which is based on atmega64a chip. The programmer is usbasp connected through ISP.

Flash reading works well.
Writing, however, results in a strange error. First of all, the message is:


Reading | ################################################## | 100% 371.64s

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

avrdude: safemode: Fuses OK (H:FF, E:89, L:0E)

avrdude done.  Thank you.


This is 100% reproducible, no matter if I select slow or fast programming mode by usbasp jumper or I power the device via the programmer or externally.

It has been also checked on two different machines, i86-32 and i86-64. Same results.

The re-read flash exhibits strange pattern. Starting from offset 0x100, every 0x100 bytes on there is a row of bytes with value 0xff. Usually there are eight of them, sometimes seven.

My guess is that at the beginning of each flash page (which is 0x100 bytes long AFAIK) the initial data goes missing.

The same device with the same programmer, connected to windows on i86-32, gets flashed and verified with zero problems.


The linux boxes keep quiet about any errors. Nothing in dmesg there. Both use Arch distro, 3.11.6 kernel.

Michal Salaban <emes>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #35471:  avrdude-6.1-20140519-x86-64.zip added by kama (650KiB - application/zip)
file #35465:  avrdude.log.zip added by kama (55KiB - application/zip - Log with failed flash program avrdude version 6.1)
file #32475:  usbasp-trace-64.txt added by joerg_wunsch (389KiB - text/plain - Logic analyzer traces for ATmega64 and ATmega1281, respectively.)
file #32476:  usbasp-trace-1281.txt added by joerg_wunsch (395KiB - text/plain - Logic analyzer traces for ATmega64 and ATmega1281, respectively.)
file #32470:  256x2-sequential_test.hex added by rperkins (1KiB - text/x-hex - out.txt is the -vvvv log . the hex file was created for debugging)
file #32471:  out.txt added by rperkins (33KiB - text/plain - out.txt is the -vvvv log . the hex file was created for debugging)
file #32458:  jwunsch.txt.bz2 added by joerg_wunsch (34KiB - application/x-bzip2 - Logfile from Joerg where all is going well)
file #32445:  avrdude-version.txt added by rperkins (2KiB - text/plain - read.log is the -vvv output of avrdude)
file #32446:  read.log added by rperkins (428KiB - text/x-log - read.log is the -vvv output of avrdude)
file #32447:  bug.sh added by rperkins (225B - application/x-shellscript - read.log is the -vvv output of avrdude)
file #32448:  read-flash.hex added by rperkins (126KiB - text/x-hex - read.log is the -vvv output of avrdude)
file #32441:  avrdude-version.txt added by rperkins (2KiB - text/plain - write.log is the -vvv output of avrdude)
file #32442:  write.log added by rperkins (710KiB - text/x-log - write.log is the -vvv output of avrdude)
file #32443:  bug.sh added by rperkins (225B - application/x-shellscript - write.log is the -vvv output of avrdude)
file #32444:  written-flash.hex added by rperkins (149KiB - text/x-hex - write.log is the -vvv output of avrdude)
file #30523:  bug.tar.gz added by emes (284KiB - application/gzip - Full bug reproduction with -vvvv logs)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kama (Updated the item)
  • -email is unavailable- added by joerg_wunsch (Thomas Fischl)
  • -email is unavailable- added by rperkins (Voted in favor of this item)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by rperkins (Posted a comment)
  • -email is unavailable- added by emes (Submitted the item)
  •  

    There are 10 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-16 kama Attached File- Added avrdude-6.1-20140519-x86-64.zip, #35471
    2015-11-15 kama Attached File- Added avrdude.log.zip, #35465
    2014-11-20 joerg_wunsch StatusConfirmed Fixed
        Assigned tofischl joerg_wunsch
        Open/ClosedOpen Closed
    2014-11-19 joerg_wunsch Priority5 - Normal 7 - High
        StatusNone Confirmed
        Assigned toNone fischl
    2014-11-19 joerg_wunsch Attached File- Added usbasp-trace-64.txt, #32475
        Attached File- Added usbasp-trace-1281.txt, #32476
    2014-11-18 rperkins Attached File- Added 256x2-sequential_test.hex, #32470
        Attached File- Added out.txt, #32471
    2014-11-18 joerg_wunsch Attached File- Added jwunsch.txt.bz2, #32458
    2014-11-16 joerg_wunsch Carbon-Copy- Added -email is unavailable-
    2014-11-16 rperkins Attached File- Added avrdude-version.txt, #32445
        Attached File- Added read.log, #32446
        Attached File- Added bug.sh, #32447
        Attached File- Added read-flash.hex, #32448
    2014-11-16 rperkins Attached File- Added avrdude-version.txt, #32441
        Attached File- Added write.log, #32442
        Attached File- Added bug.sh, #32443
        Attached File- Added written-flash.hex, #32444
    2014-11-16 rperkins Carbon-Copy- Added rperkins
    2014-02-12 joerg_wunsch SummaryLinux version of avrdude doesn\'t write first bytes of flash page, while windows version does AVRDUDE 6.0.1/USBasp doesn't write first bytes of flash page
    2014-02-12 emes Attached File- Added bug.tar.gz, #30523

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code