Get Your Open Source XPLAIN/XMEGA Programmer Here!

Last post
122 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Freaks,

I've just completed what appears to be a working first revision of a programming firmware for the XPLAIN board, loadable via FLIP into the onboard AT90USB1287. When loaded, it will cause the USB AVR to enumerate as a AVRISP-MKII which (with the latest AVRStudio release) can then program the board's XMEGA via its PDI interface.

I've attached the first build of the programmer firmware here. All those with XPLAIN boards gathering dust because you don't have an external programmer - this is for you! All I ask is for some feedback; post here if the firmware works (or doesn't work) for you.

For those interested in a generic open source XMEGA programmer, the source code for this is located in my LUFA project public SVN at http://code.google.com/p/lufa-lib/, under the Projects/AVRISP/ folder.

A very, very, very big special thanks to Justin Mattair for his help with the PDI protocol, and to Ross McKenzie for loaning me his XPLAIN board for development.

Note that Rev 1 XPLAIN boards have a faulty bootloader in the USB AVR, and cannot be flashed with this firmware without an external JTAG programmer.

EDIT: Latest build and source is now available from my site: http://www.fourwalledcubicle.com/XPLAIN.php

EDIT: I've posted a short guide to loading and using the firmware on my blog: http://fourwalledcubicle.com/blog/archives/508

- Dean :twisted:

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

Last Edited: Sun. Jul 18, 2010 - 05:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good job, Dean.

Guillem.
"Common sense is the least common of the senses" Anonymous.

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

Once again, Dean, you have outdone yourself!

Nice Job!

JC

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

If they offered you a job in Finland, would you move up there?

Imagecraft compiler user

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

bobgardner wrote:
If they offered you a job in Finland, would you move up there?
What should he do in Finland? Lurking over the border into north Norway, around the corner and around Sweden, to figure out what the Atmel guys are doing at almost the other end of Norway?

Stealing Proteus doesn't make you an engineer.

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

So do we still keep the bridge functionality?
How do we switch from programmer to bridge?
If you haven't fininshed a full manual, why not? :wink:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Nice Dean.

Does one have to check out via SVN 0r is there an uptodate Zip

Well i used SVN :-)

Is there a special "Board ID" for the Xplain board in the makefile ?

/Bingo

Last Edited: Tue. Dec 15, 2009 - 07:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finskis, Norskis, Swedskis, they're all furriners to us good ol boys. I never was too good with geography.

Imagecraft compiler user

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

