Get Your Open Source XPLAIN/XMEGA Programmer Here!

Last post
122 posts / 0 new

Pages

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!

  • 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

  • 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!

  • 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

  • 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!

  • 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. :(

Pages