Well nuts.

Last week I completed my final goal for my XPLAIN replacement firmware – to merge the XPLAIN USART bridge and PDI programmer into the one single firmware, so that either can be used with the use of a jumper, much like the method used to access the DFU class bootloader. I was hoping that people would be jumping for it, but it seems not the case; not only has the interest been marginal at best, but it turns out I forgot to add a critical file to the SVN repository. That’s right, it would never have compiled for anyone anyway, yet I only find out almost a week later. Hear that? That’s the sound of my nerd heart breaking when I realized that no one cared about the work I did. Nevertheless, perhaps when Atmel begin to use it, it will gain a little more recognition — and the repository is now fixed.

Actually, I did have a big success last night; I managed to connect the free uIP TCP/IP stack up to my RNDIS host class driver, and make a very simple webserver work when connected to my ADSL modem via USB. That’s a little different to my own home-grown TCP/IP stack used in the regular LUFA demos, because uIP is designed to be far more robust (and can handle multiple simultaneous connections). The code is now in the SVN under Projects/Webserver, and I’ll be extending it to include FatFS so that it can serve files off of the dataflash.

I was having some real trouble getting it all working correctly, with some very odd behavior: while about 30% of the time my code would read in packets correctly, process them via uIP and respond, the other 70% of the time it seemed that something was getting severely corrupted (corrupt data being read in from the USB interface, random restarts, etc.). Initially I suspected a uIP misconfiguration causing stack corruption, but eventually I narrowed it down to the way I was handling bidirectional data endpoints in the RNDIS host driver. It seems a patch I made a while back broke things rather than fixed them. While the USB AVRs can’t really support bidirectional endpoints in device mode (it’s possible to do it, but only if the host expects half-duplex communications) host mode is another matter entirely. I was under the impression that a trick similar to device mode was needed to get bidirectional data flowing, but it turns out I can just allocate two separate pipes. Doh – when I switched the pipe token to change the data direction, data from the device being sent would corrupt the USB banks and cause all the random issues.

That means the RNDIS and CDC host drivers in the latest release are badly broken, and will be fixed in the next official release. I hate rolling back patches, but in this case I was wrong to change the code in the first place. For those wanting the code right now, you can either download it as an archive straight from the GIT repository host, or use the GIT/SVN mirrors.

I was planning on connecting my USBKEY up to the general internet to show off its new capabilities, but yet more heartache – something either in my ISP or my equipment is blocking outside connections, despite my fiddling with port forwarding, DMZ and Firewalls. For now, you’ll just have to test the source on your own network equipment.

One more bit of news; while no one seems to care about my XPLAIN work, LUFA in general is finding more new users. Each LUFA release typically gets around 450 downloads total – the latest releast is just about to hit the 1000 mark. Awesome!


Comments: 9

Leave a reply »


I’m glad you resolved the bidirectional endpoints in host mode. I was going to look into that because I use two pipes on the AVR32 which appears to have the same USB engine. I just got USBKey and was planning to try your LUFA.

I have been working on how to support PS3 and Wiimote game controllers on USB and Bluetooth. Your LUFA and Bluetooth stacks are very close to being able to support this already, you don’t need all the SDP and SPP stuff. Take a look at circuitsathome.com . Wiimote on the USBKEY might be interesting for an Elektor article.


Thanks for all your hard work on this, but being a newbie, this is somewhat over my head. I have been using Arduinos and programming 168 AVRs and would like to move onto the Atmega 128. I have just purchased an XPLAIN board, but have not yet figured out the steps on how to program it. Maybe a more basic description or tutorial would promote more interest in your firmware.


[…] 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 […]



Does that mean that I can connect a 10/100 USB Ethernet Interface to the XPLAIN board and use it as a TCP/IP Server? Or isn’t that possible?



Yes, if said USB ethernet interface is Microsoft RNDIS compatible (I’ve no idea how many are, but if it works in XP without drivers it has to use RNDIS). For my test system, I’m using my old (cruddy) USB ADSL modem as a glorified USB-to-Ethernet adapter.

Note that currently HTTP serving is very slow, as I’m having some uIP issues which I’ve posted to the uIP mailing list. Basically, the HTTP application is not receiving ACKs for its sent packets correctly, causing it to send out the next packet only once the timeout period has expired. Once that’s fixed up the resulting system should be reasonably fast when serving to a client.

– Dean


Actually, thinking about this some more – while the AT90USB1287 chip supports host mode, the XPLAIN board isn’t built for it. The AVR is unable to supply VBUS to a target, which would mean getting it to work would require a spliced USB cable where the adapter VBUS is connected to 5V, and the XPLAIN’s VBUS would be left unconnected. It would probably make more sense in this case to use the USB chip as a RNDIS host adapter only, and run the actual TCP/IP stack on the XMEGA for speed.

I’m using the code on my USBKEY, which supports proper host mode.

– Dean


What about if I split a USB cable and connect XPLAIN’s VBUS? Shouldn’t that work, too? I mean, giving it 5V VCC via USB and letting it communicate with the RNDIS NIC.


Hm, I think I’ll get hands on using the AT90USB1287 as a RNDIS host adapter and let the XMEGA do TCP/IP. You’ve inspired me to do that now. I’m also thinking of attaching a HFC-USB (HFC-S) ISDN controller to the XMEGA and use it as a call monitor.

Thanks for LUFA. Keep it going.


Sorry to bring an old thread back to life, but enabling USB host mode on the XPLAIN is exactly what I want to do. I have worked out that the XPLAIN runs off 5v on the VBUS line, so it can’t provide it to a peripheral device without a spliced cable, but I have a couple of questions.

First, is it simply a case of splicing 5v into the cable to power the XPLAIN (male mini-A connector, pin 1) and the peripheral (female type-A connector, pin 1). Second, will pulling the VBUS line high permanently screw up the USB negotiation protocol?

I use LUFA and your XPLAIN BRIDGE, by the way, they’re fantastic. Thanks.


Leave a Reply

(will not be published)


Vital Stats

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

Latest Blog Posts