Get Your Open Source XPLAIN/XMEGA Programmer Here!

Go To Last Post
124 posts / 0 new

Pages

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

Thanks guys!

Do I need it? No. Do I want it? HELL YES! I'll be sure to post a review, etc. when it arrives as I don't think many people have seen one before (I know I haven't) outside Atmel's website.

I'm not certain how Atmel will be using the firmware, but I'm pleased either way. It will be interesting to see if they use it as a base for their own version, or just chuck it on new XPLAIN boards and list me on the XPLAIN page of their website.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

I'm not certain how Atmel will be using the firmware, but I'm pleased either way.

Bear in mind that for the cost of an AVR One! they could employ one contract programmer for just 8 hours so if they are actually getting an implied license to use some of your software (which took a whole lot more than 8 hours to write) as a result of this then they are getting a very good deal. OTOH maybe they are just being philanthropic (knowing Atmel I'm guessing the latter).

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

clawson wrote:
if they are actually getting an implied license to use some of your software (which took a whole lot more than 8 hours to write) as a result of this then they are getting a very good deal. OTOH maybe they are just being philanthropic (knowing Atmel I'm guessing the latter).
Ehm, they already got a LUFA license, like I got one, and like you can get one, too. Not implied, but explicit.

LUFA source wrote:

/*
  Copyright 2009  Dean Camera (dean [at] fourwalledcubicle [dot] com)

  Permission to use, copy, modify, distribute, and sell this 
  software and its documentation for any purpose is hereby granted
  without fee, provided that the above copyright notice appear in 
  all copies and that both that the copyright notice and this
  permission notice and warranty disclaimer appear in supporting 
  documentation, and that the name of the author not be used in 
  advertising or publicity pertaining to distribution of the 
  software without specific, written prior permission.

  The author disclaim all warranties with regard to this
  software, including all implied warranties of merchantability
  and fitness.  In no event shall the author be liable for any
  special, indirect or consequential damages or any damages
  whatsoever resulting from loss of use, data or profits, whether
  in an action of contract, negligence or other tortious action,
  arising out of or in connection with the use or performance of
  this software.
*/

Stealing Proteus doesn't make you an engineer.

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

Quote:

Ehm, they already got a LUFA license, like I got one, and like you can get one, too. Not implied, but explicit.

That's right - they can use it, but they must give me credit. I think a company using my firmware over their own for their boards will speak volumes to a potential employer, and I'd like the recognition.

The other (better) possibility is that Atmel pays me the US$1500 license fee I offer to absolve them of this duty, so that they can release binaries without the accompanying author credit requirement.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Congratulations Dean.

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia

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

abcminiuser wrote:
The other (better) possibility is that Atmel pays me the US$1500 license fee I offer to absolve them of this duty, so that they can release binaries without the accompanying author credit requirement.
I am all for you getting $1500.

On the other hand, Atmel has released at least one application notes based on someone else's code. AVR309 (incidentally also about USB) is written by Igor Cesko and describes his software USB implementation, with credit at the end of the document.

I also always had the feeling that the application note describing the Dragon opto-isolation extension is some kind of "student work". I am, however, not sure if the student, intern or whoever is credited in in the note (couldn't find the app. note in a hurry).

Stealing Proteus doesn't make you an engineer.

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

Congrats Dean! Thanks for all your good works, and thanks in advance for you future endeavors!

David, Canada

Dr. David Harris OpenLCB Development Team openlcb.org

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

Hey Dean, congrats on the recognition from Atmel (whys the quoted email gone now?). I finally got around to trying out the newest version of your programmer/serial bridge. It seems to work great, I'm sure its gonna be really useful in the future.

One thing I was wondering about though is what it does when it finishes programming. After programming, the Xmega seems to be stuck in reset and I have to unplug the usb to get it going again. With my jtagice mkii it does the same thing when using jtag, but if I use pdi the Xmega resets after I close the programming window. It makes it pretty handy since the Xplain doesnt have a reset button. Any ideas on why your programmer and the jtag does this? Is this the way the avrisp behaves? Any chance you can modify yours so that it behaves similarly to the pdi programming on the jtagice mkii? Have I asked enough questions in a row?:D

Anyway, thanks a bunch for your work on this!

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

Quote:

Hey Dean, congrats on the recognition from Atmel (whys the quoted email gone now?). I finally got around to trying out the newest version of your programmer/serial bridge. It seems to work great, I'm sure its gonna be really useful in the future.

The Atmel engineer asked me to remove it as he didn't want all his details and message out in the open. It was dumb of me to simply repost it without first paraphrasing or editing it anyway.

Quote:

One thing I was wondering about though is what it does when it finishes programming. After programming, the Xmega seems to be stuck in reset and I have to unplug the usb to get it going again.

I actually noticed that yesterday morning, and fixed it in the SVN/GIT repositories. If you grab the absolute latest files and recompile, it should release the XMEGA from reset now automatically.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

hmm... well I built the newest version, but it doesn't seem to work for me. It won't read the signature or anything, acts like its connected wrong. Went back to the version from this thread and it works ok. There is a high liklihood that I'm doing something wrong, but it built so I'm not sure what.

I finally realized that since I don't need the jtag header I can just use a jumper to reset instead of unplugging each time. So its been downgraded to a minor inconvenience anyway.

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

Quote:

hmm... well I built the newest version, but it doesn't seem to work for me. It won't read the signature or anything, acts like its connected wrong. Went back to the version from this thread and it works ok. There is a high liklihood that I'm doing something wrong, but it built so I'm not sure what.

Were you building the AVRISP-MKII project, or the XPLAIN bridge project? The latter has the dual mode functionality, with the jumper to switch between them, and will work out of the box for the XPLAIN. If you just want the programmer, you will need to edit the AVRISP-MKII project makefile so that it uses "BOARD = XPLAIN" instead of "BOARD = USBKEY" and recompile.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I tried the Xplain bridge project first. After reading your post I went back and tried the isp-mkii project with the change you mentioned in your post. So far still no luck. I'm able to compile it, and program the xplain and it shows up as an avrisp-mkii, but it throws the error like its hooked up wrong if I try programming or reading the signature.

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

A dumb question - are you selecting the correct device from AVRStudio? You should select "atxmega128a1" from the device list once you've connected to the AVRISP-MKII clone, and the "programming interface" should read "PDI".

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Yup, double checked that. Like I said the hex file attached to this thread is working great, other than it doesn't reset the target.

I downloaded the 091223 version and tried building it and it didn't work for me either, so its gotta be something I'm doing wrong, but I'm not sure what since it seems to build ok, the hex just doesn't work right. I tried winavr 20090313 as well as 20100110 to see if the new winavr was the problem, I don't think so.

I think for now I'm going to see if I can get it to build in avr studio, this is the first time I've used programmers notepad so I'm probably missing something simple.

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

Whoops-a-diddly! The code was indeed broken. With PDI, two lines of the AVR are used, /RESET and the Test Access pin. To enable PDI, I need to pull /RESET low for 90nS, and then toggle the test pin 14 times within 100uS. While fixing the reset-release issue, I changed over the code to use a call to delay_ms(1), which violated the timing requirements.

It's fixed in the SVN now, but you can just change the calls to _delay_ms(1) in XPROGTarget_EnableTargetPDI() with delay_us(1) to fix it.

Sorry about the hassle!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Dean,

Could you kindly attach the latest XPlain combo .hex to your post?

Thanks.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

No problem - I've updated my original post with the latest firmware, tested on my virgin XPLAIN board.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Thanks a lot Dean!

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Great Work, now makes my XPLAIN board to be usable!
Using the hex files you posted...
But the same problems like alancarr above when trying to build the XPLAIN project out of the svn archive (updated last Friday, 28/1/2010). "It won't read the signature or anything, acts like its connected wrong"

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

Yes, you need to grab the absolute latest SVN revision, which I updated only an hour or two ago with the corrected code.

Glad you're finding it useful!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Is it still possible to use a Flip to (re)load the new HEX to the XPlain's 90USB1287 after the combo HEX has been succesfully loaded via external JTAG programmer?

I tried but the bootloader doesn't seem to get activated when the TCK pin is being grounded [as XPlain manual suggests] and USB cable reconnected.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

abcminiuser wrote:
Yes, you need to grab the absolute latest SVN revision, which I updated only an hour or two ago with the corrected code.

Yep, works :-)

Two more questions (not only to Dean ;-)
1. what about making the XPLAIN board to a "true" clone, i.e. make it possible to use it to flash/debug other boards/devices?
2. did anybody happen to get the "drum" example sources with which the XPLAIN board is shipped?

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

MBedder wrote:

I tried but the bootloader doesn't seem to get activated when the TCK pin is being grounded [as XPlain manual suggests] and USB cable reconnected.

You need to manually pull the reset pin (pin 6) of J200 to ground after powering up with TCK grounded. That's at least what I experienced and I think has been posted earlier as well.

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

That's the same as reconnecting the XPlain USB - doesn't work.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Awesome it works!! Just downloaded the newest version built it and loaded it on my Xplain. Programming works, and it resets the target!

Thanks for all your work on this Dean!

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

MBedder wrote:
That's the same as reconnecting the XPlain USB - doesn't work.
For reasons no one can explain, it isn't the same.

TCK to GND, and reconnecting USB
=> No bootloader

TCK to GND, board powered via USB, /RESET shortened to GND, and opened
=> bootloader

For lack of any real idea I blame a power glitch, power-up sequencing or the phase of the moon.

Stealing Proteus doesn't make you an engineer.

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

Nope. My both XPlain's still enumerate as an mkII if TDI is grounded or as a serial port if not - the TCK grounded + Reset pulsed low still doesn't activate the bootloader.

Could anyone read and post the XPlain's 90USB1287 fuse settings?

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Quote:

Is it still possible to use a Flip to (re)load the new HEX to the XPlain's 90USB1287 after the combo HEX has been succesfully loaded via external JTAG programmer?

By using an external hardware programmer, you've wipe the DFU bootloader. You can get it back by using your JTAG to load the DFU bootloader HEX from the Atmel website, or after compiling my open source DFU bootloader from LUFA.

Quote:

1. what about making the XPLAIN board to a "true" clone, i.e. make it possible to use it to flash/debug other boards/devices?

The XPLAINBridge code shares code with my AVRISP-MKII project (see here) with a few compile time options to remove the ISP programming support. If I added support for bit-banged SPI (I'll put that on my TODO) it would be possible to load the full firmware onto the XPLAIN and use the JTAG pins for SPI, PDI and TPI programming of other devices.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Thanks, after JTAGing :D the DFU bootloader and FLIPping your HEX everything is working fine. The DFU is accessible only after a hardware reset as others said.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

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

Hello,

I have a small problem, the Xplain working (as AVRISP-MKII) with WinXP just fine! But in Windows 7 (32-bit) does not work, there is the following error:

avrdude -p atxmega128a1 -P usb -c avrispv2 -U flash:w:test4.hex
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive

or with -B 10

avrdude -p atxmega128a1 -P usb -c avrispv2 -B 10 -U flash:w:test4.hex
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive

the original AVRISP-MKII is working fine!

Greetings

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

Hello,
Great job Dean !
It worked for me seamless !
I still didn't manage to make it work with avrdude.

I found that it's an issue on having it working on both avrdude and avrstudio

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=91244&postdays=0&postorder=asc&highlight=abcminiuser&start=20

Regards,
Daniel

Last Edited: Wed. Jul 28, 2010 - 02:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For everyone: I'm now posting builds of the firmware on my site - http://www.fourwalledcubicle.com... - for those who do not want to compile it themselves. The build on my site is currently for AVRStudio only (not avrdude) but I'll start uploading avrdude ones from this week forward also.

The latest firmware revisions are MUCH, MUCH more reliable when in serial bridge mode -- lost characters are now the exception rather than the rule, and the baud rate is configurable in the user's terminal.

dandumit: For AVRDude on Windows you need to recompile with the libUSB compat compile time option.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I built a LUFA based XMEGA programmer with AT90USB1287 and it works fine. There are some questions:

1- As I use IAR for C programming (and not gcc), the first question is about changing ÙŽAT90US1287 to other part numbers. Is it sufficient to change MCU = at90usb1287 to MCU=at90usb646(or other parts) in makefile and then recompile in AVR Studio?

2- Can AT90USB82 be used for this programmer?

3- There is an automatic update feature in Atmel AVRISPMKII for new versions of AVR Studio. Is this feature present in LUFA based MKII?

Ozhan KD
Knowledge is POWER

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

Quote:

1- As I use IAR for C programming (and not gcc), the first question is about changing ÙŽAT90US1287 to other part numbers. Is it sufficient to change MCU = at90usb1287 to MCU=at90usb646(or other parts) in makefile and then recompile in AVR Studio?

Yes, the makefile will control everything you need, as all my source code for the project adjusts as needed to suit. This also applies for the other makefile settings - just make your changes, and recompile with a "make clean" followed by a "make all".

Quote:

2- Can AT90USB82 be used for this programmer?

Technically yes, with reduced functionality. Due to the limited space available you will need to either disable ISP functionality, or disable PDI/TPI functionality via the makefile. Future revisions may be able to fit into the 8K of the AT90USB82 without this restriction.

Quote:

3- There is an automatic update feature in Atmel AVRISPMKII for new versions of AVR Studio. Is this feature present in LUFA based MKII?

No, as AVRStudio believes the USB AVR to be a real AVRISP-MKII, thus even if it was possible to do so it would be disastrous. You will need to update manually with each (roughly 2 month interval) LUFA release, or as needed from the SVN.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Thanks Dean.
Also I saw a new difference in reading VTarget(in HW Settings window). This voltage is zero for LUFA based programmer and 3.3v for Atmel MKII.

Ozhan KD
Knowledge is POWER

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

Quote:

Also I saw a new difference in reading VTarget(in HW Settings window). This voltage is zero for LUFA based programmer and 3.3v for Atmel MKII.

The ADC channel used to detect VTARGET is configured in the makefile - it default to ADC channel 2. Connect ADC2 of your AVR to your target's VCC to detect the target programming level. Note that if your board is running off a lower voltage than the target board, you'll need to add in a resistive divider and set the scale factor in the makefile accordingly.

On the USB AVRs without an inbuilt ADC, the VTARGET value will be reported as 5V at all times.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Thanks again.

Quote:
Due to the limited space available you will need to either disable ISP functionality, or disable PDI/TPI functionality via the makefile.

How can ISP functionality be disabled via the makefile for using ÙŽAT90USB82 as a PDI programmer?

Ozhan KD
Knowledge is POWER

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

Quote:

How can ISP functionality be disabled via the makefile for using ÙŽAT90USB82 as a PDI programmer?

Just change the line:

LUFA_OPTS += -D ENABLE_ISP_PROTOCOL

To:

#LUFA_OPTS += -D ENABLE_ISP_PROTOCOL

In the makefile and recompile.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I have some reports from LUFA based mkii users about corruption of at90usb162 firmware, after a few microcontroller programming. The problem is solved by reprogramming of at90usb162 (by FLIP). What can be the reason for this problem?

Ozhan KD
Knowledge is POWER

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

How do you know firmware is corrupted? What happens? What's the hardware?

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

Quote:
How do you know firmware is corrupted?

Because by roprogramming the at90usb, programmer returns to normal operation.

Ozhan KD
Knowledge is POWER

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

Hmmm. I can't think of any reasonable way that the firmware in the programmer itself could be coming corrupt, unless the bootloader's reprogramming routines were firing somehow. Do you have a procedure to replicate the issue?

Does the programmer become completely unresponsive, or does it just fail to connect to a target properly?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:

Does the programmer become completely unresponsive

I asked the programmer owner and he told about a "connection fail" (or "fail connection"?) message from AVRStudio.

Ozhan KD
Knowledge is POWER

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

@Dean ...

Could one (easily) "Trick" an UNO into acting as a ISPMKII ?
I mean the M8-USB chip could signal the correct vid/pid & act as a serial gw to the m328 , doing the programming ...

/Bingo

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

Hello...
Will this AVRISP-MKII works on xmega-a1 xplained (ie.32uc3b1256)?

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

golubev wrote:
Hello...
Will this AVRISP-MKII works on xmega-a1 xplained (ie.32uc3b1256)?

yes, LUFA already comes with a pre-configured project for the XPLAIN

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

That XPLAIN uses at90usb1287, I'm talking about XPLAIN with 32uc3b1256 as its usb controller.

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

Quote:

That XPLAIN uses at90usb1287, I'm talking about XPLAIN with 32uc3b1256 as its usb controller.

As of early this week LUFA can now run on the AVR32 UC3A0, UC3A1, UC3A3, UC3A4, UC3B0 and UC3B1 series microcontrollers, but I've still got a lot of porting work left to do - specifically, I need to fix up the bajillion endianness assumptions I've made when working with serialized structs, and I need to add the correct packing attribute where it is needed.

That means my firmware does not currently run on the new XPLAIN-A1 board, but it's not too far off.

Quote:

I asked the programmer owner and he told about a "connection fail" (or "fail connection"?) message from AVRStudio.

Hmm, I can't see how that could affect the firmware - if the programming window pops up, then the firmware is alive enough to perform USB and V2 protocol processing duties, so it can't be too dead. Reloading the firmware via an external programmer would reset the EEPROM and thus the reset line polarity parameter, but that's not done when reprogramming through FLIP.

- Dean :twisted:

EDIT: Hmm, that begs the question, where's the AVR32 UC3A2?

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Thanks for the light, can't wait to see it running on the new xplain-a1 :)

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

abcminiuser wrote:
if the programming window pops up, then the firmware is alive enough to perform USB and V2 protocol processing duties, so it can't be too dead.

Is it possible that AVRStudio do this to Non-atmel programmers after a few chip programming?

Ozhan KD
Knowledge is POWER

Pages