I don't see this anywhere in ASF. I'm using Atmel Studio 6 and I've got ASF 2.11.1 thru 3.4.1.
A prebuilt hex file (for the ATxmega64A4U) would be a good start, but ultimately I need the source because I have to change the pin it uses to sense whether to boot the application.
Yeah, I did, and it tells me how to modify the source to change the pin, but not where the source is or how to get it. There's nothing in the ASF list of components that mentions "boot", "dfu" or "flip".
clawson 
Yeah, I did, and it tells me how to modify the source to change the pin, but not where the source is or how to get it.
EDIT: here in fact.. http://www.atmel.com/Images/AVR1...
mspeng I never found the source either. The package you point to has source code for including the bootloader in your project.
I think I also read somewhere that atmel used iar to compile the bootloader. Using other compilers didn't make the bootloader small enough to fit in the bootloader space.
clawson
The package you point to has source code for including the bootloader in your project.
I think I also read somewhere that atmel used iar to compile the bootloader.
jari.koskinen 
I found source code of XMega USB DFU bootloader (XMEGA_bootloaders_v104). Code uses ASF and it is intended to build with Atmel Studio. But there is not any project files or any information how to build it.
Can anyone give a simple example, how to build that code?
JKo
clawson
I found source code of XMega USB DFU bootloader (XMEGA_bootloaders_v104). Code uses ASF and it is intended to build with Atmel Studio. But there is not any project files or any information how to build it.Can anyone give a simple example, how to build that code?
You cannot build the code using Studio.
pixel2001n 
It's true that the bootloader is under 4k for some XMega chips. For others it's only under 8k.
I also seem to recall a limitation on the IAR kickstart version for being used in commercial products. These two combined mean I end up hex editing the output files instead of recompiling them.
clawson Jeff,
I'd have thought that anything that spills into the 4K-8K range is likely not close to the total 8K so it should be possible to take the source and make it build with a different compiler such as avr-gcc (the ASF stuff that the bootloaders seem based on should work for boar IAR and avr-gcc).
Cliff
pixel2001n My recollection is that the 32A4U DFU bootloader took about 5k when I ported it to avrgcc. This was more than a year ago, so I don't recall exactly. Anyway, trimming 20% of the code away didn't appeal to me, especially when Atmel was already doing funky things with manually locating sections in their IAR project (presumably to make it fit).
The 8k parts do take up significantly more room because every address needs to be 24-bit.
Search "1916" on the Atmel site - there's a (huge!) .zip to accompany the 1916 PDF.EDIT: here in fact.. http://www.atmel.com/Images/AVR1...
Thanks for the pointer.
I also seem to recall a limitation on the IAR kickstart version for being used in commercial products. These two combined mean I end up hex editing the output files instead of recompiling them.
What did you change? The only thing I'd need to change is the choice of pin for switching between the boot loader and the application. If that's what you changed, and you remember where it is, that would be a useful piece of information. Even the approximate location, so I don't have to pore through all 4K of a disassembly.
Never mind, I see it right at the very beginning. Looks easy enough to patch for a different port pin.
pixel2001n Yes, it's right near the beginning. I changed the pin, changed the trigger level from low to high, and changed the pull up to a pull down. I've also created versions that always start or never start (which is more useful than it sounds).
jari.koskinen Now I was able to build that boot loader with IAR. It was also quite hard to found project file to IAR, because there was so many directories.
But then I had a lot of difficulty with Flip (old version, path and other). Flip 3.4.7 refused to start because it can't found _AT32UC3A0512.xml file. It took a while before I noticed that there was _ mark in start of device name. Of course there was not that file. I make a copy of AT32UC3A0512 and add _ to start of name. Then Flip agreed to start. Then I change valid device name.
After that everything was OK. I download some programs to my Mini XMega experiment cards (I tested with several boards). But this morning Flip refuses to connect: "Could not open USB device". I also test with several boards.
I also check from Device Manager of Window 7 that I have Atmel USB Device (ATxmega16A4U) and it works OK.
Can anyone find out what went wrong with Flip this time?
JKo
But this morning Flip refuses to connect: "Could not open USB device"
jari.koskinen Now it works. My mistake. I had change device type to ATmega16U4. It had to be ATXMega16AU4. It is sometimes hard to noticed this kind of small differences.
But I have often wondered, why this kind of programs can't give any more information. I would have save many hours if Flip should have agree to start in first time and let me change device type. And this time it should be pointed out that device type is not correct.
Levenkay Flip is misdesigned, IMHO. Its only job should be to exchange a binary image (given as an intel-hex file) with a given DFU client xyz, regardless of which kind of chip is implementing that DFU client. As a nicety, it might query the target DFU client as to what the extent of its nonvolatile space(s)is(are), and issue a warning if the requested image size doesn't match, but this notion of having to tell Flip ahead of time which device it may program, is, well, "non-Scottish".
I use Flip in a class I intermittently present to highschool students, and the venue imposes pretty strict security policies on their computer equipment. It was a major pain to discover that even though we'd installed the Flip program as part of the classroom computers' configurations, the actual communications with the target AVRs require administrator-privilege reconfiguring of the device driver for each and every different AVR chip type.
Could any of you tell me how to change the .hex file to change the pin that makes the chip enter the bootloader? Which line and digits, etc.
I have an 128a4u so now it is the PC3, but I need that pin for other things.
I have been looking through atmel's .zip and the PDF that tells how to change the pin is lacking a lot of information on how to apply the changes as others have said in this post.
Thanks!
clawson
Which line and digits, etc.
// Definition of hardware condition to enter in ISP mode #if XMEGA_A1U # define ISP_PORT_DIR PORTF_DIR # define ISP_PORT_PINCTRL PORTF_PIN5CTRL # define ISP_PORT_IN PORTF_IN # define ISP_PORT_PIN 0 #elif (XMEGA_A3U || XMEGA_A3BU || XMEGA_C3) # define ISP_PORT_DIR PORTE_DIR # define ISP_PORT_PINCTRL PORTE_PIN5CTRL # define ISP_PORT_IN PORTE_IN # define ISP_PORT_PIN 5 #elif (XMEGA_A4U || XMEGA_C4) # define ISP_PORT_DIR PORTC_DIR # define ISP_PORT_PINCTRL PORTC_PIN3CTRL # define ISP_PORT_IN PORTC_IN # define ISP_PORT_PIN 3 #elif XMEGA_B # define ISP_PORT_DIR PORTC_DIR # define ISP_PORT_PINCTRL PORTC_PIN6CTRL # define ISP_PORT_IN PORTC_IN # define ISP_PORT_PIN 6 #else # error Unknow AVR Xmega part #endif
I'm just guessing but that looks a LOT like the place you need to edit the source to change the entry condition.
(*) Am I the only person on earth who thinks this file and path naming is just about the stupidest thing I've ever seen?!?
(*) Am I the only person on earth who thinks this file and path naming is just about the stupidest thing I've ever seen?!?
Thanks clawson,
I was already aware of the existence of that conf. file but the problem is I don't know how to implement that modification into the bootloader. How can I burn that with AS6? I have been trying it but in vain.. the bootloader could be one file but no.. That is why I asked about modifying the .hex. Seems easier but I have no idea what I have to modify.
Any of these two solution is fine of course! I will try whichever you can explain.
Thanks!
clawson
I was already aware of the existence of that conf. file but the problem is I don't know how to implement that modification into the bootloader. How can I burn that with AS6?
All is not lost. Although IAR costs $3,000 you can get a "KickStart" trial version and because its limit is simply that it cannot generate more than 4K of code this does not matter as the booloaders build to be under 4K anyway.
So visit:
http://supp.iar.com/Download/SW/...
and get that 312MB download and use that to edit and build your modified copy of the source that is in the AV1916 .zip file.
I guess you could achieve this by editing the Hex file (especially if just moving to another pin in PORTC) but it's not a very maintainable solution and disassembling the hex to find whih byte(s) to be changed would be a right old game!
After spending some time on this I finally obtained something but I am not convinced. I have tried to recompile the original bootloader in IAR to make sure that things went as expected (I haven't modified it). I had to use the 30 days trial version since it takes 16k and gave me an error with the 4K version. The original .hex is also 16k.
The .hex file is not the same. There are many lines that are the same and others that are different (see the first few lines):
The original .hex
:020000022000DC :1000000000C00091780005FD42C0F092400608E172 :10001000009353060FEF0A950023E9F70091480675 :1000200003FFECC0E0E0F0E0079116910F3F19F4F8 :100030001F3F09F4E3C02BC03091CF0137FDFCCF47 :100040003BB72BBFF8012091CA0113E21093CA01FC :100050000A01E8952093CA013BBF08953BB72BBF27 :10006000F8012091CA014093CA013DE93093340060 :10007000E8952093CA013BBF089501E70DBF00E258 :100080000EBFC2E9DAE20F94B6000F94720AF09242 :10009000530600910020109101200A3A154511F0F5 :1000A0000C940000F0920020F092012000E20093F6 :1000B0007800F6CFEE84DD84CC84BB84AA84998456 :1000C00088847F806E805D804C80BB81AA8199810D
The IAR recompiled .hex
:020000022000DC :1000000000C00091780005FD42C0F092400608E172 :10001000009353060FEF0A950023E9F70091480675 :1000200003FFECC0E0E0F0E0079116910F3F19F4F8 :100030001F3F09F4E3C02BC03091CF0137FDFCCF47 :100040003BB72BBFF8012091CA0113E21093CA01FC :100050000A01E8952093CA013BBF08953BB72BBF27 :10006000F8012091CA014093CA013DE93093340060 :10007000E8952093CA013BBF089501E70DBF00E258 :100080000EBFC2E9DAE20F94B6000F947A0AF0923A :10009000530600910020109101200A3A154511F0F5 :1000A0000C940000F0920020F092012000E20093F6 :1000B0007800F6CFFF84EE84DD84CC84BB84AA84F0 :1000C000998488847F806E805D804C80BB81AA810A
I wanted to ask you why is this before programming the chip. I don´t want to mess with the fuses...
Thanks again.
clawson
I had to use the 30 days trial version since it takes 16k and gave me an error with the 4K version. The original .hex is also 16k.
If you really are building these bootloaders to be >4K then something is wrong somewhere.
Anyway the first parts of the two .hex you show are as follows:
E:\>avr-objcopy -I ihex -O binary dfu.hex dfu.bin E:\>avr-objdump -b binary -D -m avr dfu.bin dfu.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: 00 c0 rjmp .+0 ; 0x2 2: 00 91 78 00 lds r16, 0x0078 6: 05 fd sbrc r16, 5 8: 42 c0 rjmp .+132 ; 0x8e a: f0 92 40 06 sts 0x0640, r15 e: 08 e1 ldi r16, 0x18 ; 24 10: 00 93 53 06 sts 0x0653, r16 14: 0f ef ldi r16, 0xFF ; 255 16: 0a 95 dec r16 18: 00 23 and r16, r16 1a: e9 f7 brne .-6 ; 0x16 1c: 00 91 48 06 lds r16, 0x0648 20: 03 ff sbrs r16, 3 22: ec c0 rjmp .+472 ; 0x1fc 24: e0 e0 ldi r30, 0x00 ; 0 26: f0 e0 ldi r31, 0x00 ; 0 28: 07 91 elpm r16, Z+ 2a: 16 91 elpm r17, Z+ 2c: 0f 3f cpi r16, 0xFF ; 255 2e: 19 f4 brne .+6 ; 0x36 30: 1f 3f cpi r17, 0xFF ; 255 32: 09 f4 brne .+2 ; 0x36 34: e3 c0 rjmp .+454 ; 0x1fc 36: 2b c0 rjmp .+86 ; 0x8e 38: 30 91 cf 01 lds r19, 0x01CF 3c: 37 fd sbrc r19, 7 3e: fc cf rjmp .-8 ; 0x38 40: 3b b7 in r19, 0x3b ; 59 42: 2b bf out 0x3b, r18 ; 59 44: f8 01 movw r30, r16 46: 20 91 ca 01 lds r18, 0x01CA 4a: 13 e2 ldi r17, 0x23 ; 35 4c: 10 93 ca 01 sts 0x01CA, r17 50: 0a 01 movw r0, r20 52: e8 95 spm 54: 20 93 ca 01 sts 0x01CA, r18 58: 3b bf out 0x3b, r19 ; 59 5a: 08 95 ret 5c: 3b b7 in r19, 0x3b ; 59 5e: 2b bf out 0x3b, r18 ; 59 60: f8 01 movw r30, r16 62: 20 91 ca 01 lds r18, 0x01CA 66: 40 93 ca 01 sts 0x01CA, r20 6a: 3d e9 ldi r19, 0x9D ; 157 6c: 30 93 34 00 sts 0x0034, r19 70: e8 95 spm 72: 20 93 ca 01 sts 0x01CA, r18 76: 3b bf out 0x3b, r19 ; 59 78: 08 95 ret
E:\>avr-objdump -b binary -D -m avr new.bin new.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: 00 c0 rjmp .+0 ; 0x2 2: 00 91 78 00 lds r16, 0x0078 6: 05 fd sbrc r16, 5 8: 42 c0 rjmp .+132 ; 0x8e a: f0 92 40 06 sts 0x0640, r15 e: 08 e1 ldi r16, 0x18 ; 24 10: 00 93 53 06 sts 0x0653, r16 14: 0f ef ldi r16, 0xFF ; 255 16: 0a 95 dec r16 18: 00 23 and r16, r16 1a: e9 f7 brne .-6 ; 0x16 1c: 00 91 48 06 lds r16, 0x0648 20: 03 ff sbrs r16, 3 22: ec c0 rjmp .+472 ; 0x1fc 24: e0 e0 ldi r30, 0x00 ; 0 26: f0 e0 ldi r31, 0x00 ; 0 28: 07 91 elpm r16, Z+ 2a: 16 91 elpm r17, Z+ 2c: 0f 3f cpi r16, 0xFF ; 255 2e: 19 f4 brne .+6 ; 0x36 30: 1f 3f cpi r17, 0xFF ; 255 32: 09 f4 brne .+2 ; 0x36 34: e3 c0 rjmp .+454 ; 0x1fc 36: 2b c0 rjmp .+86 ; 0x8e 38: 30 91 cf 01 lds r19, 0x01CF 3c: 37 fd sbrc r19, 7 3e: fc cf rjmp .-8 ; 0x38 40: 3b b7 in r19, 0x3b ; 59 42: 2b bf out 0x3b, r18 ; 59 44: f8 01 movw r30, r16 46: 20 91 ca 01 lds r18, 0x01CA 4a: 13 e2 ldi r17, 0x23 ; 35 4c: 10 93 ca 01 sts 0x01CA, r17 50: 0a 01 movw r0, r20 52: e8 95 spm 54: 20 93 ca 01 sts 0x01CA, r18 58: 3b bf out 0x3b, r19 ; 59 5a: 08 95 ret 5c: 3b b7 in r19, 0x3b ; 59 5e: 2b bf out 0x3b, r18 ; 59 60: f8 01 movw r30, r16 62: 20 91 ca 01 lds r18, 0x01CA 66: 40 93 ca 01 sts 0x01CA, r20 6a: 3d e9 ldi r19, 0x9D ; 157 6c: 30 93 34 00 sts 0x0034, r19 70: e8 95 spm 72: 20 93 ca 01 sts 0x01CA, r18 76: 3b bf out 0x3b, r19 ; 59 78: 08 95 ret
if you want to see more repeat my commands locally.
Ok, I did what you said. I used the command avr-size on the original .hex dfu bootloader -> 5588. That is still over 4k...
I also disassembled the binary files but I cannot interpret them so I'll just burn the new bootloader and cross my fingers.
BINGO!
It works. I reprogrammed the modified bootloader that has the trigger pin changed and it works. I hope no surprises will show up.
Thanks!
Auzman Hi everyone!
I'm trying to modify the IAR project to change pin and mode.
I installed the IAR 4k limited version and loaded the .eww file.
It asks me to update to the latest project type and I say yes.
When I try to compile (without modifying anything) I stop on the linker. The error code is:
Fatal Error[e72]: Segment HUGE_ID must be defined in a segment definition option (-Z, -b or -P)
I tried to modify the "Project->Options->Target->Memory model" but I always continue to get errors.
How can I manage it?
Thank you!
I didn't do anything special. I just opened the IAR file (in the IAR workbench) that came in the zip file that Atmel provides and it loaded everything (you should see all the folders on the left side (explorer of IAR)). I changed the pin in the corresponding part and then put the Atxmega128a4u as target.
I used the 30 days trial because the 4k version wasn't enough. No errors.
Auzman I think I found the problem, but not the solution. I was using the 64a1u bootloader and I found no way to compile it. Then I tried the 128a1u (I have both) and it compiled. It seems to be a problem in the project or something similar, but since I never used IAR I suppose that I will go on with the 128a1u...
Thank you for the support!
Mostacha Hi everyone,
i would like to use 4 pins to activate the bootloader mode, i guess i understand this code, but i dont know how to add 3 more ISP_PORT_PINCTRL, ISP_PORT_IN and ISP_PORT_PIN.
[code]boot_process:
// Test Software reset
LDS R16,RST_STATUS
SBRC R16,RST_SRF_bp // Test Software Reset Flag
RJMP start_app
// Test ISP pin
STS ISP_PORT_DIR, R15
LDI R16,0x18
STS ISP_PORT_PINCTRL, R16
LDI R16,0xFF
tempo:
DEC R16
TST R16
BRNE tempo
LDS R16,ISP_PORT_IN
SBRS R16,ISP_PORT_PIN // test ISP pin active
RJMP start_boot // pin activated
Mostacha Solved, i will write the code maybe someone needs it:
boot_process:
// Test Software reset
LDS R16,RST_STATUS
SBRC R16,RST_SRF_bp // Test Software Reset Flag
RJMP start_app
// Test ISP pins PortA, Pins:4, 6 & 7
STS ISP_PORT_DIR, R15
LDI R16,0x18
STS PORTA_PIN4CTRL,R16
//STS ISP_PORT_PINCTRL, R16
LDI R16,0xFF
tempo:
DEC R16
TST R16
BRNE tempo
LDS R16,ISP_PORT_IN
SBRS R16,4 // test ISP pin 4 active
RJMP continue
RJMP endpro
continue: // Test ISP pin
STS ISP_PORT_DIR, R15
LDI R16,0x18
STS PORTA_PIN6CTRL,R16
//STS ISP_PORT_PINCTRL, R16
LDI R16,0xFF
tempo1:
DEC R16
TST R16
BRNE tempo1
LDS R16,ISP_PORT_IN
SBRS R16,6 // test ISP pin 6 active
RJMP continue1
RJMP endpro
continue1:
// Test ISP pin
STS ISP_PORT_DIR, R15
LDI R16,0x18
STS PORTA_PIN7CTRL,R16
//STS ISP_PORT_PINCTRL, R16
LDI R16,0xFF
tempo2:
DEC R16
TST R16
BRNE tempo2
LDS R16,ISP_PORT_IN
SBRS R16,7 // test ISP pin 7 active
RJMP start_boot
endpro:
Hi -
in case anyone else comes in from google/bing looking for how to change the bootload sense pin on an xmega (as I did a couple of days ago), I have written up a how-to aimed at other amateurs. This takes the disassemble and hex edit route, rather than IAR.
http://www.hilltop-cottage.info/...
Cheers, Adam
Hi all,
I can see that the current bootloader need a switch or input port to select that bootloader routine.
Do any one got a better idel or way? other then need to press the swtich and power ON.
CS
I rather like the switch/jumper approach; I find it very controllable!
It does not have to be a power on, of course, a hardware reset will do the job.
Arduino tried something "smarter" with Leonardo, but IMO it just makes for more trouble in practice.
The Leo approach also relies on software on the PC side, which makes it messier.
Adam
I know this is a long-dead thread, but since I just made my way into XMEGA land, trying to create a decent boot loader, I stumbled over it just a few days ago, and happened to find a few "niceties" in the AVR1916.zip linked in #4 above.
Has anyone ever noticed that it contains a subtle little bug?
Obviously, the last thing they changed was the boot loader for the atxmega192a3u, because there was a bug in common\services\usb\class\dfu_flip\device\bootloader\xmega\conf\conf_usb.h - line 108 was changed from
#define USB_DEVICE_PRODUCT_NAME "DFU ATXMEGA128A3U"
to
#define USB_DEVICE_PRODUCT_NAME "DFU ATXMEGA192A3U"
obviously to cure a copy-and-paste error.
They didn't, however, add this change to the other .zip files in the source code directory. So, if you first unzip the atxmega192a3u source code and then unzip one of the others over it (feasible, since they only differ in one distinct subdirectory with the IAR project settings), you re-introduce the error.
Plus, they left the complete debug build for the atxmega192a3u in, which accounts for the "(huge!)" in #4. Here's a cleaned-up version of the .zip file - all xmega boot loaders rolled into one, minus the debug build. Much smaller this way.
