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

bug #28744: Can't load bootloader to xmega128a1

Submitted by:  giuliano carlini <gorillacoder>
Submitted on:  Wed Jan 27 07:43:56 2010  
Votes:  6  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Name: giuliano carlini
Open/Closed: ClosedRelease: None
Programmer hardware: Device type: 

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

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

Flashing ELF files works now, too.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Fri Apr 13 15:28:27 2012, 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>
Project AdministratorIn charge of this item.
Fri Mar 30 16:22:20 2012, 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>
Project AdministratorIn charge of this item.
Fri Feb 3 09:15:03 2012, 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 Feb 2 17:29:27 2012, 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>
Project AdministratorIn charge of this item.
Fri Jan 27 14:23:01 2012, 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 Dec 13 10:18:37 2011, 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 Dec 12 16:15:52 2011, 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>
Project AdministratorIn charge of this item.
Mon Dec 12 14:27:58 2011, 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 May 21 21:17:06 2011, 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 May 7 01:10:26 2010, 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 May 6 19:49:56 2010, 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 May 3 18:56:19 2010, 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:

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 May 3 04:26:33 2010, 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>
Project AdministratorIn charge of this item.
Mon May 3 02:15:20 2010, 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 Mar 22 00:21:34 2010, comment #11:

Generating and uploading raw binary works fine.

giuliano carlini <gorillacoder>
Thu Mar 18 18:23:10 2010, 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 Mar 18 17:28:53 2010, 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 Mar 15 07:03:52 2010, 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 Feb 28 21:58:11 2010, 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 Feb 28 21:56:33 2010, 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 Feb 26 01:11:53 2010, 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 Feb 25 01:15:11 2010, 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 Feb 24 22:04:36 2010, 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 Feb 16 18:09:14 2010, 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 Jan 31 06:09:30 2010, 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 Jan 27 07:43:56 2010, 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>

 

Attached Files
file #24969:  logs.zip added by espitall (144kB - application/x-zip-compressed - Logs files for the test with different JTAGICE MKII firwmwares)
file #24967:  xboot.hex added by espitall (12kB - application/octet-stream - Logs and binary files for the test with different JTAGICE MKII firwmwares)
file #24968:  xboot.elf added by espitall (73kB - application/octet-stream - Logs and binary files for the test with different JTAGICE MKII firwmwares)
file #24576:  Portfile added by joshperry (2kB - 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 (2kB - application/octet-stream - MacPorts changes to build AVRDUDE on OSX with these patches)
file #23435:  xmega_boot_jtag.patch added by jlacerte (5kB - application/octet-stream - Patch directly against avrdude-5.10)
file #20392:  xmega_boot_rev3.patch added by aforencich (2kB - text/x-diff - Updated patch file)
file #19948:  ATmegaBOOT_xplain.hex.GOOD added by gorillacoder (19kB - application/octet-stream)
file #19949:  ATmegaBOOT_xplain.hex.BAD added by gorillacoder (7kB - application/octet-stream)
file #19796:  xmega_boot_rev2.patch added by kmahan (2kB - text/x-diff)
file #19790:  xmega_boot.patch added by kmahan (2kB - 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 (2kB - application/octet-stream)
file #19555:  test2.hex added by gorillacoder (2kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by espitall (Posted a comment)
  • -unavailable- added by joshperry (Updated the item)
  • -unavailable- added by joshperry
  • -unavailable- added by jlacerte (Updated the item)
  • -unavailable- added by jlacerte
  • -unavailable- added by joerg_wunsch (Posted a comment)
  • -unavailable- added by aforencich (Updated the item)
  • -unavailable- added by aforencich (Voted in favor of this item)
  • -unavailable- added by tz1 (Voted in favor of this item)
  • -unavailable- added by kmahan (Voted in favor of this item)
  • -unavailable- added by kmahan (Posted a comment)
  • -unavailable- added by gorillacoder (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 6 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 24 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Apr 19 09:20:56 2012joerg_wunschOpen/ClosedOpen=>Closed
    Fri Apr 13 15:28:27 2012joerg_wunschStatusIn Progress=>Fixed
    Fri Mar 30 16:22:20 2012joerg_wunschStatusNone=>In Progress
      Assigned toNone=>joerg_wunsch
    Fri Feb 3 09:17:32 2012espitallAttached File-=>Added logs.zip, #24969
    Fri Feb 3 09:15:03 2012espitallAttached File-=>Added xboot.hex, #24967
      Attached File-=>Added xboot.elf, #24968
    Mon Dec 12 14:27:58 2011joshperryAttached 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
    Sat May 21 21:17:06 2011jlacerteAttached File-=>Added xmega_boot_jtag.patch, #23435
      Carbon-Copy-=>Added jlacerte
    Mon May 3 02:15:20 2010aforencichAttached File-=>Added xmega_boot_rev3.patch, #20392
      Carbon-Copy-=>Added aforencich
    Tue Mar 16 16:51:37 2010tz1Carbon-Copy-=>Added tz1
    Mon Mar 15 07:07:26 2010gorillacoderAttached File-=>Added ATmegaBOOT_xplain.hex.GOOD, #19948
      Attached File-=>Added ATmegaBOOT_xplain.hex.BAD, #19949
    Fri Feb 26 01:09:54 2010kmahanAttached File-=>Added xmega_boot_rev2.patch, #19796
    Thu Feb 25 01:13:53 2010kmahanAttached File-=>Added xmega_boot.patch, #19790
    Wed Feb 24 22:05:09 2010kmahanCarbon-Copy-=>Added kmahan
    Wed Jan 27 07:43:56 2010gorillacoderAttached 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.1-cleanup