bugAVR Downloader/UploaDEr - Bugs: bug #28744, Can't load bootloader to xmega128a1

 
 

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

bug #28744: Can't load bootloader to xmega128a1

Submitter:  giuliano carlini <gorillacoder>
Submitted:  Wed 27 Jan 2010 07:43:56 AM UTC
Votes: 6
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  giuliano carlini
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Thu 19 Apr 2012 09:20:56 AM UTC, comment #26: 

Flashing ELF files works now, too.

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 13 Apr 2012 03:28:27 PM UTC, comment #25: 

Now also fixed for firmware >= 7.x, using CMND_SET_XMEGA_PARAMS.

The only things that's not yet working is flashing the ELF
file directly.  I'll look into that soon (and keep the bug
report open as a reminder).

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 30 Mar 2012 04:22:20 PM UTC, comment #24: 

Fixed for firmware versions < 7.x (where it didn't work for
me either), in SVN r1077.

Fixing for firmware >= 7.x will involve some more magic, as
we presumably have to issue the new Xmega device descriptor
there, and have to refrain from applying NVM controller
offsets as part of the memory address.  Sheesh.

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 03 Feb 2012 09:15:03 AM UTC, comment #23: 

For this test I compiled avr-xboot and try to program my target with the commande line :
avrdude -p x128a1 -P usb -c jtag2 -U flash:w:xboot.hex -vvvv

I attached logs with different JTAGICE MKII firmwares.
I also attached the elf file generated by my avr-xboot compilation for your own tests.