avrdude 5.8 (with PDI patch, but that shouldn't matter here):

$ dfu-programmer at90usb1287 erase --suppress-bootloader-mem
$ dfu-programmer at90usb1287 flash --suppress-bootloader-mem  XPLAIN\ Programmer\ R1.hex
Validating...
6288 bytes used (5.12%)
$ lsusb | grep Atmel
Bus 001 Device 011: ID 03eb:2104 Atmel Corp. AVR ISP mkII
$ avrdude -p atxmega128a1 -c avrispmkII -P usb -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.30s

avrdude: Device signature = 0x1e974c
avrdude>  dump flash 0 256
>>> dump flash 0 256 
0000  0c 94 fa 00 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0010  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0020  0c 94 1c 01 0c 94 1c 01  0c 94 d7 06 0c 94 1c 01  | ... ... ... ...|
0030  0c 94 1c 01 0c 94 1c 01  0c 94 24 06 0c 94 1c 01  | ... ... .$. ...|
0040  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0050  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0060  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0070  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0080  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0090  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00a0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00b0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00c0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00d0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00e0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00f0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|

avrdude> quit
>>> quit 

avrdude: safemode: Fuses OK

avrdude done.  Thank you.
$

Reading just the first 256 bytes of the flash takes, however, 25 seconds. 25 s / 256 bytes ~= 100 ms/byte

I didn't try programming.

Stealing Proteus doesn't make you an engineer.

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

Thanks all!

Quote:

If they offered you a job in Finland, would you move up there?

Every time I hear "Finland", I always think of that Monty Python song. If Atmel were ever to offer me a job, I think the bits wouldn't have time to travel to my inbox before I would already be on a plane over there.

Quote:
So do we still keep the bridge functionality?
How do we switch from programmer to bridge?
If you haven't fininshed a full manual, why not? Wink

Programmer only for now. Once it's shown to work, I'll make a special dual version which can act as a programmer or a bridge, depending on a jumper (or similar switching method). I'd be able to do both at the same time, except the Atmel drivers won't bind to a compound device.

Quote:

Does one have to check out via SVN 0r is there an uptodate Zip

Well i used SVN Smile

Is there a special "Board ID" for the Xplain board in the makefile ?

Yes, SVN only for now, until the next release (which will be as soon as I can confirm this working for the unwashed masses). When compling, specify "BOARD = XPLAIN" in the makefile and it'll do the rest to ensure it will work on the board.

Quote:

Reading just the first 256 bytes of the flash takes, however, 25 seconds. 25 s / 256 bytes ~= 100 ms/byte

I didn't try programming.

That's ridiculous - something's wrong there with how AVRDude is sending the bytes; I'll go check it out. Under AVRStudio, my code is currently faster than the Atmel JTAG, by virtue of it's 1MHz bus since it's located so close to the target chip physically. Writing the QTouch app takes less than a second, and full 256KB readback takes only 5 seconds or so. I'll go see what's what.

- Dean :twisted:

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

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

ArnoldB, where did you get your AVRDude build (and patch), and what OS are you using? The latest AVRDude in WinAVR doesn't work under Windows for me, as it doesn't want to work with the USB port. Under Ubuntu, I get a faulty (0x00) readback on almost every read. Since yours apparently works (and since the code works with AVRStudio), I'm thinking I need to get a later avrdude version.

- Dean :twisted:

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

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

Yep, AVRDude's jiggered - no idea how you got yours working ArnoldB. I compiled from the latest source and ran some tests - AVRDude is trying to read the wrong addresses (it reads address 0x02000090UL for the signature, instead of 0x01000090UL, for example). If I force it to continue, I see the same crazily slow read speed you do when reading out normal bytes.

I think I might see if I can figure out the avrdude code, and make my own patch.

EDIT: Darn. After fixing it myself in the source, I then through to seek out ArnoldB's mentioned patch, and found it at http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=645370. Using that and the slightly updated version attached here, it all works great now.

EDIT 2: Removed updated build - see original post for latest version.

- Dean :twisted:

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

Last Edited: Tue. Jan 5, 2010 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first revision of the Xplain board was a composite device with a dual CDC class so both programmer and serial interface was available at the same time.

This can be achieved by using the association descriptors in the USB which will wrap each of the CDC in it's own class. However, Windows XP SP2 do not have drivers that support this without manually updating the usbser.sys and another .sys file. Updates available at microsoft.com. The SP3 do however include this so it will work without any magic updates.

Dean can probably make this work without any jumpers or such and use the driver (.inf) file for the rev1 of the Xplain. It's in the zip-file for the Xplain at www.atmel.com/xplain.

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

SuperAVRMan,

The Atmel firmware apparently uses a CDC interface for the programming; what host side application is Atmel using to program the XPLAIN? That method won't work here as my version clones a full AVRISP-MKII (including the V2 protocol and ISP/PDI programming modes) which can't be part of a composite device.

Also, if Atmel has a semi-complete version already made, why isn't it in general use?

- Dean :twisted:

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

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

I am using Ubuntu 9.04, an avrdude 5.8 compiled from original source with the PDI patch.

With the R2 version it still takes 25 seconds for dumping the first 256 bytes of flash. And avrdude crashes on a second attempt:

$ avrdude -p atxmega128a1 -c avrispmkII -P usb -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.30s

avrdude: Device signature = 0x1e974c
avrdude> dump flash 0 256
>>> dump flash 0 256 
0000  0c 94 fa 00 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0010  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0020  0c 94 1c 01 0c 94 1c 01  0c 94 d7 06 0c 94 1c 01  | ... ... ... ...|
0030  0c 94 1c 01 0c 94 1c 01  0c 94 24 06 0c 94 1c 01  | ... ... .$. ...|
0040  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0050  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0060  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0070  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0080  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
0090  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00a0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00b0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00c0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00d0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00e0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|
00f0  0c 94 1c 01 0c 94 1c 01  0c 94 1c 01 0c 94 1c 01  | ... ... ... ...|

avrdude> dump flash 0 256
>>> dump flash 0 256 
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = No error
avrdude: stk500_send_mk2(): failed to send command to serial port
$

The USB interface is still there, and when starting avrdude again I can again read the flash (at the low rate).

So the crash must be something inside avrdude.

Stealing Proteus doesn't make you an engineer.

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

Congratulations Dean.

You are a pretty smart guy and I am sure Atmel with consider you in their future plans (Better they do it soon or they will lose the opportunity).

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

Quote:

I am using Ubuntu 9.04, an avrdude 5.8 compiled from original source with the PDI patch.

With the R2 version it still takes 25 seconds for dumping the first 256 bytes of flash. And avrdude crashes on a second attempt:

Try using non terminal mode -- that's what I tested with and what appears to work great (with the patched version). Try this:

$ avrdude -p atxmega128a1 -c avrispmkII -P usb -U flash:r:FIRMWARE.hex

- Dean :twisted:

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

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

Hallo,

thanks to Dean for his great work! I've just downloaded the newest LUFA and tried to get the Xplain bridge to work. I could build the project for the 1287 with no errors in Studio 4.18 Build 692

Program: 4190 bytes (3.2% Full)
(.text + .data + .bootloader)

Data: 307 bytes (3.7% Full)
(.data + .bss + .noinit)

Flip succeeded in programming and Windows XP SP3 shows a 'LUFA XPLAIN Bridge' I set the driver to the 'LUFA XPLAIN Bridge.inf' file and get a 'communications port'

But the AVRstudio is not able to connect to an AVRISP mkII using an USB connection.

Does anybody know where the fault is?

Thanks and greetings from Germany

Eumel

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

Eumel,

The XPLAINBridge code is for making a USB to Serial bridge between the XMEGA and the host for communications -- but not for programming. To be able to make the XPLAIN board appear as a AVRISP-MKII for programming of the XMEGA, you'll instead need to compile and flash the "AVRISP" project in LUFA, compiled for the 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

Thank you very much Dean!

Merry Christmas to you and your family.

Greetings from the cold (and a little bit snowy) north west Germany
Einhart

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

Now it works! I'm able to read the Xmegas signature.

Again, thank you Dean. LUFA is the best project I've seen so far - perfect working and well documented code.

Greetings

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

Great to hear! I'm glad I was able to release the code before Christmas -- that way it becomes my present to fellow 'freaks, so I don't have to buy 40,000 individual ones ;).

When compiled for the XPLAIN board it will automatically switch over to using the hardware USART for programming rather than the slower bit-banged USART, so it should be pretty darn fast (1MHz bus). I was able to program and read back the entire 256KB of memory in only a few seconds.

- 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, and Merry Christmas to you, Santa! :P :P :P

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

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

Now my Xplain is useful! This combination is always working, of the patched avrdude and the LUFA AVRISP build for XPLAIN (my host is mint7). Dean your efforts make a difference, thank you very much.

There is a delay sometimes when programming starts, and an error message is emitted. It goes on to work fine anyway. This is the message "avrdude: stk500v2_recv_mk2: error in USB receive".

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

Glad you appreciate it teachop -- it's always great to hear feedback from my work. You can help by further spreading the word; I'm sure there's still some XPLAIN users despairing because they don't realize that my programmer firmware exists.

As for the AVRDude error, I'll have to investigate. Cheers!

- Dean :twisted:

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

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

Avrdude 5.8 as a whole is a little bit touchy. I see all kinds of USB errors from time to time with different programmers. There are even some reports that ISP with the Dragon crashes the program.

Stealing Proteus doesn't make you an engineer.

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

Hi Dean,

thank you very much for this fantastic job, now I can use my Xplain Board :-) .
I have two questions, when I send a program to the Board the program starts to run when I make a Power OFF Power ON, is normal? is something like the reset if not release from LUFA.

