Where's the DFU bootloader?

Go To Last Post
36 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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.

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The package you point to has source code for including the bootloader in your project.

Umm but it also contains IAR project files for building each of the variants ?!?
Quote:

I think I also read somewhere that atmel used iar to compile the bootloader.

That's true. Only IAR guarantees to build them under 4K. Which is a happy coincidence as that's the limit on the "free" version of IAR. Any bigger and you'd have to buy the $3000 version to build the code.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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?


Surely what you found is exactly what I just showed above? As already mentioned it can only be built using IAR. You can download a "KickStart" version of their IDE/compiler from their website and its only limitation is that it can only generate 4KB of code but that does not matter as the bootloaders have to be under that size anyway.

You cannot build the code using Studio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

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.

pixel2001n wrote:
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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never mind, I see it right at the very beginning. Looks easy enough to patch for a different port pin.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jari.koskinen wrote:
But this morning Flip refuses to connect: "Could not open USB device"
Did you try resetting the computer?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. The reconfiguring is only required the first time a new AVR type's DFU needs to be recognized, but it's still a major pain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Which line and digits, etc.

common.services.usb.class.dfu_atmel.device.bootloader.atxmega128a4u.zip/common/services/usb/class/dfu_atmel/device/bootloader/xmega/conf/conf_isp.h(*) contains this:

// 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?!?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(*) Am I the only person on earth who thinks this file and path naming is just about the stupidest thing I've ever seen?!?

No. There is at least one more. I think it's just the way bloatware is going.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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?

The DFU bootloaders are written for the IAR compiler not AS6 (IAR is more efficient than any other compiler and I think it's the only one guaranteed to get the code into the space available).

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

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 size of .hex has nothing to do with the size of the binary it contains. Use avr-size on a .hex to find out how much it really contains.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

Attachment(s):