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:
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.
Step 4: Program the USB AVR
After you have started FLIP, you should see a screen similar to the one below (click to enlarge).
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:
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.




This is a very cool project!
I really love reading detailed instructions even I am not a beginner.
Dean:
Great tutorial. I followed your directions and the programming went flawlessly. Thanks for the jump start on getting to use my XPLAIN board as both a programmer and USB-Serial converter.
Steve
Hi Dean, thank you very much for your software, it works very well!
You are really the best!
I’m he guy that postedon youtube the video of XPLAIN with 9 musics and the vu-meeter.
Now thanks your software I can play with xplain and without an external programmer.
I’m not a so goo pprogrammeras you but if you need something, ask to me, if I can help.
Bye
Davide
WinAVR link is http://winavr.sourceforge.net/ not http://winavr.sourceforget.net/
Thanks for that, I messed it up while typing it. I’ll fix it in the post so others aren’t confused.
- Dean
Hi, I get as far as the step where it is supposed to install the USB driver and it fails….
I have put a small application on the XMEGA which sucessfully outputs hello world once a second to the USB bridge serial port and I can see both the output for this on COM5 (by default) on the PC and a brief red flash of the power/USB led.
If I remove the USB-to-serial driver on the PC, then replug the board, the PC ALWAYS sees the board enumerate as the USB-serial gateway and not the DFU device, this is regardless of whether the jumper is on or off pin 1/2 JTAG USB header. Also, the power LED briefly flashes red regardless of the jumper setting.
This leads me to suspect that my board does NOT have the bootloader programmed into the AT90USB1287. However, looking at the back of the board it says REV 2 on the silk screen.
Is there anything else I can try or does it look as if this board really is bootloader-less?
Are you bridging pins 1+2 of the USB AVR JTAG header, and not the XMEGA JTAG header? The USB AVR JTAG header is located on the left side of the board, held with the Micro USB connected pointing towards you.
If it still enumerates as the Atmel USB-to-Serial gateway, your board probably lacks the DFU bootloader for some reason.
- Dean
Heh, yes I’ve got the right header and pins
Anyway, I’ve just added an ISP (SPI) programming header to the AT90USB1287 as a last ditch attempt to get into it… and hey presto it’s all working!
Here’s what I did. I first took a copy of whatever was in flash on the device which I’ll have a look at in a bit, but it is probably bootloaderless as the boot reset vector fuse isn’t programmed I notice….
Anyway at the moment, I’m much more interested in the fact the AT90USB1287 now has a lovely copy of your Xplain bridge firmware programmed and running!!
It enumerates as either a serial bridge or MK2 ISP programmer depending on jumper over pins 9/10, as expected.
I’ve not programmed a XMEGA firmware via it yet, but it looks promising as I can read the XMEGA’s sig bytes from AVR studio… Also the serial bridge appears to work flawlessly and doesn’t drop or mangle characters like the Atmel bridge firmware (but you know that
.
I’m thinking I really ought to get a copy of DFU bootloader from somewhere so that I don’t have to leave the ISP header in if I ever want to update your bridge firmware for any reason(?)
Anyway, outstanding work I’m very impressed, and thankyou very much for your efforts. Atmel ought to ship the XPLAIN with your code on it’s far superior
One final question… do you think there could be added a mechanism to allow toggling the operating mode (serial bridge vs ISP programmer) via the USB link rather than with a jumper? I guess one could have a magic sequence on the serial from the PC direction that reset the device and put it into ISP mode, but I can’t think of a way back out of ISP mode back to bridge… Maybe toggle between two ISP interface frequencies or something (altho that seems a bit gash…
Anyway, thankyou again.
Best regards, Simon.
I’ve now had a look at the original flash image I’d saved and it DOES contain a boot loader.
As I mentioned, the boot reset vector fuse wasn’t set, so I’ve just done the obvious – ie. loaded the original image back on and set the fuse. It now enumerates correctly as DFU with jumper over pin 1/2. I then used Atmel’s programming tool Flip to program your xplain firmware and that now works too.
So there was at least one (and probably more) xplain boards out there with the boot fuse set incorrectly.
This board came directly from Farnell Electronics in the UK for interest.
I did notice that the JTAG port was enabled via the JTAG fuse so I could have got in via that route – if I had a JTAG programmer, which I don’t, hence soldering the ISP connector on.
First, thanks Dean for LUFA, and for this very useful replacement firmware.
One thing worth mentioning is that some boards seem to require you to explicitely assert reset on the AT90USB1287 after normal powerup in order to start the bootloader. This was the case with my board. Regardless of the TCK/GND-jumper setting, it always enumerated as serialport upon powerup.
So instead of just placing the TCK-jumper and powering up the board, you might also need to ground the RST pin on the same header in order to reset the AT90USB1287.
Might save a couple of hours for people.
(with the new LUFA-based firmware, however, explicit resets are no longer necessary)
/Jimmy
Hi Dean. Thanks for this great tutorial and LUFA. The only thing that tripped me up was the boot reset.
FYI – The latest FLIP 3.4.1 (Jan 28, 2010) now supports Windows 7 and Vista 64-bit with a signed driver.
I haven’t worked with the USB AVRs yet, but shouldn’t it be possible to support both, the AVRISP-MKII emulation and the serial bridge at the same time by merging the two sets of interface descriptors and running both tasks at once on the AT90USB1287? That would allow to keep the board powered and the serial channel open while reprogramming the XMEGA.
Yes, it would be perfectly possible to do both at the same time — if the Atmel/Jungo driver allowed it. As it stands I can’t figure out any way to get the Atmel AVRISP driver to bind to an arbitrary interface within the device, rather than the device itself, so I can’t turn the app into a composite device with dual programming/serial capabilities.
- Dean
Thanks a million, Dean. I’m glad you did this so I didn’t have to! Do you think changing the bridge baud rate would be as simple as changing the BAUD macro in SoftUART.h, e.g. to 115200?
Yes, altering that value will indeed alter the software USART baud rate. However, due to limitations imposed by the fact that it is indeed software and not hardware USART, you probably won’t be able to dial it up much further than the existing 9600 baud without transmission errors due to insufficient cycles to bit-bang the data.
- Dean