When I open AVRStudio and connect the Board , AVRStudio always asks if I want to do a firmware! I always reply that not because I fear that after something does not work.

With XPlain I use AVRStudio, but usually I use WinAVR with Avrdude (Note Pad), the Pach of Avrdude 5.8 is only for linux?

Thank you very much!

Martin

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

Quote:

thank you very much for this fantastic job, now I can use my Xplain Board Smile .
I have two questions, when I send a program to the Board the program starts to run when I make a Power OFF Power ON, is normal? is something like the reset if not release from LUFA.

I'm not exactly certain what you think is wrong here. In theory, the programmed application should run at all times, unless you have a programming session open. Are you saying that your target is not running unless you power-cycle the board?

Quote:

When I open AVRStudio and connect the Board , AVRStudio always asks if I want to do a firmware! I always reply that not because I fear that after something does not work.

This and the above seems to indicate that you are using the old build from this thread, rather than the updated source code from the LUFA package. I'm going to update my original post with the latest build which should fix both issues. The device will automatically reject firmware updates if requested from AVRStudio, so you can't break anything if you accidentally click yes to that dialogue in the future.

Quote:

With XPlain I use AVRStudio, but usually I use WinAVR with Avrdude (Note Pad), the Pach of Avrdude 5.8 is only for linux?

