Mein Server!

Wowza. The 091223 LUFA release has had around 1100 downloads, nearly causing my server to go into conniptions. That’s easily more than double the number of releases of previous releases, and I’m pleased as punch with the increased uptake. I’m dying however to get a new release out with the major fixes to the AVRISP-MKII project code and other demos, but I want to complete TPI protocol support in the AVRISP-MKII project first. Thankfully it looks like I’ll have that working very soon, so we can all look forward to the next official release. I’m planning to have it enter a two week beta testing cycle (with the increased user-base, it is now more important to ensure each release is as free of defects as possible) beginning late this week.

I thought I’d fill up this entry with a short guide to loading my XPLAIN Bridge firmware into the XPLAIN board, after some coaxing. Without further ado, here it is!

Loading the XPLAIN Bridge code into the XPLAIN board

Step 1: Get the Source

Before you begin, you will need a fresh copy of the latest XPLAINBridge code. This is part of my LUFA project, however you will need the most recent in-development code instead of the latest LUFA release. Start by downloading a zipped package of all the latest LUFA code, straight from my online source repositories.

Extract out the entire package somewhere on your hard drive – a path without spaces is best (such as C:\AVR\LUFA_SRC\).

Step 2: Get the AVR-GCC Compiler and Tools

Most people should already have the required tools installed for AVR development, but I’ll put it here for completeness. On Windows, look no further than the WinAVR package – just download, install and you’re done. On Linux, grab the “avrgcc” package from your repositories. This will install the required compiler which can compile your source code into machine code that can be loaded into the AVR microcontrollers on the XPLAIN.

The other tool you’ll need is the Atmel FLIP software, which will act as our programming frontend for the USB AVR later on. Download and install it – if you are on an x64 based system, you’ll need these signed drivers instead.

Step 3: Build the Source

LUFA is a big project. No seriously, it’s HUGE and I’ve spent a lot of time on it. While it can make the USB AVR on the XPLAIN board to wondrous things with a minimum amount of pain, we’re only interested in one small project I’ve made with it. For that reason, you’ll need to navigate to the {LUFA Root Directory}/Projects/XPLAINBridge/ folder before you compile, lest you sit around for 10 minutes watching around 100,000 lines of source code be compiled.

Once in the XPLAINBridge project, you need to open up your terminal (that’s Command Prompt in Windows-land) and type make all. This will compile the XPLAINBridge code into the machine code needed for the AVR processor to execute.

When run, you’ll see a lot of similarly named files with different extensions be created. Most of these are related to the compiling itself, and we are only interested in the XPLAINBridge.hex file that is created – that’s the file which contains the compiled machine code for our programmer software to use.

Step 4: GET TO THE BOOTLOAAWDERRR!! (this is funny if you read it in an Arnold Schwarzenegger voice)

Unless you’re unlucky enough to have a first revision XPLAIN board (which 99.99% of you will not) your XPLAIN’s USB AVR comes preloaded with a special AVR program in it called a bootloader. This special program lives in the upper sections of the chip’s non-volatile FLASH memory, and allows you to reprogram the remainder of the memory with a regular AVR application through a non-standard interface (in this case directly from the USB port) without external hardware.

To get to the bootloader, you need to jumper the TCK pin to GND on the USB AVR JTAG header, that is, pins one and two shown here:

Jumper the circled pins to enter the bootloader.

When jumpered, plugging in the XPLAIN to a PC via the USB port will cause it to start it’s DFU class bootloader. You should get a driver popup under Windows – point it to {FLIP Install Directory}/usb for x86 systems, or to the drivers in the signed driver package you downloaded earlier for x64 systems. If this does not happen, you may need to apply power to the board and momentarily jumper pins 6 and 10 as well to force a reset of the USB AVR.

Step 4: Program the USB AVR

After you have started FLIP, you should see a screen similar to the one below (click to enlarge).

The FLIP Interface.

