avrs-admin
commented
2 years ago giuliano carlini
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.
Closed avrs-admin closed 2 years ago
avrs-admin
commented
2 years ago giuliano carlini
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.
avrs-admin
commented
2 years ago giuliano carlini
Hi, just wondering whether there is any interest in fixing this bug? Or if it's been noticed at all ;-> Thanks!
avrs-admin
commented
2 years ago Kurt Mahan
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.
avrs-admin
commented
2 years ago Kurt Mahan
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.
avrs-admin
commented
2 years ago Kurt Mahan
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).
avrs-admin
commented
2 years ago giuliano carlini
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():
avrs-admin
commented
2 years ago giuliano carlini
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!
avrs-admin
commented
2 years ago giuliano carlini
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.
avrs-admin
commented
2 years ago Kurt Mahan
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.
avrs-admin
commented
2 years ago giuliano carlini
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!
avrs-admin
commented
2 years ago giuliano carlini
Generating and uploading raw binary works fine.
avrs-admin
commented
2 years ago Alex Forencich
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!
avrs-admin
commented
2 years ago Joerg Wunsch
Thanks, that sounds like an idea then. Yes, maybe it should be selected in the avrdude.conf file, I'll look into it.
avrs-admin
commented
2 years ago Alex Forencich
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.
avrs-admin
commented
2 years ago giuliano carlini
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.
avrs-admin
commented
2 years ago Alex Forencich
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.
avrs-admin
commented
2 years ago Joseph Lacerte
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
avrs-admin
commented
2 years ago Josh Perry
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.
avrs-admin
commented
2 years ago Joerg Wunsch
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.
avrs-admin
commented
2 years ago giuliano carlini
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...
avrs-admin
commented
2 years ago Damien Espitallier
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).
avrs-admin
commented
2 years ago Joerg Wunsch
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.
avrs-admin
commented
2 years ago Damien Espitallier
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.
avrs-admin
commented
2 years ago Joerg Wunsch
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.
avrs-admin
commented
2 years ago Joerg Wunsch
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).
avrs-admin
commented
2 years ago Joerg Wunsch
Flashing ELF files works now, too.
giuliano carlini
Wed 27 Jan 2010 07:43:56 AM UTC
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.
file #19555: test2.hex file #19554: test0.hex file #19553: test.c file #19790: xmega_boot.patch file #19796: xmega_boot_rev2.patch file #19949: ATmegaBOOT_xplain.hex.BAD file #19948: ATmegaBOOT_xplain.hex.GOOD file #20392: xmega_boot_rev3.patch file #23435: xmega_boot_jtag.patch file #24578: patch-jtagmkII.c.diff file #24577: patch-jtagmkII_private.h.diff file #24576: Portfile file #24968: xboot.elf file #24967: xboot.hex file #24969: logs.zip
This issue was migrated from https://savannah.nongnu.org/bugs/?28744