The patch is for both Windows and Linux, although you'll have to find someone kind enough and smart enough to compile it for you. I can compile it for Linux, but I don't know how to cross-compile it for Windows.

- Dean :twisted:

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

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

Great work Dean! Haven't tested it yet, but I will. Thanks :-)

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

Hallo Dean,
thanks for your answer!
sorry, my English is not perfect, unfortunately!

>> Are you saying that your target is not running unless you power-cycle the board?

Yes, I have to first remove the USB cable and then if you run the program.

Martin

Last Edited: Tue. Jan 5, 2010 - 01:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try the new build in the first post of this thread -- in the earlier builds I had posted I neglected to clear the XMEGA RESET PDI register when exiting programming mode, holding the target in indefinite reset. That (and the upgrade dialogue) should now be fixed.

- Dean :twisted:

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

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

PERFECT !!
with the new firmware working throughout perfect
thank you very much

Martin

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

Fantastic! Here's hoping you're now able to create many fascinating XPLAIN projects :).

- Dean :twisted:

(PS: You can donate on my website at http://www.fourwalledcubicle.com if you feel it's worth anything ;))

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

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

Good job Dean thank you very much...
Davide

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

Hmmm, I always get a verification error on byte 0x0213 or 0x0214 with the new version.

Using JTAG I can program the same xplain board without problems.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.30s

avrdude: Device signature = 0x1e974c
avrdude: reading input file "blink.hex"
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: writing flash (740 bytes):

Writing | ################################################## | 100% 0.04s

avrdude: 740 bytes of flash written
avrdude: verifying flash memory against blink.hex:
avrdude: load data flash data from input file blink.hex:
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: input file blink.hex contains 740 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0213
         0xee != 0xec
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Stealing Proteus doesn't make you an engineer.

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

Arnold,

Are you using a patched version of AVRDude? The current unpatched avrdude has some bugs in it, which prevent the AVRISP MKII from working correctly in PDI mode -- and my firmware uses the same code paths.

If you are, can you send me your test file please? I'd like to test it on my own board, but I suspect it will just be a case of the programming bus being too fast (1MHz).

- Dean :twisted:

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

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

Of course I use a patched avrdude.

I have attached the highly sophisticated source code and the hex file that cause the error.

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.30s

avrdude: Device signature = 0x1e974c
avrdude: reading input file "blink.hex"
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: writing flash (630 bytes):

Writing | ################################################## | 100% 0.04s

avrdude: 630 bytes of flash written
avrdude: verifying flash memory against blink.hex:
avrdude: load data flash data from input file blink.hex:
avrdude: input file blink.hex auto detected as Intel Hex
avrdude: input file blink.hex contains 630 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0213
         0xe7 != 0xe1
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Stealing Proteus doesn't make you an engineer.

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

Tested working on my XPLAIN board under Windows (AVRStudio4) and Linux (patched avrdude). Try the attached build - I've halved the transfer speed to 500KHz to try to make it more reliable.

- Dean :twisted:

Attachment(s): 

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

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

blink.hex now works, but the program I use here http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=653873#653873 fails with

avrdude: verification error, first mismatch at byte 0x0212
         0xee != 0xe6

Stealing Proteus doesn't make you an engineer.

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

Hmm. Well, at least it's been narrowed down to a clock frequency problem (I think). I've attached yet another build with a 100KHz clock.

It seems rather odd that my board is rock-solid at 1MHz, but yours is unstable at 500KHz; is there normally this much variation between board tolerances?

- Dean :twisted:

Attachment(s): 

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

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

With that version now both the blink and the dfll program show verification errors.

blink:

avrdude: verification error, first mismatch at byte 0x0213
         0xe7 != 0xe1

dfll:

avrdude: verification error, first mismatch at byte 0x0212
         0xee != 0xe6

Comparing the values in binary

1110 0111 (wanted)
1110 0001 (found)

and

1110 1110 (wanted)
1110 0110 (found)

shows two things:

1. It is always the lower nibble being wrong
2. It is always that 1s are written as 0s:

And

3. It is always around 0x213

I went back to the previous error messages, and it is the same there. Always the lower nibble wrong, always 1s changed to 0s.

Maybe it is time to call it a hardware error, or power supply error or whatnot. However, I should mention that I can program the same xmega on the board with JTAG without problems.

BTW, I still use the original rev 4 bootloader in the at90usb1287 on the board.

Stealing Proteus doesn't make you an engineer.

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

Well I'm thoroughly confused; the transmission system is serial USART, so it's not like a line could be stuck somewhere -- it's either not going to be able to do anything at all, or it's going to work. Lots of others seems to have got it working (myself included) which doesn't leave much else to chance.

Could you please try programming with AVRStudio, and NOT AVRDude? If that still gives verification errors, I'll be both very confused and grumpy as it doesn't leave much else to check. The one thing I can think of is AVRDude not setting the correct erase/page bits in the programming packets, but on my patched AVRDude it seems to work just fine.

When my non-loaner XPLAIN gets here, I'll have to check it on that also.

The bootloader won't have anything to do with the failure to program the XMEGA - something else is afoot.

- Dean :twisted:

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

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

So i tried it on Windows with Studio 4.18 SP1. Out of ten tries nine worked, one failed at 212. As opposite to Linux where 10/10 fail.

Next week I'll get another Xplain board. I'll try with that one again.

Stealing Proteus doesn't make you an engineer.

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

HOLY CRAP.

Quote:
{REMOVED}

- Dean :twisted:

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

Last Edited: Wed. Jan 27, 2010 - 09:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulation Dean, you're well deserved it.

Vince

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

Start buying lots of winter clothes then :D :D :D

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

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

abcminiuser wrote:
HOLY CRAP.

< Quote removed (on demand) by Plons >

Hey Dean

Get them to ship an Xplain board also , the Ross can have his back :-)