First click the Select Target button (#1). From the dropdown, choose the AT90USB1287 entry (this is the USB AVR mounted on the XPLAIN board) and click OK to dismiss the window. Next, open the device via the Select Communication Medium button (#2) and choosing USB – click OK when the dialog opens up to establish a connection with your XPLAIN’s USB AVR.

Now you need to load the XPLAINBridge firmware into FLIP. To do this, click the Load HEX File button (#3) and select the XPLAINBridge.hex file you compiled earlier in step 3. Program it into the USB AVR by hitting the Run button (#4). Remove the jumper you placed earlier to access the DFU bootloader, then start the new firmware via the Start Application button (5). Don’t worry if you forget to remove the jumper before this step – just remove it and power cycle the board to exit the bootloader.

Step 5: Load the Bridge Drivers

By now, you should see a new driver window pop up, asking for the LUFA XPLAIN Bridge drivers. You’ve now successfully programmed in the bridge firmware! In the mode you are currently seeing, the firmware is acting as a USB-to-Serial bridge for the XMEGA AVR on the XPLAIN board. Before it will work correctly however, we need to supply the right drivers. In actual fact, Windows already contains the appropriate drivers, but you’ll need to supply the XPLAIN Bridge.inf file in the {LUFA Root Directory}/Projects/XPLAINBridge/ folder for it to use them. This will probably pop up an unsigned driver warning on your system — this is Microsoft’s fault (and not mine!) for not signing their own driver.

When loaded, you’ll be able to communicate with your XMEGA chip by the new virtual COM port the driver will create on your system.

Step 6: Load the PDI Programmer Drivers

The XPLAINBridge firmware contains a second mode – it can act as a clone of an Atmel AVRISP-MKII so that you can reprogram the XMEGA from within AVRStudio. To access this mode, you’ll need to jumper the TDI and GND pins of the USB AVR JTAG connector (pins 9 and 10) together and power-cycle the board, much like you did to enter the DFU bootloader:

Jumper the circled pins to switch to the programmer mode.

This should cause Windows to ask for a second set of drivers, for the new AVRISP-MKII Clone Programmer device. Point it to your {Atmel Program Files Folder}/AVR Tools/usb/ folder (for x86 systems) or {Atmel Program Files Folder}/AVR Tools/usb64/ folder (for x64 systems) and let it install Atmel’s drivers. You’ve now got yourself a programmer! To exit programming mode and return to the USB-to-Serial bridge mode, just remove the jumper you placed on the JTAG port and power cycle the board.

Step 7: Program the XMEGA AVR

When in programmer mode, you can reprogram the XPLAIN’s onboard ATXMEGA128A1 microcontroller via the PDI protocol, using any supported host software you like, such as AVRDude (note: PDI programming is broken in the latest release and requires manual patching) or Atmel’s own AVRStudio. For AVRStudio, you can follow the procedure in the AVR Tools help file, included with the application – just connect to the AVRISP MKII programmer, select the ATXMEGA128A1 target and use it like you would a regular AVRISP-MKII device.


Comments: 133

Leave a reply »


This is a thing of beauty. Thank you Dean!


I also had an XPLAIN board with the wrong fuses set out of the box. Correcting the fuses as explained in under heading 2.4 of using a JTAG ICE MkII corrected this issue and allowed the jumpering between pins 1 and 2 to enter DFU class bootloader mode. Previously, this would not work as the wrong bits were set. Then things ran flawlessly.


Is there any schematic for the XPLAIN board detailing the connection of at90usb1287? Can I access its ports on the board? What is the frequency it is running? I’ve seen all the docs on but surprisingly I could not find such details…

BTW: great work!



It’s not as easy to find as I would have liked, but the XPLAIN schematics are in the Hardware/ folder inside this application note:

See the “USB” schematic sheet for the AT90USB1287 connections.

– Dean


Thank you very much 🙂 I’ll take a look at it.


Thanks to you Dean ! Awesome work.


Pardon my noob question, but I flashed your excellent bridge code onto the AT90USB1287 in order to erase the XMEGA, and then flashed another program onto the ‘1287. Now I can’t access the DFU bootloader. Did I blow it away?


If you used an external JTAG programmer, then yes, but if you used the steps listed in this post, then no. To get back to the DFU bootloader, try shorting pins 9+10 as shown in the post, but also momentarily short pins 6 and 10 to force a reset of the chip while it is powered. That should get you back into the DFU bootloader.

– Dean


Thank you very much!!! LUFA works well!!!


Dean, thanks for the info. The board kept coming up ‘Unknown USB’, but I tried it on my laptop and the DFU bootloader came right up.


Hello Dean & others,

thank you for this software, great job! I am using it for my XPLAIN board.

Unfortunately, I’ve hit a problem which I do know know how to solve.

Due to a misinterpretation (my fault) of a post in a forum, I changed


in the makefile of the AVRISP-MKII/ subdirectory. Now, I only have the programmer mode available, but not the USB-bridge. For some reason, I cannot connect any more with the dfu-programmer.

How can I reprogramm the XPLAIN board?

Your help would be very much appreciated!


PS: Sopftware is
Ubuntu 10.04
dfu-programmer 0.5.1
avrdude 5.10
avr-gcc 4.3.4

The sricker on my xplain-board says Revision 5


Ok, managed to get the xplain back to dfu-programmer mode. I didn’t understand that I had to shorten pins 6 and 10 to get it back to this mode. Sorry.

Great software, thanks again!


No problem, glad you’re sorted. Enough people are having trouble with this that I’ll update the post to add in the extra forced reset step. Enjoy!

– Dean


I am having trouble getting the serial port to work correctly, i have both drivers loaded correctly ( i think), device manager pops us and tells me either AVRISP mkII (for pin 6+10) and COM4 (for pin 1+2), but I cannot get a simple printf to say “hello world” over terraterm, any ideas???



What baud rate have you got your terminal running at? The latest XPLAINBridge will use the USART speed you set in your terminal program, and also won’t allow any data transfer until a speed is set. The original Atmel version ignores the baud setting and assumes 9600 baud at all times.

– Dean


I have not set a UART speed in my program, that must be my problem, I assumed this was in your XPLAINBridge firmware, Do I need to include a complete UART driver in my program? Or do you mean which speed is my terraterm set at? This is set at 9600 baud.



The latter – the terminal program just needs to send a baud rate to the XMEGA, or it won’t communicate at all. Are you matching the baud rate settings between the XMEGA and Terraterm? You need to make sure the XMEGA is using the 9600 baud, (presumably) no parity, 8 data bits, 1 stop bit settings that your terminal is using. If the two don’t match, you’ll either get nothing at all, or a garbled mess of junk data.

– Dean


Ok I thought all of that would be included in a UART driver which would be in your firmware, where should I got to declare the baud, parity and stop bit for the XMEGA, I know how to do this with terraterm, thank you



The USART portion of my XPLAINBridge firmware converts the physical UART link between the XMEGA and the USB1298 into a virtual USB serial port, and vice-versa – it’s basically a glorified MAX232 that has USB instead of RS-232. That means that the terminal settings you use in your terminal program (Terraterm in your case) are used by the microcontroller to determine what settings to use on the physical UART link between the two microcontrollers. For communications to work correctly, you need to match these settings on the XMEGA side, so that both sides can send and receive data formatted in the same manner. If the settings don’t match, you won’t be able to communicate between the PC and XMEGA correctly.

The XMEGA side of the equation is up to you to write; you need to initialize the UART of the XMEGA with the baud and packet format settings you are using in Terraterm.

– Dean


Ok cool, i see now, thanks for your help dean!


Did anyone try to program a external XMEGA like Dean suggested at July 20th?

– Stephan


I’m waiting for an AVRISP mkII to arrive since a week before Christmas, but due to the snow haven’t got it yet, so I may well be attempting this!

AFAICS this isn’t quite straight forward. Either the reset or the data line has to be isolated from the on-board xmega128, and in the case of reset this has to be pulled low on the xmega128 only. Unfortunately the routing of the reset signal seems to go from the USB chip to the xmega128, then to the connector J100 (XMEGA_RESET_PDI_CLK) making isolation difficult.

However, the data line (XMEGA_PDI_DATA) actually has a pair of resistors R203 and R205 in the line near the USB chip, so it seems this can be relatively easily isolated by removing the resistors and placing some kapton tape under two of the pads. These would then be replaced and a wire taken from the common side to the data line of the external board. The reset and ground can be taken from J100.

I don’t know whether this would work, the external board would need to be powered by 3.3V (or possibly powered by the 3.3V from the xplain board).

If my AVRISP mkII hasn’t arrived by tomorrow I’ll give this a go and let you know what happens.



OK, AVRISP mkII hasn’t arrived so I had a go using the XPLAIN board and the XPLAIN Bridge firmware as a programmer for an external xmega.

I can confirm that isolating the data line by removing and replacing R203 and R205 works, I now have a makeshift external xmega PDI programmer!

What I did was find R203 and R205 on the XPLAIN PCB, these are together near the USB chip and crystal, just above the test point marked PR0. If you are unsure buzz it out with a multimeter, you should find the two common pads that connect to the data line J100 pin 8. I removed these resistors (220R) and replaced them pointing the other way in a ‘V’ shape so as to isolate the two common pads. I then connected a small wire from the tip of the ‘V’ (i.e. where the two resistors connect) and wired to the unconnected spare pin on the USB JTAG connector (J200 pin 8).

I’ve used a standard 6 pin PDI header on my external board labelled P1, so I connected the following pins between the boards using jumper cables:

J200 pin 8 to P1 pin 1 (data)
J100 pin 6 to P1 pin 5 (reset#/clk)
J100 pin 10 to P1 pin 6 (gnd)

I power my external board separately so didn’t use the 3.3V on the XPLAIN board to power my external board. Due to the substrate diodes this has the effect of pulling reset low when the external board is powered down, but as soon as power is applied the xplain board recovers.

To convert back to to an internal programmer all you need to do is jumper J200 pin 8 to J100 pin 8, i.e. reconnect the data line back to the internal xmega128.



Firstly, thanks Dean, and great job, you’ve certainly made the Xplain board more useful.

Now comes my problem. 🙂 Which I imagine is just something I’m doing wrong because it seems very fundamental. And reading through your Xplain bridge code I can’t find fault there. But I’m seeing the following behavior. I write a simple test program for the xmega128 that sends some characters over the serial port at 9600 baud (no divisors, default 2MHz clock and a BSEL value of 12). I have used three different serial interface programs (minicom, cutecom and screen /dev/ttyACM0 9600) and they all behave the same way. That is they all give garbage out instead of the characters I’m expecting to see. But, if I force them to switch baud rates to something else and then back to 9600 I get the expected output. The simplest way I have to reproduce the behavior is with the following commands:

This produces bogus output.
screen /dev/ttyACM0 9600

This produces the expected output.
stty -F /dev/ttyACM0 600; screen /dev/ttyACM0 9600

And if I make my example program a bit more complex and let it accept and echo characters I can see that both versions above are in fact working to some degree (I can type and see garbage echoed back in the first case, and what I type in the second case). By guess right now is that if the terminal emulator reads the baud rate from the tty and sees that it’s already 9600 baud then it doesn’t bother setting it and something doesn’t get initialized correctly in the bridge. And that’s why forcing it to another value and then back works. But reading through the software UART it’s hard to see what could be missing.

I build the XPLAINBridge project from the archive. And loaded it onto the at90USB using dfu-programmer-0.5.4 that I also built on Ubuntu 10.10. I can provide an example program for the Xmega128 if that’s useful.

Thanks again,


Just a quick update on my comment above for anyone having the same trouble. I believe I have solved the problem and have posted a fix to SoftUART.c here:



Hallo Dean,
Just a great job you have made. At least I have a question:
did anybody ask for program the onboard flash and not the flash on Xmega.
I bought the Display Xplained and the Touch Xplained and it seems, that all graphical stuff has to be in the on board flash! Atmel talk about mass-storage in their documentation about the connection over AT90USB1287 and did your driver work with that flash?



While the XPLAIN Bridge firmware I’ve written can’t do this, the regular LUFA Mass Storage demo can (see Demos/Device/ClassDriver/MassStorage/ in the latest LUFA release). Once recompiled for the XPLAIN board – set the correct makefile options, in this case just set BOARD = XPLAIN) the XPLAIN board will appear to the host as a regular data storage device just like any USB flash drive.

That said, I think the Display Xplained demo firmware expects the data to be loaded onto the Dataflash without a filesystem, in a proprietary format. In that case, you’ll need to ask Atmel for their loader software, or use my code with Linux and the dd tool to write the raw data onto the Dataflash pages.

– Dean


Hi Dean,

Will this work with the Xplained ?


Unfortunately not – I’ve not yet completed the AVR32 port to a releasable degree, and the new Xplained boards use a AT32 UC3B chip in place of the previous AT90USB1287. Once the AVR32 port is complete I’ll release an updated firmware for the newer boards.

– Dean


Just wondering on the status of the AVR32 port for use with the new Xplained boards.



I’m time-poor at the moment (as always) but I’m currently working on porting the AVRISP-MKII Clone project to the AVR32s, which the XplainBridge firmware is dependant on. Once that’s done, getting the bridge code working should be simple, as it’s just a basic USB-to-Serial converter bolted onto the AVRISP-MKII Clone code.

– Dean


Would it be possible to make it serial based, so I could run it from a mega8, just for a pdi programmer for the xmega?


Only Atmel’s USB driven programmers support PDI, which in this instance means the AVRISP-MKII. The original serial AVRISP doesn’t support PDI programming, thus AVRStudio wouldn’t recognize the programmer.

It may be possible to get avrdude working with it over a serial connection (since it’s not fussy about the physical transport used for each programmer, as it’s selectable) but AVRStudio wouldn’t work.

– Dean


Ok, I was just trying to make something that I have here work. Perhaps I will get a USB avr then.


So with the release of the new source code, will the xplain stuff work with the new xplained boards or is that still a work in progress?


Work-in-progress unfortunately, and somewhat delayed due to my other (University) commitments. I want to get full UC3 support as a first-class citizen into LUFA before the next release however – otherwise I’ll never finish it – and that means porting all the demos, fixing all the endianness issues, adding platform support for the missing runtime bits (ISRs, etc.) and of course getting the XPlain Bridge code running on the newer boards.

– Dean


Hi Dean and all others,

first thank you for the great Firmware,

but i have a problem with the Windows driver of the AVRISP-MKII.

All steps to number 6 was completely OK, but in step 6 Windows (7 Professional 32-Bit) isn’t able to find a possible driver in the …Atmel/AVR Tools/usb/ folder.

If I install the windrvr6.inf (the only .inf-file in the folder) manually, AVR-Studio don’t find a AVRISP-MKII.

Is the windrvr6.inf the right driver file? What is my mistake?

Please help, thank you!



Sorry @ all,

i only have to install all service packs of AVR Studio 4.

My fault.

Greetings, Bimbo385


Can I use the LUFA with the new UC3-A3 Xplained Xplained?



The UC3A3 chips are supported in the new multi-architecture port, so yes. However, keep in mind that the internal class drivers other than Audio and HID are not yet ported, and neither are the project demos — so if you want to go that route, you’re in for a bit of leg work to get it up and running. There’s a new MultiArchDemos\ branch in the LUFA SVN with working AVR32 demos in Demos\Device\ClassDriver\Mouse\ and Demos\Device\ClassDriver\AudioOutput\ at the moment.

– Dean


Hi Dean, but your firmware for the Xplain (AVRISPmkII) does not go with the Xplained or?
I would like to use the Xplained AVRISPmkII as it would work?
Thank you for your help




Not yet – I’m slowly porting the class drivers and demos to the UC3 devices, but it’s not finished yet (lots on my TODO plate already that I want to get done first). The XPLAINED boards all use an Atmel AT32UC3B0256 microcontroller if I remember correctly instead of the older 8-bit AT90USB1287, which the code does not currently target. I need to port the project, fix the endianness issues in the CDC class driver and add in the low level serial peripheral driver for the UC3 parts before it will work.

– Dean


ok Thank you I think it’s worth waiting a little bit 🙂



Great work – rarely have seen something this nice…
Good luck with further projects


Hey Dean,

I downloaded the new version of your project (LUFA-111009-BETA). Does it support the new XPLAINED boards with the UC3A3 chips? How do i compile and connect to the board? (my Flip only shows the devices ATMega32U2 and ATMega32U4 but not UC3)

Thanks in advance 😉



The XPLAIN board controller and other demos/projects haven’t been ported to the UC3A3, although the core library is now ported. Since there seems to be a reasonably high demand for a working CDC-ACM serial bridge on the new chips, I’ll do my best to make a working port of the USBtoSerial project for the newer boards.

– Dean



i received an Xplain from a friend so i installed lufa on it and it works.

my only problem is that i can forget baud rates over 9600 Baud. 19200 Baud are okay but not good. Even if i connect the XTAL1-Pins of both mikrocontrollers (so both have the same or a multiple clock of each other) it does not work well.

At which end do i have to optimize? Is it the xmega, the 90USB1287 or something else? i guess the goal would be fitting the baud rates of both mikrocontrollers, right? what i tried is sweeping the BSEL value from -10% to +10%. This “works” at 19200 BAUD (there is a point of “less errors”) but not for more.

Any Idea? (even if this problem could have multiple problem sources, e.g. LUFA, XMega and 90USB1287, coding, …)

Thanks in advance


Probably the AT90USB1287 end. Annoyingly the 1287 has only one hardware UART, and that’s dedicated to PDI programming rather than general serial communications. That does mean that programming is rock-stable at the hardware layer, but general communications with a PC needs to run through a software UART. I’ve spent a bit of time optimizing the software UART in the XPLAIN bridge, but if you think you can improve it you are more than welcome to have a go at it. It may also pay to tweak the size of the ringbuffer and the “(BufferCount > 200)” conditional in the main function loop.

Full-duplex communications at high baud rates is unlikely to ever work, due to the large CPU load placed on the processor.

– Dean


Hello Dean !

I know it is a quite old post, but I reusing my XPLAIN board with your perfect bridge, its works like a charm under AS5.1 (as foreseen). Thanks a lot ! But I have a question:on my computer I have both AS4 and AS5.1 in //, so I have access to the AVRISPmkII usb inf file. However this file does not exist in the AS5.1 folder. So what can I do in this case ? Should I let windows find itself the driver ?
And I would like to know if the new toolchain provided with AS5.1 will produce a good XPlainBridge.hex file like WinAVR ?

Thanks again for your work,
Have a nice evening,


Hi Carl,

Great to hear! I assume that you recompiled from the latest LUFA beta package, as I hadn’t updated the binaries posted on the project page (I’ve now fixed this). The Jungo USB drivers for AVRStudio 5.0 upwards is located in C:\Program Files (x86)\Atmel\AVR Jungo USB\ rather than the old AS4 driver directory, but you should be able to allow Windows to automatically pick the best driver regardless.

The Atmel Toolchain can be used to compile the project, however you will need to download the last release of WinAVR or the GNU shell utilities separately (such as grep and sh) as the LUFA makefiles require those programs but the newer Atmel Toolchain does not include them.

– Dean


Leave a Reply

(will not be published)


Vital Stats

  • 28 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts