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.
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
Hi,
I am trying to run the xplain board under linux. But right now I am stuck at step 4. I also followed this guide: https://m21.hyte.de/wiki/Projekte/Atmel-XPLAIN-Board (sorry, seems there is only a german version). “lsusb | grep -i atmel” will print “Bus 006 Device 015: ID 03eb:2ffb Atmel Corp. at90usb AVR DFU bootloader”. Every time I set RESET to GND the Device number increments. However, dfu-programmer and flip both say there is no device. If somebody could help me out, that would be really nice.
Marc,
I assume from the lsusb command you referenced that you are running on a Linux system. Have you tried using a Windows system? I’ve seen some interesting permission errors under Linux with USB devices, where some programs do not have the required permission to access the USB devices on the bus directly. Does starting Flip/dfu-programmer with sudo help?
– Dean
Hi Dean,
yes, it does. I had a look at the dfu-programmer source code and noticed that you can switch on some debug output. In src/dfu.c you can see which debug level is appropriate for you. When I typed in “dfu-programmer at90usb1287 get –debug 500” I got many lines saying “error obtaining child information: Operation not permitted”. As root transmitting the hex file of your project works very well, just like on the site I mentioned above.
Thanks a lot and goodbye.
Hi,
great work DEAN! I was able to do all the steps above. at the beginning everything worked perfect and i was able to test some code. But after flashing a small programm to the XMega, in which the clock wasn’t set, i can’t programm it any more. By default the xemga should have internal RC 2 MHz, so i can’t imagine that there is any problem with it. Read signature and read/set fuse is no problem. Only after verfiying the new programmed flash, I get an error in the first Byte. If you like i send / post the 20 lines of code…
Any ideas?
Thanks
I assume this was on the XPLAIN board? Obviously that shouldn’t happen :P. Send me the .HEX file you tried to program into the device and I’ll test it on my own board.
Can you still access the XMEGA on the board via my code, or are you completely locked out? The latter shouldn’t matter, as the PDI programming interface is completely self-clocked, i.e. it should work even without a valid system clock to the XMEGA.
Cheers!
– Dean
Hey,
thanks for your reply. You are right, it’s the xplain board. I still have access to the xmega. I can read the signature and read/set the fuse, but flashing fails on the verify, and reading it out just gets zeros. The hex file is on the way, via email…
Thanks
bEr
bEr,
I gave the HEX file you attached a go on my XPLAIN, and it programmed in just fine (and appeared to run – data from PORTA is output to the speaker). Have you tried performing a complete chip erase first? In the programing dialog, change the erase dropdown to “Chip Erase” and click the Erase button to make sure the chips’ FLASH memory is reset to all 0xFF.
That will also reset the chip’s lockbits if they are set, which would also cause the odd behavior you describe.
Cheers!
– Dean
Hey Dean,
thanks for your try. I have tried all available erase modes, and also change some fuses, without success. After chiperase i read the flash out, but its all 0x00 in the hex file, not 0xFF. Antoher thing I did’t by mistace, was to shortcut the JTag PIN V3P3 with gnd. But the voltage is still fine at 3.3V, or did I kill with a wrong Juper position some function of the xmega?
Whats about the VTarget Voltage? I think it was before @ 3.3V but now it’s 5.0V!?
Maybe I have to try a JTag programmer, what you think about it?
Best regards,
bEr
bEr,
The VTARGET reported by the XPLAINBridge programmer project wasn’t (until just now, in the latest SVN/GIT revision) meaningful, and reported back a fixed 5V regardless of the real supply voltage. That was an oversight on my end, which is now corrected – the real supply voltage is now returned in the latest code.
If a full chip erase doesn’t fix the board, then you’re looking at the possibility of a dead board — suggest you try with an external programmer if you have one to see if the chip can be reprogrammed that way.
Cheers!
– Dean
So, the baud rate is limited to 9600 when using this as usb to serial mode?
Very nice by the way. Great way to program and communicate like I used to do with the mega 128’s.
Yes, 9600 for serial communications between the AVRs, since the UART has to be software emulated.
Glad you like it!
– Dean
I do everything, but I can’t programming xmega128a1 on xplain board with AvrStudio.
When short TCK and GND in device manager popup Communication port.
When I short TDI and GND in device manager popup Jungo- AVRISp mkII.
In AvrStudio select Program Avr>Connect…>AVRISPMKII>USB but no connection on target xplain board.
Please help me!
Steva,
That sounds like the correct procedure; once loaded and started in programmer mode, Device Manager should install it as an AVRISP-MKII using Atmel’s Jungo drivers as you can see. When installed AVRStudio should be able to connect to it.
If you open up the device in the Device Manager, does Windows give an error as the device’s status? Does AVRStudio bring up the programming window once you choose the AVRISP-MKII, or does it fail to connect to the device at all? If the programming window comes up, perhaps you have forgotten to set the programming mode in the first tab of the programming window to PDI. If the programming method is listed as JTAG and not PDI, the programmer will be unable to communicate with the XMEGA.
Cheers!
– Dean
In AvrStudio select ProgramAvr>Connect…>AVRISPMKII>USB
few second and connect failed.
I don’t see programming window yet.
Thank you for your quick answer.
What does the Device Manager say when you open up the AVRISP-MKII clone’s entry? If it says something like a “Code 10” error, then the drivers or firmware are incorrect. If all’s well there, something else has gone wrong.
What Windows version (including x86/x64) are you using?
– Dean
No error state in device manager for Jungo AVRISp mkII.
My OS is WinXP Home SP2
I try with another PC and everything OK.
Thank you,
my Xplain board is finally live.
Excellent, glad you’re all sorted.
Cheers!
– Dean
Is anyone else having a problem with Step 3? The “make all” is not building the .hex file for me. I have the latest version of WinAVR and followed the directions above.
charlie
Please disregard the previous message. I did a make clean and another make all and everything compiled fine.
Thanks,
Charlie
Programmer mode doesn’t work correctly. When I press ‘Read Signature’ button, signature reads one time and doesn’t read two times after. When I try to write flash, process fails every time.
Version without USB-to-USART bridge works correctly.
Please help me!
Vladimir,
Are you building the XPLAINBridge.hex from the latest repository source code, or are you using someone’s pre-built binary? I just tested the latest version from my repository on my XPLAIN board, and I can’t see the failures you’ve described.
The AVRISP-MKII project code is used within the XPLAINBridge project, so if the former works the latter should work also.
– Dean
Thank you, Dean!
I’ve compile latest XPLAINBridge version and reinstall all drivers (Bridge and MKII). And now both bridge and programmer modes are working!
Hi,
I’ve got a curly one…
When i plug in the device it reports as being Xplain USB Gateway… VID/PID is 03EB/210D
So none of the drivers will install!
I think just hack the .inf to have this VID/PID?
I’ve got a rev 4 board (A09-0560/04)
using Win7x64
That’s the original Atmel bridge code (without the programming functionality) and not my alternative firmware, so the VID/PID is different. You need to install Atmel’s driver INF, which is included in the XPLAIN package downloads at Atmel.com.
– Dean
OK,
So plug in the USB, then short pins 6 and 10 on J200 to reset the AT90USB1287 and it will restart in DFU mode…
Documentation Fail.
* with Jumper on pins 1&2 as illustrated in step 4
Dean,
You have NAILED IT. So impressed.
I’m new to AVR but you just saved me $50 and I could not be happier!
Thanks! XD
No worries, glad you’re all sorted. Enjoy!
– Dean
I wonder if it would be possible to turn the XPLAINBridge into a composite USB device that supports programming and serial communications at the same time through different USB interfaces.
I’ve investigated this a bit and it seems that at least under Linux the cdc_acm driver only looks for the interface class, but doesn’t care about the device class. I think this means the CDC interface could be appended to the AVRISP device (after adjusting the endpoint numbers to avoid conflicts, of course) to get both functionalities at once.
Unfortunately I am not familiar enough with LUFA to try this myself, but that might change soon…
Unfortunately not – avrdude binds to the device’s VID and PID, and not the individual device interfaces. The Windows Jungo driver from Atmel will also only bind to the device if it is identical to the official AVRISP’s descriptors.
– Dean
This code works great!
Question: since this project converts the onboard AT90USB1287 chip to a PDI programmer, would it possible to use this XPLAIN board as a make-shift PDI programmer for an external AVR chip? Meaning that, instead of programming the XMEGA on the XPLAIN, could I program a second XMEGA?
Thanks for any input.
Bryan,
It *might* work, if you hold the XPLAIN’s XMEGA chip in reset by shorting the XMEGA’s /RESET line on the JTAG port to ground. I haven’t tested to see if there is anything else on the XPLAIN which would interfere with external programming, but it can’t hurt to try.
If you’re just after a PDI programmer which can be loaded into a raw USB AVR, look at my AVRISP-MKII project, upon which the XPLAINBridge code is based.
– Dean
Hi Dean,
beatiful work men! I just wonder if there is a chance to use the pdi interface for debugging the xmega? Any idea if this is possible and if it is so how I can manage to get a working toolchain?
greetz Jonas
Jonas,
While technically the PDI interface allows you to debug the controller (to a degree), the AVRISP-MKII is not designed to do it – therefore, there is no set of debugging command in the communication protocol it uses. It may be possible to create a custom host application with custom firmware to use as a debugger, but it would be incompatible with AVRStudio as it would not mimic an official tool.
– Dean