Congrats .... You have been "Discovered"

/Bingo

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

Holy crap! indeed.

(the mercenary in me says "do you really need an AVR One! - how much could you get for it on ebay?" ;-))

Perhaps you can now confirm the myth that users of the One! have a gentle aura of gold glow around them?

 

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

Fantastic!

Finally they noticed your good work, Dean. Maybe you can be the missing link between Atmel and good C-libraries.

I think when you finish your study, they will (and should) offer you a good job.

Congratulations from Germany

Einhart

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

NICE!!!

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

you must tell me how they are.
i would buy one if my budget whas enough (110€) and if they had avr8bit(comming wath i now) support. :(

  • 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

http://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/XPLAIN.php - 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

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

Quote:

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

Studio 4, or Studio 5? If the former, I've been using Tom's programmer loaded with my code for quite a while under Studio 4, with no issues at all.

- Dean :twisted:

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

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

I guess this is the best place to post the issue, other than support group for LUFA.

I have an issue with Xplain Bridge on windows 7 32 Bit(Enterprise).

when i try to load driver file(.inf) it just doesnt works.

i made Xplain work as MKII so i think is not really my hardware.

anyone have any suggestions to solve this?

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

Are you using the .INF file located on my website? If so, are you running in Serial Bridge mode, or AVRISP-MKII mode?

If the former, give Windows the INF from my site. If the latter, you need to give Windows the location of the Atmel AVRISP-MKII drivers, which ship along with AVRStudio.

- Dean :twisted:

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

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

does LUFA work for new Xplained board(shiped with at32uc3b1256) now?

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

The LUFA core is ported, but that project is not. I've been busy with a few other things lately, but given the large amount of interest perhaps I should re-prioritize.

The big changes would be writing an appropriate UART and SPI driver for the AVR32s, and fixing up the endianness issues in the demo.

- 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:
The LUFA core is ported, but that project is not. I've been busy with a few other things lately, but given the large amount of interest perhaps I should re-prioritize.

The big changes would be writing an appropriate UART and SPI driver for the AVR32s, and fixing up the endianness issues in the demo.

- Dean :twisted:

nice guy!!

i'm new to avr32, in my xplainED board, i can switch AVR32 into bootloader mode via the jumper. And I can use dfu-programmer access the AVR32 chip, so I think I can re-program it. The question is, if I upload a hello world program into, will the DFU bootloader(on AVR32) be broken?

If the operation is safe, I also want join your LUFA proj to let xplained broad works well under Linux.

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

Quote:

The question is, if I upload a hello world program into, will the DFU bootloader(on AVR32) be broken?

The serial bootloader in the XPLAINED boards is why I haven't put in the effort before now to port the bridge firmware in LUFA; you can already do both debugging and programming through the existing board controller.

Yes, you can reprogram the AVR32 through the bootloader without damaging the bootloader; that's the point. Reprogramming with an external programmer such as a Dragon or JTAG will erase the bootloader however.

- Dean :twisted:

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

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


you can already do both debugging and programming through the existing board controller.

No, i can't do it under LinuX, even i can't import the device into my virtualbox(which m$ windows there)

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

you can follow this link:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=862569

====
if re-programming AVR32 via bootloader is safe, i'll try some testing code

Thank you!

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

Quote:

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

Try opening the port with a standard serial terminal program such as PuTTY - that should set the baud rate (while directly cat'ing to /dev/ttyACM0 won't). The device firmware may time out unless the port settings are indicated beforehand.

- 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:
Quote:

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

Try opening the port with a standard serial terminal program such as PuTTY - that should set the baud rate (while directly cat'ing to /dev/ttyACM0 won't). The device firmware may time out unless the port settings are indicated beforehand.

- Dean :twisted:

I used a lots of tools, like cutecom/ minicom or access the /dev/ttyACM0 by python serial port, the result is the same.

you tried the Xpalined under Linux?

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

Hi all, Dean, does the AT32UC3B1256 works now ? I also have an xplain with that chip and I want to start with programing the 128A1.
If I am not wrong, then I might have rev #9 board.

on your page there I can only see at90USB1287 support.

Pls redirect me to the right direction ... or so. ;)

thanks
D

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

No, unfortunately I never did finish the port, although I don't think it would take more than a week's effort with the latest release. That said, I don't think the programming pins are routed to the UC3B on those boards, so porting might not be much use. If I remember correctly, the XPLAIN boards with the UC3B board controller all have a serial bootloader loaded in from the factory that you can use with FLIP from the command line.

- Dean :twisted:

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

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

Hi Dean, Thanks for your reply.

My problem with that board is, that I damaged somehow the BL from the BC so I cannot use the UC3B anymore without reprogramming. But it is still showing as DFU device in windows (any only DFU not the CDC or similar) so my last hope was to receive from Atmel the original BL for the BC or an alternate LUFA ;)

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

You can grab the original board controller firmware for the boards in AS6: start a new example project, and search for "board controller".

- Dean :twisted:

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

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

really, cool !!!
that sounds interessting. what is the exact precedure to get the BL on the BC without destroying it completely ?
I only can use batchisp.
do you know the exact comment for batchisp ?
batchisp -device at32uc3b1256 -hardware usb -operation
??

Thank you so much dean ;)

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

You can't break the chip with FLIP (or BATCHISP) unless you load in a bad program that exploits the hardware to cause physical damage, so don't stress.

batchisp -hardware usb -device at32uc3b1256 -operation erase f loadbuffer BoardControllerFirmware.hex program

batchisp -hardware usb -device at32uc3b1256 -operation start reset 0

- Dean :twisted:

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

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

Quote:

unless you load in a bad program that exploits the hardware to cause physical damage

So avoid using the HCF opcode!

 

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

gentleman, all working now, thanks for your great support !!! what I did so far:

1. create new "USB Device CDC Example - Board Controller"
2. compile
3. batchisp -hardware usb -device at32uc3b1256 -operation erase f loadbuffer DEVICE_EXAMPLE2.hex program

batchisp -hardware usb -device at32uc3b1256 -operation start reset 0

now we should have back the CDC as I have :)

now I am open for the NEXT problems :)
(I am trying to get the 24 PWM's working... )

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

There is a strange problem with my LUFA based mkii. When connected to usb connectors in the back side of PC, everything is ok. But by connecting the usb cable to the connectors in the front side of PC, the at90usb162 warms up very quickly! I have tested this case with more than one programmer and 2 PCs.
Another question: there are 3 LEDs connected to PD5,PD6 and PD7. What are the exact function of these LEDs?

Ozhan KD
Knowledge is POWER

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

Well that's strange, do you have the exact schematic for your programmer? I suppose there could be a voltage difference in the bus between the back and front ports, which might upset the internal regulator in the USB AVR.

EDIT: The LED functionality depends on what modifications were made to my code. Stock there's a bicolor LED to indicate activity, and a red LED to indicate if the target is being powered from the programmer.

- Dean :twisted:

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

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

By putting a 5.6v zener diode and 10uF capacitor on 5v line, the problem disappeared.
And about LEDs: Single (red) led which indicates power connection, blinks during programming. So I omitted the bicolor led and it seems the single led is sufficient for programming indication.

Ozhan KD
Knowledge is POWER