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 authentification level.

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

Submitted by:  Michal Salaban <emes>
Submitted on:  Wed 12 Feb 2014 02:29:09 AM UTC  
Votes:  10  
 
Category: NoneSeverity: 3 - Normal
Priority: 7 - HighItem Group: None
Status: FixedPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: Michal Salaban
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

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

Randy 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>
Project AdministratorIn charge of this item.
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

Randy 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) {

Randy 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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:

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:

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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

Randy 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.

Randy 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)

Randy 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

Randy 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:

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>
Project AdministratorIn charge of this item.
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

Randy 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>
Project AdministratorIn charge of this item.
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

Randy 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)

Randy 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)

Randy 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>
Project AdministratorIn charge of this item.
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

Randy 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>
Project AdministratorIn charge of this item.
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

Randy 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>

 

Attached Files
file #32475:  usbasp-trace-64.txt added by joerg_wunsch (389kB - text/plain - Logic analyzer traces for ATmega64 and ATmega1281, respectively.)
file #32476:  usbasp-trace-1281.txt added by joerg_wunsch (395kB - text/plain - Logic analyzer traces for ATmega64 and ATmega1281, respectively.)
file #32470:  256x2-sequential_test.hex added by rperkins (1kB - text/x-hex - out.txt is the -vvvv log . the hex file was created for debugging)
file #32471:  out.txt added by rperkins (33kB - text/plain - out.txt is the -vvvv log . the hex file was created for debugging)
file #32458:  jwunsch.txt.bz2 added by joerg_wunsch (34kB - application/x-bzip2 - Logfile from Joerg where all is going well)
file #32445:  avrdude-version.txt added by rperkins (2kB - text/plain - read.log is the -vvv output of avrdude)
file #32446:  read.log added by rperkins (428kB - 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 (126kB - text/x-hex - read.log is the -vvv output of avrdude)
file #32441:  avrdude-version.txt added by rperkins (2kB - text/plain - write.log is the -vvv output of avrdude)
file #32442:  write.log added by rperkins (710kB - 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 (149kB - text/x-hex - write.log is the -vvv output of avrdude)
file #30523:  bug.tar.gz added by emes (284kB - 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
  • -unavailable- added by joerg_wunsch (Thomas Fischl)
  • -unavailable- added by rperkins (Voted in favor of this item)
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by rperkins (Posted a comment)
  • -unavailable- added by emes (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 10 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 23 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 20 Nov 2014 09:22:09 AM UTCjoerg_wunschStatusConfirmed=>Fixed
      Assigned tofischl=>joerg_wunsch
      Open/ClosedOpen=>Closed
    Wed 19 Nov 2014 04:25:27 PM UTCjoerg_wunschPriority5 - Normal=>7 - High
      StatusNone=>Confirmed
      Assigned toNone=>fischl
    Wed 19 Nov 2014 03:49:22 PM UTCjoerg_wunschAttached File-=>Added usbasp-trace-64.txt, #32475
      Attached File-=>Added usbasp-trace-1281.txt, #32476
    Tue 18 Nov 2014 10:39:32 PM UTCrperkinsAttached File-=>Added 256x2-sequential_test.hex, #32470
      Attached File-=>Added out.txt, #32471
    Tue 18 Nov 2014 11:49:58 AM UTCjoerg_wunschAttached File-=>Added jwunsch.txt.bz2, #32458
    Sun 16 Nov 2014 07:32:51 PM UTCjoerg_wunschCarbon-Copy-=>Added -unavailable-
    Sun 16 Nov 2014 09:59:02 AM UTCrperkinsAttached 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
    Sun 16 Nov 2014 09:53:09 AM UTCrperkinsAttached 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
    Sun 16 Nov 2014 05:44:01 AM UTCrperkinsCarbon-Copy-=>Added rperkins
    Wed 12 Feb 2014 09:27:37 AM UTCjoerg_wunschSummaryLinux 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
    Wed 12 Feb 2014 08:47:52 AM UTCemesAttached File-=>Added bug.tar.gz, #30523

    Back to the top


    Powered by Savane 3.1-cleanup