(file #24967, file #24968)

Damien Espitallier <espitall>
Thu 02 Feb 2012 05:29:27 PM UTC, comment #22: 

I'm interested in seeing the differences between different
firmware versions.  Can you attach the -vvvv logs to the
bug report, please?  (The main focus will be firmware version
7.x in future, as this one allows Xmega debugging with
AVaRICE.)

Are the hex files below still valid?

As we now support loading directly from ELF files, I'd also
be interested in getting an ELF file with a valid bootloader
for the ATxmega128A1.

Joerg Wunsch <joerg_wunsch>
Group administrator
Fri 27 Jan 2012 02:23:01 PM UTC, comment #21: 

I compiled avrdude with modified sources inspired by these patches (and another little modification for xmega auto reset after programmation), and it worked well until i got a new JTAGICE.

I have now two JTAGICE MKII and only one can program the bootloader section. The main difference is firmware (6.06 for the good one, and 7.13 (7.d) for the other).

Damien Espitallier <espitall>
Tue 13 Dec 2011 10:18:37 AM UTC, comment #20: 

But don't you have to be able to upload a program to the xmega before you can debug it?

;->

Sorry, couldn't resist. Not a serious comment at all. This is just a "which came first, the chicken or the egg" sort of thing...

giuliano carlini <gorillacoder>
Mon 12 Dec 2011 04:15:52 PM UTC, comment #19: 

The primary reason is: lack of time, vs. different dynamic priorities.
I've been very busy with working on AVaRICE lately, something that has
not been receiving a larger slice of my time-sharing schedule for many
years now.  Naturally, other projects had to be left idle for this.

The second reason is: usually, I walk over the list of bugs and
patches right before a release, rather than anywhere between.  When
doing this, patches that are accompanied by documentation always stand
a much better chance of being integrated.  Btw., when submitting
patches, please stick with the formatting style of the file you are
patching.  This particular patch fails my loose style check for a
number of reasons:

. extra whitspaces around parentheses
. commented-out code (should be dropped)
. adds extra newlines outside of its scope

Finally (and this gets back to the AVaRICE stuff mentioned above):
there are a number of things going wrong with Xmega devices, so a
general overhaul appears to be needed.  It is not yet clear whether a
local solution like the one in the patch is really the way to go
(btw., does it also handle the STK600?)  A good number of Xmega
devices which can be found in the wild now are still missing on the
config file, too.  All this is loosely related to the first paragraph
above: until recently, Xmega devices could not be debugged using a
non-Windows system, which naturally didn't boost my motivation to do
much work for these devices, and resolve all the issues around them.
This has finally changed now.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 12 Dec 2011 02:27:58 PM UTC, comment #18: 

Is there a reason a fix for this hasn't been integrated into trunk? Is the solution incomplete? I'd be willing to put some time into getting an acceptable patch put together if the maintainers could let us know what they'd like to see.

I'm working on OSX on an embedded xmega project and just got to working on a bootloader only to find (after a couple hours of "why the hell won't this program?" and subsequent google searches) that avrdude can't program the bootloader section of flash on the xmega.

I integrated the rev3 jtagmkII.c and jtagmkII_private.h changes into a couple patches in my local macports file for avrdude and it successfully built 5.11.1 and programmed the bootloader on my x64a3 (using both ihex and binary sources, and both the 'flash' and 'boot' memory targets).

I've attached these files for other OSX users, it makes using the newest AVRDUDE with these fixes extremely simple, just copy the Portfile to "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/cross/avrdude" and the patch files to the "files" subdirectory.

(file #24576, file #24577, file #24578)

Josh Perry <joshperry>
Sat 21 May 2011 09:17:06 PM UTC, comment #17: 

I am the lucky owner of a Rev A jtagicemkII. I was unable to program the boot section of a xmega256a3b with the listed patches (rev3 + ..private.h mods), using the JTAG protocol. Main flash section and fuses would program OK. With AvrStudio5 my mkII would program the boot section of the chip, so I could not leave it to that!

After experimentation I found that setting the offset to zero vs 0x84000 did the trick. (only for boot section programming)

I have made a quick fix and included rev3 patch modifications plus missing jtagmkII_private.h defs.

xmega_boot_jtag.patch to be used against avrdude-5.10

(file #23435)

Joseph Lacerte <jlacerte>
Fri 07 May 2010 01:10:26 AM UTC, comment #16: 

It might not be a bad idea to support that so people can upload a hex file to the application table section.  However, it doesn't seem to be differentiated hardware-wise, at least from a standpoint of writing data to it with avrdude.  The page write instruction is the same for application and application table.  The point is that it's different for the bootloader section and avrdude has to send the proper instruction, otherwise the data doesn't get written.

Alex Forencich <aforencich>
Thu 06 May 2010 07:49:56 PM UTC, comment #15: 

In fact, I believe the xmegs have three flash sections. At least according to the xmega A1 datasheet section 7.3 In-System Programmable Flash Program Memory, which lists the sections "Application", "Application Table", and "Boot". As the Application Table section could be considered to be just the end of the Application section, perhaps there is no reason to distinguish.

giuliano carlini <gorillacoder>
Mon 03 May 2010 06:56:19 PM UTC, comment #14: 

Actually, I just came up with an elegant solution for this.  I won't submit a patch for this, since it involves modifying serveral files including avrdude.conf, but here it is:  since the 'flash' memory is really a 'meta-memory' that's a concatenation of 'application' and 'boot', all you need to do is change avrdude.conf to show this and then add support in do_op to break the source file into two parts and write each one individually to 'application' and 'boot'.  Say, for the 128A1, you could have an avrdude.conf entry that looks like this:


    memory "flash"
        meta       = 1;
        0x00000000 = application;
        0x00020000 = boot;
    ;


Then all do_op needs to do is separate out the segments for application and flash based on the start addresses and sizes and then write them separately.  The only patch you would need to implement is the rev2 patch by kmahan.

Unfortunately, a change like this to avrdude.conf would require several disparate changes to implement, but I think it is worth the extra effort for generalized support for this particular memory configuration. 

Also, you should double-check the page sizes listed in avrdude.conf, as I understand it the 128A and higher should have 512 byte pages instead of 256 byte.

Alex Forencich <aforencich>
Mon 03 May 2010 04:26:33 AM UTC, comment #13: 

Thanks, that sounds like an idea then.  Yes, maybe it should
be selected in the avrdude.conf file, I'll look into it.

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 03 May 2010 02:15:20 AM UTC, comment #12: 

OK, here is one more fix for this bug that's been driving me up the wall:  there are two separate flash write commands for the main flash and for the boot section.  This latest patch adds support for automatic switching while writing to the 'flash' memory.  Slightly hackish, might want to adjust how the config file is structured to make it not-so-hackish.  However, now the xmega boot block can be reliably programmed!

(file #20392)

Alex Forencich <aforencich>
Mon 22 Mar 2010 12:21:34 AM UTC, comment #11: 

Generating and uploading raw binary works fine.

giuliano carlini <gorillacoder>
Thu 18 Mar 2010 06:23:10 PM UTC, comment #10: 

No worries! Thanks for all the help.

I'm porting the arduino bootloader and core to the xmega chips. Shouldn't be too hard for me to change from hex to binary format until this is fixed.

Your guess about offsets seems to match the differences in the two input files I attached.

I wouldn't worry about figuring out if a "flash" area address is in the boot area. I'm using "-U boot:w:FILE.hex:i" so checking against "boot" should be fine. There's something to be said about having to specify "boot" in order to write to the boot area.

Thanks again!

giuliano carlini <gorillacoder>
Thu 18 Mar 2010 05:28:53 PM UTC, comment #9: 

Sorry for the delay -- my mail filters got ahold of these notifications.  Hopefully fixed.

I use a BIN file for programming.  I initially tried using HEX files but ran into problems with offsets.  I put it on my todo list to track down those problems but haven't had any time.  My makefile kicks out BINs for everything too, so that made life easy.

The BOOT section is offset, and the hex files also have offsets.  I'm guessing that the offsets aren't being taken into account.  A problem I have with the programming algorithm is that there isn't a simple way to discern memory areas when programming as "flash".  So if you do a "flash" program on a hex file that offsets into the boot section there isn't an easy way to say "if memaddr is in boot area use the boot write cmd".  The quick hack I did just checks the section against "boot" and uses that.  I guess I could write up some code that tries to find the "common" names of sections and builds up address ranges for those.

Kurt Mahan <kmahan>
Mon 15 Mar 2010 07:03:52 AM UTC, comment #8: 

Hi, further experimentation shows that this problem seems related to the input file syntax.

I attached two files, ATmegaBOOT_xplain.hex.BAD fails to load. ATmegaBOOT_xplain.hex.GOOD loads. The first was generated by avr-gcc and avr-objcopy. The second was generated by avr-studio using gcc, uploaded to the xplain using avr-studio, and then downloaded to the file.

kerouac:xplain giuliano$ avrdude -p x128a1 -c dragon_jtag -P usb -U boot:w:ATmegaBOOT_xplain.hex.BAD:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e974c
avrdude: reading input file "ATmegaBOOT_xplain.hex.BAD"
avrdude: ERROR: address 0x20010 out of range at line 2 of ATmegaBOOT_xplain.hex.BAD
avrdude: write to file 'ATmegaBOOT_xplain.hex.BAD' failed

avrdude done.  Thank you.

kerouac:xplain giuliano$ avrdude -p x128a1 -c dragon_jtag -P usb -U boot:w:ATmegaBOOT_xplain.hex.GOOD:i

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e974c
avrdude: reading input file "ATmegaBOOT_xplain.hex.GOOD"
avrdude: writing boot (8192 bytes):

Writing | ################################################## | 100% 2.11s

avrdude: 8192 bytes of boot written
avrdude: verifying boot memory against ATmegaBOOT_xplain.hex.GOOD:
avrdude: load data boot data from input file ATmegaBOOT_xplain.hex.GOOD:
avrdude: input file ATmegaBOOT_xplain.hex.GOOD contains 8192 bytes
avrdude: reading on-chip boot data:

Reading | ################################################## | 100% 1.66s

avrdude: verifying ...
avrdude: 8192 bytes of boot verified

avrdude done.  Thank you.


giuliano carlini <gorillacoder>
Sun 28 Feb 2010 09:58:11 PM UTC, comment #7: 

You say you could burn a bootloader, so clearly we're doing something different. Can you post your bootloader and the command you use to upload it? Perhaps strip the bootloader to something trivial, like "blink" ...

Thanks!

giuliano carlini <gorillacoder>
Sun 28 Feb 2010 09:56:33 PM UTC, comment #6: 

Still doesn't seem to be working. Perhaps I'm doing soemthing wrong? The below has been while trying to burn using the arduino IDE. Later this week I'll try it directly using avrdude from the command line, and I'll be trying various compiler/linker options to see if that helps, though the current ones ought to be fine.

I execute the following commands:
/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -q -q -patxmega128a1 -cdragon_jtag -Pusb -e -Ulock:w:0x3F:m -Ufuse0:w:0xFF:m -Ufuse1:w:0xFF:m -Ufuse2:w:0xBF:m -Ufuse4:w:0xFE:m -Ufuse5:w:0xFD:m

/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patxmega128a1 -cdragon_jtag -Pusb -Uboot:w:/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/arduino/bootloaders/xplain/ATmegaBOOT_xplain.hex:i -Ulock:w:0x3F:m

The verbose output shows that the second runs a bit with avrdude and the dragon whispering sweet nothings to each other, but when asked to actually do something:

avrdude: reading input file "/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/arduino/bootloaders/xplain/ATmegaBOOT_xplain.hex"
avrdude: ERROR: address 0x20010 out of range at line 2 of /Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/arduino/bootloaders/xplain/ATmegaBOOT_xplain.hex
avrdude: write to file '/Users/giuliano/Desktop/Arduino-r881/build/macosx/work/Arduino.app/Contents/Resources/Java/hardware/arduino/bootloaders/xplain/ATmegaBOOT_xplain.hex' failed
avrdude: jtagmkII_program_disable(): Sending leave progmode command:
avrdude: jtagmkII_send(): sending 1 bytes
avrdude: Sent: . [1b] . [16] . [00] . [01] . [00] . [00] . [00] . [0e] . [15] . [9f] . [87]
avrdude: jtagmkII_recv():



giuliano carlini <gorillacoder>
Fri 26 Feb 2010 01:11:53 AM UTC, comment #5: 

New patch with a couple more lines of code to make writing the usersig work.  This allows us to do a full program on our 128a1 board (fuses/lock/boot/app/usersig).

Kurt Mahan <kmahan>
Thu 25 Feb 2010 01:15:11 AM UTC, comment #4: 

I've attached xmega_boot.patch which addresses the issue of not being able to program the boot flash.

AVR067 seems to have been updated to contain some of the xmega pdi bits.

Kurt Mahan <kmahan>
Wed 24 Feb 2010 10:04:36 PM UTC, comment #3: 

I'm experiencing the same problem.  I'm unable to write a binary to boot: or a hex (with boot addressing) to flash: .  Writing to the application space (0) works just fine.  This is on an xmega128a1 using jtag2pdi using avrdude 5.10.

Kurt Mahan <kmahan>
Tue 16 Feb 2010 06:09:14 PM UTC, comment #2: 

Hi, just wondering whether there is any interest in fixing this bug? Or if it's been noticed at all ;-> Thanks!

giuliano carlini <gorillacoder>
Sun 31 Jan 2010 06:09:30 AM UTC, comment #1: 

Uploads fine using avrstudio. Would hate to have to use avrstudio/windows rather than the avr tool chain on osx/linux just because of this bug.

giuliano carlini <gorillacoder>
Wed 27 Jan 2010 07:43:56 AM UTC, original submission:  

I'm using the lates AVR CrossPack as the basis of my toolchain. I've replaced avrdude 5.8 with avrdude 5.10 that I built myself. I had to patch avrdude to correctly use libusb.

I'm using avr-gcc 4.3.3 to compile test.c to test.o

avr-gcc -g -Wall -O2 -mmcu=atxmega128a1 -DF_CPU=32000000L -c -o test.o test.c

I'm using avr-ld 2.19 to link test.o into test.elf placing the text section at 0x20000, or 128K, the start of the xmega128a1's bootstrap section.

avr-gcc -g -Wall -O2 -mmcu=atxmega128a1
-DF_CPU=32000000L  -Wl,--section-start=.text=0x20000 -o test.elf test.o

I'm using avr-objcopy 2.19 to convert test.elf into
test.hex (Intel format) and test.srec (Motorola format).

avr-objcopy -j .text -j .data -O ihex test.elf test.hex
avr-objcopy -j .text -j .data -O srec test.elf test.srec

So, I then try to use avrdude 5.10 to burn my bootloader, but get a verification error. Doubt it matters, but I'm using an avr dragon as my programmer.

avrdude  -c dragon_jtag -e -P usb -p atxmega128a1 -U boot:w:test.hex

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e974c
avrdude: erasing chip
avrdude: reading input file "test.hex"
avrdude: input file test2.hex auto detected as Intel Hex
avrdude: ERROR: address 0x20010 out of range at line 2 of test.hex
avrdude: write to file 'test.hex' failed

avrdude done.  Thank you.

So I tried to link at address 0.

avrdude  -c dragon_jtag -e -P usb -p atxmega128a1 -U boot:w:test.hex

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e974c
avrdude: erasing chip
avrdude: reading input file "test.hex"
avrdude: input file test.hex auto detected as Intel Hex
avrdude: writing boot (636 bytes):

Writing | ################################################## | 100% 0.18s

avrdude: 636 bytes of boot written
avrdude: verifying boot memory against test.hex:
avrdude: load data boot data from input file test.hex:
avrdude: input file test.hex auto detected as Intel Hex
avrdude: input file test.hex contains 636 bytes
avrdude: reading on-chip boot data:

Reading | ################################################## | 100% 0.13s

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

avrdude done.  Thank you.

Then I tried the same use "flash" rather than "boot" at both address 0 and 2000. At address 2000:

avrdude  -c dragon_jtag -e -P usb -p atxmega128a1 -U flash:w:test.hex

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e974c
avrdude: erasing chip
avrdude: reading input file "test.hex"
avrdude: input file test.hex auto detected as Intel Hex
avrdude: writing flash (131708 bytes):

Writing | ################################################## | 100% 33.72s

avrdude: 131708 bytes of flash written
avrdude: verifying flash memory against test.hex:
avrdude: load data flash data from input file test.hex:
avrdude: input file test.hex auto detected as Intel Hex
avrdude: input file test.hex contains 131708 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 26.68s

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

avrdude done.  Thank you.

At address 0 and application section it burns fine, but at address 0 in the application section, and I need it at 0x2000 in the bootloader section.

I retried all of the above using srecs with the same results.

I've attached test.c; test0.hex, loaded at address 0; and test2.hex, loaded at address 0x20000.

giuliano carlini <gorillacoder>

 

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

Attached Files
file #24969:  logs.zip added by espitall (144KiB - application/x-zip-compressed - Logs files for the test with different JTAGICE MKII firwmwares)
file #24967:  xboot.hex added by espitall (12KiB - application/octet-stream - Logs and binary files for the test with different JTAGICE MKII firwmwares)
file #24968:  xboot.elf added by espitall (73KiB - application/octet-stream - Logs and binary files for the test with different JTAGICE MKII firwmwares)
file #24576:  Portfile added by joshperry (2KiB - application/octet-stream - MacPorts changes to build AVRDUDE on OSX with these patches)
file #24577:  patch-jtagmkII_private.h.diff added by joshperry (862B - application/octet-stream - MacPorts changes to build AVRDUDE on OSX with these patches)
file #24578:  patch-jtagmkII.c.diff added by joshperry (2KiB - application/octet-stream - MacPorts changes to build AVRDUDE on OSX with these patches)
file #23435:  xmega_boot_jtag.patch added by jlacerte (5KiB - application/octet-stream - Patch directly against avrdude-5.10)
file #20392:  xmega_boot_rev3.patch added by aforencich (2KiB - text/x-diff - Updated patch file)
file #19948:  ATmegaBOOT_xplain.hex.GOOD added by gorillacoder (19KiB - application/octet-stream)
file #19949:  ATmegaBOOT_xplain.hex.BAD added by gorillacoder (7KiB - application/octet-stream)
file #19796:  xmega_boot_rev2.patch added by kmahan (2KiB - text/x-diff)
file #19790:  xmega_boot.patch added by kmahan (2KiB - text/x-diff - patch for programming xmega boot)
file #19553:  test.c added by gorillacoder (318B - text/plain)
file #19554:  test0.hex added by gorillacoder (2KiB - application/octet-stream)
file #19555:  test2.hex added by gorillacoder (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by espitall (Posted a comment)
  • -email is unavailable- added by joshperry (Updated the item)
  • -email is unavailable- added by joshperry
  • -email is unavailable- added by jlacerte (Updated the item)
  • -email is unavailable- added by jlacerte
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by aforencich (Updated the item)
  • -email is unavailable- added by aforencich (Voted in favor of this item)
  • -email is unavailable- added by tz1 (Voted in favor of this item)
  • -email is unavailable- added by kmahan (Voted in favor of this item)
  • -email is unavailable- added by kmahan (Posted a comment)
  • -email is unavailable- added by gorillacoder (Submitted the item)
  •  

    There are 6 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 24 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-04-19 joerg_wunsch Open/ClosedOpen Closed
    2012-04-13 joerg_wunsch StatusIn Progress Fixed
    2012-03-30 joerg_wunsch StatusNone In Progress
        Assigned toNone joerg_wunsch
    2012-02-03 espitall Attached File- Added logs.zip, #24969
    2012-02-03 espitall Attached File- Added xboot.hex, #24967
        Attached File- Added xboot.elf, #24968
    2011-12-12 joshperry Attached File- Added Portfile, #24576
        Attached File- Added patch-jtagmkII_private.h.diff, #24577
        Attached File- Added patch-jtagmkII.c.diff, #24578
        Carbon-Copy- Added joshperry
    2011-05-21 jlacerte Attached File- Added xmega_boot_jtag.patch, #23435
        Carbon-Copy- Added jlacerte
    2010-05-03 aforencich Attached File- Added xmega_boot_rev3.patch, #20392
        Carbon-Copy- Added aforencich
    2010-03-16 tz1 Carbon-Copy- Added tz1
    2010-03-15 gorillacoder Attached File- Added ATmegaBOOT_xplain.hex.GOOD, #19948
        Attached File- Added ATmegaBOOT_xplain.hex.BAD, #19949
    2010-02-26 kmahan Attached File- Added xmega_boot_rev2.patch, #19796
    2010-02-25 kmahan Attached File- Added xmega_boot.patch, #19790
    2010-02-24 kmahan Carbon-Copy- Added kmahan
    2010-01-27 gorillacoder Attached File- Added test.c, #19553
        Attached File- Added test0.hex, #19554
        Attached File- Added test2.hex, #19555

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code