AVR Downloader/UploaDEr - Bugs: bug #19773, ATmega2561 not correctly flashed
You are not allowed to post comments on this tracker with your current authentication level.
bug #19773: ATmega2561 not correctly flashed
Submitter: | Harald Kipp <haraldkipp> | ||
Submitted: | Wed 02 May 2007 02:47:41 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | None |
Status: | Invalid | Privacy: | Public |
Assigned to: | joerg_wunsch | Originator Name: | Harald Kipp |
Open/Closed: | Closed | Release: | None |
Programmer hardware: | Device type: |
Jump to the original submission
Sun 06 May 2007 03:20:33 PM UTC, comment #6: |
Joerg Wunsch <joerg_wunsch> |
Sat 05 May 2007 09:52:25 PM UTC, comment #5: Thanks for the trace files.
|
Joerg Wunsch <joerg_wunsch> |
Thu 03 May 2007 08:05:31 AM UTC, comment #4: The archive
|
Harald Kipp <haraldkipp> |
Wed 02 May 2007 08:19:55 PM UTC, comment #3: That reminds me: if you could also attach AVR Studio's
|
Joerg Wunsch <joerg_wunsch> |
Wed 02 May 2007 08:15:33 PM UTC, comment #2: I have no troubles programming that hex file into an ATmega2561
|
Joerg Wunsch <joerg_wunsch> |
Wed 02 May 2007 08:01:53 PM UTC, comment #1: I notice the avrduo has different firmware than the STK500, so there is more than one spot for a problem to occur here...
|
Colin O Flynn <c_oflynn> |
Wed 02 May 2007 02:47:41 PM UTC, original submission:
avrdude fails to flash some of our hex files. A sample project (without Nut/OS libs) is available for download:
|
Harald Kipp <haraldkipp> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 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 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-05-15 | joerg_wunsch | Open/Closed | Open | Closed | |
2007-05-06 | joerg_wunsch | Status | In Progress | Invalid | |
Assigned to | None | joerg_wunsch | |||
2007-05-05 | joerg_wunsch | Status | Need Info | In Progress | |
2007-05-02 | joerg_wunsch | Status | None | Need Info |
Powered by Savane 3.13-bb6a.
Corresponding source code
Further investigation shows that spduo simply flashed the
last block transferred into address 0x31900 rather than
0x11900 where it is supposed to be placed at. Two differences
can be noticed here between the way avrdude and AVR Studio
are working: avrdude issues a new LOAD ADDRESS command for
that block (does that confuse SP Duo?), and avrdude writes a
short block, i.e. the block only contains as many bytes as
have been read from the input file for this memory page.
AVR Studio instead writes a page-sized block even for the
last block, where the remaining data up to the page size have
been padded with 0xff.
Does that confuse SP Duo's firmware? After reading AVR068, I
believe avrdude is allowed to write a short block, and the
programmer should simply issue the WRITE PAGE command after
all input data have been processed.
A different issue is that the data read back from the flash
apprently are wrong when hitting the 0x10000 boundary (this
is what causes the verification error shown below). Alas,
the trace does not show any of the data read back by avrdude
(all the "Recv: " lines are empty, for whatever reason).
However, there's again the difference between avrdude and
AVR Studio that avrdude re-issues the LOAD ADDRESS command
right before address 0x10000, while AVR Studio simply proceeds,
and relies on the programmer to correctly wrap the address.
It appears to me that avrdude's operation, while different
than AVR Studio's, is fully in agreement with the protocol
description in AVR067.