Xplain USART bridge code. [solved]

Go To Last Post
101 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I zapped the 1287 with the 1287 firmware provided with the Xplain docs using the Dragon, but it seesm to be just the bootloader code so the existinng application for the USART bridge has now disappeared.

Where do I find it? Looked around the Atmel site but could not find any info.

I should be able to program it back in using FLIP, correct?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Nov 25, 2009 - 08:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey what revision hardware do you have? Mine is revision 1 and I modded the hardware to get the xmega bootloader working through the USB port.

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

How does the 1287 interface with the XMEGA? I could modify my LUFA USBtoSerial demo in a few minutes to solve that problem everyone's been having with the board...

- Dean :twisted:

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

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

Dean,

The Xplain uses a soft UART in the 1287 to interface to the xmega.

I wrote a suitable soft UART and adapted the LUFA code. But then ran into problems with Windows... ? and generally got fed up and gave up.

The Xplain board obviously comes with a 1287 application that provides the CDC comms to the PC for the xmega UART. It is also supposed to interface to a xmega bootloader as the communication device.

Read the Xplain app note for a better explanation.

The 1287 DFU bootloader is available on the Atmel website. But if you install this, you lose the magic 1287 app that provides the UART bridge. An of course there is no replacement binary for the 1287 app on the Atmel website.

I have asked a couple of times for someone to READ the 1287 app into a hexfile, so that you can re-install. But no-one has chosen to oblige. I presume that they have all done the same as John and me. --- installed the DFU and erased the chip in the process.

The idea behind a single board which can just connect to a PC via one USB cable is brilliant. BUT ONLY IF IT WORKS. You can investigate most of the xmega features with the Xplain and it would be an excellent evaluation tool.

However if you compare this with evaluation boards from other manufacturers, it falls far behind. However good the xmega is, it can hardly compete with the available silicon + functional devkits from other vendors.

David.

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

Quote:
How does the 1287 interface with the XMEGA?

The XMega connects to PD0(XMega TX) and PD1(XMega RX) of the 1287 chip. I'm sure a software uart should be possible. I don't seem to remember a com port being discovered by the pc with the old firmware though. The USB may have been designed as a debug port as the pdi port is connected to the 1287 too.

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

Dean, I was thinking of using LUFA for a replacement but it may all be well beyond me... :) If you are preared to mess around with it I'll try...nothing more to lose!

Reading the 1287 would be ok IF the chip is not locked.

Anyway I only zapped the code because I was under the false understanding that the code provided was the entire code and not just the bootloader. Yep, the old ASS_U_ME.

Atmel should supply the code, surely it is not top secret, well maybe they think that someone will make a few bucks by using a 1287 as a PDI progammer??

The board is version 2 by the way.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I've replaced the hardware uart with an asm software uart i wrote last night in the CDC example that is on the atmel website. The xmega bootloader also available on the atmel website is working fine with the AVROSP utility.
I'll upload the code when i've tidied it up.
If anyone wants the binaries in the meantime.....

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

Quote:
I've replaced the hardware uart with an asm software uart
I'm confused, there is no hardware uart from the 1287 to the Xmega, just a bit banged version.

The harware USART1 is used for PDI programming by the looks of things.

Quote:
The xmega bootloader
You mean there WAS one in the Xplain's Xmega chip? :lol: that would have been obliterated within the first few minutes after I got the board and proceeded to plug in the Dragon with it's new found powers.

All I need is basically a USB to TTL converter out of the 1287, nothing else for now. There is some USART code already available that works with USARTC0 in CVAVR. (of coure I have plenty of RS232 to TTL boards around if I need to use other USARTs)

Anyway I have posted a ticket for the above with Atmel.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I don't know if any of you still need it, but attached is a hex file read from the 1287 on my Xplain board.

Attachment(s): 

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

Alan that seems to be the whole chip, application and bootloader, correct?

Is that for a version 1 or version 2 board? The bootloader section seems different than the one supplied with AVR1907 for version 2 board.

I'll give it a try anyway.

oops goofed, there is no [bootloader programmed in the] 1287 in version 1 board it seems. :oops:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sat. Nov 21, 2009 - 05:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have lift off!! Com 50 comes back on when I plug in the USB lead. Bootloader seems OK too as FLIP can see it if I power up with the bootloader jumper in place.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

And to round things off this is the (messed up) USART bridge at work. I have used the CVAVR code for the STK600 as the Xmega USART C0 is already prewired to the 1287 bridge.

Also used PDI for "debugging" ie single stepping through the code. Who knows where the problem lies, most likely with the bridge and soft UART??

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sorry, I think some wires got crossed with software/hardware on my previous post. Also forgot to attach the binarys to it!!

I've got this working reliably if you want to try it out. It basically provides a 9600 baud serial bridge out of the 1287 to the xmega chip USARTC0.

The bootloader application for the xmega is also in there too.

Attachment(s): 

Last Edited: Tue. Nov 24, 2009 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 1287 Bridge hex file successfully installs a COM port.

It then repeatedly sends "Select Pressed !" to the Terminal.
You can get your xmega application to send text out through this "port" but is a little unreadable since the screen fills completely with the "Select Pressed !" text.

Since the 1287 has no user accessible pins, how can you stop this?

Incidentally the Atmel 1287 HEX file posted a few days ago provides a 9600baud soft UART but it loses characters like they are going out of fashion.

It looks as if this soft UART is more robust. But I suspect that you have to pull a 1287 pin high or low for this "text" to stop.

Has anyone got this working?

David.

Edit. I think that I have found the problem. I was using the DataFlash on the Xplain board. I suspect that the 1287 bridge code is reading the SS pin. (which is of course being used by when you access the DataFlash)

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

At the risk of offence, most likely to Dean after unashamedly hijacking his fantastic USBtoSerial demo for his LUFA project (sorry). Here is the source for anyone who is interested.

Think the makefile could do with some attention as I've never used them before!

Cheers.

John.

Attachment(s): 

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

Of course it would be nice if Atmel addressed this problem, I put in a ticket but nothing more than an automated response so far.

I'm getting into the hacking mood to disconnect the 1287 from the Xmega, remove the 2 resistors from the USART1 pins and use that for the bridge as I don't really care about possible PDI programming via the 1287. In fact there is no need to cut tracks as the pins now used for soft uart can just be made inputs.

But I'll need to come to grips with Dean's LUFA (or whatever the new name is) code I guess. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

At the risk of offence, most likely to Dean after unashamedly hijacking his fantastic USBtoSerial demo for his LUFA project (sorry). Here is the source for anyone who is interested.

Think the makefile could do with some attention as I've never used them before!

Cheers.

John.

John,

That codes based off MyUSB 1.5.3, which is at *least* a year old. Do you mind if I convert it over to the latest LUFA framework? Also, can I have your permission to use your soft USART code in the code, which will be used as an official LUFA project?

- 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:
- Dean :twisted:
ahh, look who has new "sunnies" ...

Ross McKenzie ValuSoft Melbourne Australia

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

Ohh THAT John...

Anyway I think you should make the program flexible enough so that either a soft USART code or the real USART1 could be used... with a little hack, with a little hack

oh that's a Beatle's song.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Well, I'm still pending John's approval for his code (yes, it's MIT licensed, but I'd rather have explicit permission when I can) but I've managed to knock up a first revision:

http://code.google.com/p/lufa-li...

See how much better it all is with the new framework? :D

I haven't got a XPLAIN board yet to test it with, but it should be functionally identical to John's version based on the ancient MyUSB distribution.

John - I really need to dig up the schematics. Are you saying that the XMEGA's USART is connected to USART1 of the AT90USB1287? If so, I might as well remove the software USART and switch over to hardware.

- Dean :twisted:

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

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

Quote:
Are you saying that the XMEGA's USART is connected to USART1
No, the XMEGA's USART1 is used for "future"?? PDI programming, but I'm thinking of hacking the board. There are 2 resistors that can be removed to free up USART1, all that is then required is to connect the USART1 pins to USARTC0 in the XMEGA.

The pins currently used for soft uart can just be left connected as long as they are inputs in the 1287.

edit I can't see the .hex file for the bridge, I can try it if you get it compiled.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hmm, I've been meaning to add PDI support to my AVRISP programmer project, since the official AVRISP-MKII now supports it. If I get that going, I could extend the bridge to allow for PDI programming also. It would be ironic if I manage to get it all up and running before Atmel does...

Nothing EVER works the first time in these sorts of things, but I've attached the build of the first version here for you to try.

- 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

OK so where do I get the drivers now for LUFA? I have programmed the new code into the chip but windows want to know where the drivers are located. :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Whoops! Sorry! The firmware actually uses Windows' own CDC drivers, but you need a special INF file in order for it to use them. Point the driver wizard to the attached file once you've renamed the extention to .INF.

- 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

SUCCESS!! I'll try it now with another Xmega program see how it beHaves.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You can receive and send data?!

That's GOT to be a first. Granted, all the components have been tested individually, but for something to work first time is nothing short of a miracle.

Also, the LUFA bridge implements proper buffering and whatnot, and so should be as suceptable to lost characters as the official code apparently is.

- Dean :twisted:

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

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

From the looks of the avatar above it would appear the space aliens have snatched Dean and replaced him with someone else. It also happened to my daughter as a senior in high school.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

FANTASTIC!!! Congratulations Dean and John, much better than the original Atmel bridge.

This one does NOT drop any characters unlike the original whose screen shot I posted in the 1st page, even with the much hated Hyperterminal :lol:

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Change and use away, glad it is of some use!

I did notice a bit of a silly in the uart_init routine where there is an atomic section that needs to include the read of TCNT3H and TCNT3L. It may cause a problem (sometimes!).


	// grab timer value

	lds		r18,TCNT3L
	lds		r19,TCNT3H

	// drop down tx line for start bit
	lds		r20, PORTD
	andi		r20,0xFD
	sts		PORTD,r20
	
	// set trigger for tx timer
	cli
	sts		OCR3BH,r19
	sts		OCR3BL,r18
	sei

should be


	// grab timer value
	cli
	lds		r18,TCNT3L
	lds		r19,TCNT3H

	// drop down tx line for start bit
	lds		r20, PORTD
	andi		r20,0xFD
	sts		PORTD,r20
	
	// set trigger for tx timer
	sts		OCR3BH,r19
	sts		OCR3BL,r18
	sei

No the xmega's usartC0 is connected to pins PORTD pin0 and pin1 which does not correspond with the hardware uart... which would have made things a lot simpler!!

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

Just to wrap this up, Atmel just send me the Xplain USART bridge code and programmed it into the board.

It suffers from character drop out like what is visible in the earlier screen shot posted.

So I have gone back to Dean\John's code for the USART bridge.

So far I only have tested one way, when I get a bit of time I'll try sending and receiving unless someone beats me to it. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Sorry if this is tangential, but I'm having a hard time getting started with my XPLAIN. From the schematic it looks like the 1287 could be programmed (via FLIP?) to be a PDI programmer for the XMEGA, (e.g. AVRISP emulator?). Is this related at all to the LUFA and/or UART bridge you're discussing?

Out in the boonies,
-Mike

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

It could work but the software implementation was never there from Atmel. The uart bridge being discussed is to purely provide a USB to Uart connection and nothing more. I have sucessfully used a bootloader in the xmega this way but debug is not possible yet. If you have a dragon or an JTAG ICE II you can directly connect it for debug.

Dean has mentioned a pdi possibility with the LUFA project.

John.

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

I now have a simple echo program running on the Xmega (in ASM of course...) and I can send text files and receive the text on the terminal screen without problems with the LUFA bridge.

After many files I could see only 1 character messed up. The files are pretty short, up to 447 bytes.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Neat! Glad you're able to get some use out of it John. I'll be using it myself when I get my own XPLAIN board which I just won off Ebay.

Now, on to PDI programming. The part I'm stuck on is how to expose it to the host, so that it's actually useful. I could make the USB AVR appear as an AVRISP-MKII to the host, but that would break the UART bridge (since the cruddy Jungo drivers only work on devices with the correct VID/PID, rather than by interface). I suppose I could make a button toggle between modes, but I'll be interested to see what route Atmel themselves take.

- Dean :twisted:

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

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

John, do you have an idea what byte was messed up and what it should have been? Are you using the corrected uart code?

John.

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

Quote:
do you have an idea what byte was messed up
I think it was a full stop, but thats after sending 450 bytes file out to the chip continuously.

Edit these were the 2 files used for the test. The CV version has a clock output on PD7 and needs a negative pulse on PA6 to trigger the printing.

The asm version prints a little banner (repeatable if ESC pressed) and then just echoes back whatever comes in. The clock for both is 2.027MHz because that's what I have in my board.

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John,

I tried both of your hex files. My Xplain currently has the bridge code posted by j0n90.

The CV code displays correctly but is hardly an onerous test. e.g. small quantity of text output slowly.

The ASM version obviously copes with my typing. But if I send a 18k text file directly from a file I lose characters everywhere.

IMHO a soft UART should be able to cope with full speed reception of 9600 baud with NO loss. Of course a soft UART has to have an interrupt latency less than a single bit time. I expect that Dean can make some comments on the service time of the USB interrupts.

So a sensible test of "fitness for purpose" would consist of the PC sending say a 10k text file and the xmega sending a similar amount of continuous text.

In practice a PC is only going to send a small quantity of text to an "echo" program running on the xmega. However non-echoing text should be foolproof in both directions.

David.

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

David it is difficult to know what release of hex you are running... I have released 2, one based on the atmel cdc example and the other on Deans MYUSB.
There is a danger that if you have the one that I hashed together with deans MYUSB cdc project that bytes could be missed if the scheduler got a bit delayed in transfering what was received in to the ring buffer as I didn't have it transfering on receive. It might be worth using the hex that dean has posted that he has compiled as it uses the lastest LUFA cdc project and will most likely prove more reliable. It could also be the bit interrupt isn't quick enough especially in full duplex operation, maybe doing bits both rx and tx and also doing USB stuff is overwhelming the processor. I think it should be ok but I can't say for sure.

John.

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

I will do a bit of experimenting shortly. I know that your bridge captures everything from the xmega ok. e.g. if you do a massive hex dump from the xmega to a PC terminal. The Atmel code would corrupt. This is basicly testing the soft UART RX from the xmega TX.

John had an "echo" program. So you get the PC terminal to send a text file. The 1287 receives this over USB, and soft TX's it to the xmega UART RX. The xmega UART then just echoes it back i.e. the 1287 soft UART has to receive it and pass back through USB to the terminal.

This gives the 1287 full speed TX and RX. If the soft UART uses the hardware to time the OC2 bits it should cope.

David.

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

Are INT0\INT1 used for the soft uart or is it just polled? Anyway Dean's code works MUCH better than the original.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

My conclusions:

For xmega UART TX:

The original Atmel loses many characters.
j0n90's cdc.hex loses no characters
Dean's XPLAINBridge.hex loses the odd char.

None are very robust if you fire full bursts at 9600 baud both ways.

However both of the last two options are usable.

I will look at the soft UART code. In my opinion you can get a pretty good two-way soft UART using INT0, COMPA, COMPB interrupts. You receive on the INT0 pin, and TX via the OC2B pin. For example you can echo 115200 baud at full speed without losing a single character. (no other IRQs being serviced)

As an aside. The design of the XPLAIN is for the 1287 UART to provide PDI for the xmega. Surely a regular RS232 bootloader is the simplest arrangement? But I suppose you have no fuse access.

If the 1287 UART was directly connected to any of the xmega's eight uarts, you would have seamless communication. The xmega PDI / JTAG capabilities are already provided by the 10 pin header.

David.

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

Hi all,

I'm experiencing the same serial problems as everyone here. However, I also have problems programming with Flip. Maybe someone knows the answer how to get the AT90USB chip to boot in DFU mode. The jumper on J200 pin 1+2 does not seem to do the trick.

I noticed that the revision 2 schematic and board layout that are in AVR1902 do not match with the board I received. My board does say A08-0551 Rev 2 though.

As far as I understand Flip, I need to get a different USB product code (USB\VID_03EB&PID_2FFB) when in bootloader mode to communicate with Flip, but I keep getting the virtual COM port (USB\VID_03EB&PID_210D).

Don't have any atmel JTAG programmer. Only the AVRISP mkII.

Once I get this going I'd be happy to test some of the serial stuff. Thanks for any tips.

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

Man, you guys are amazing :) would love it if dean could finish up atmels short comings :) maybe you should sell atmel your code dean hahaha

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

Quote:

Man, you guys are amazing Smile would love it if dean could finish up atmels short comings Smile maybe you should sell atmel your code dean hahaha

I wish - I'd love to get some income from LUFA (even though I purposly made it open source and MIT so that more people would use it, to help my job prospects later on) however I don't think Atmel are interested -- after all, they continue to develop their own USB stack.

Quote:

I'm experiencing the same serial problems as everyone here. However, I also have problems programming with Flip. Maybe someone knows the answer how to get the AT90USB chip to boot in DFU mode. The jumper on J200 pin 1+2 does not seem to do the trick.

You need to short the AVR's /HWB pin to GND (I assume that's what that jumper is designed to do) while resetting the AVR. Try shorting the jumper while powering up the board.

I think I remember that some of the boards were supposed to have been released without a DFU bootloader installed on the AT90USB1287; perhaps you were unlucky enough to have received one of those.

Quote:

j0n90's cdc.hex loses no characters
Dean's XPLAINBridge.hex loses the odd char.

Is that loss only in the one direction? The soft UART code is still the same between the two HEX files, as I've simply converted it over to the latest LUFA distribution. The only problem I can see would be characters lost from the XMEGA if the software UART's receive function isn't called fast enough before another character arrives. Normally I buffer the characters directly from the UART receive interrupt, but that's obviously not possible here.

How tight is the timing? Perhaps I'll have a go at implementing the software UART in C using interrupts there so I can buffer the bytes as they are received into the ring buffer.

- Dean :twisted:

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

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

Not directly related, but I've been having a look at the 1287 DFU bootloader (and the crypto application of the JAVAN kit) to see what they're doing and how the USB stuff works. I've deliberately not looked at LUFA just so when I do get to it I'll have a broader base of experience.

Anyway, I'm amazed that the 1287 DFU bootloader even works at all from some of the things I've seen in there. They write a lot of "reserved" bits and values into various I/O registers (like the PLL divisor), and at one point totally trash RAMPZ and then proceed to use it. I'm sure I'll find more as I continue sniffing around. The Butterfly bootloader likewise had its shortcomings, although nothing quite as gross.

Anyway, they should get Dean to develop a clean version for them. And I'll write up everything I found out in the next couple of weeks.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

Quote:

Anyway, they should get Dean to develop a clean version for them. And I'll write up everything I found out in the next couple of weeks.

LUFA already contains my own version of a DFU bootloader, which compiles smaller than Atmel's. I haven't seen Atmel's DFU code because they haven't released the source code to my knowledge; do you have a download link?

For the record, here's the LUFA DFU bootloader source:

http://code.google.com/p/lufa-li...

- Dean :twisted:

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

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

Quote:
because they haven't released the source code to my knowledge

The old guys work from the hex files. :(

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

Quote:
If the 1287 UART was directly connected to any of the xmega's eight uarts, you would have seamless communication.
It IS directly connected to one of the xmega's eight uarts, USARTC0.

The problem is with the 1287 and the soft usart it uses to communicate with USARTC0. There could also be "issues" with the way USB packets data I suspect but don't really know.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Hey Chuck you should really reveal the number you are holding against your chest in the mugshot. :lol:

Or else take another shot with a little smile...you can even assume a sophisticated, debonnaire look if you like...I won't sue you.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Oh, all right. This fuzzy thing will have to do until I go out in the garage and find the one with the tutu on my head.

I rather enjoyed being the grumpy old man.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

Hi Dean,

Thanks for your answer.

Quote:

You need to short the AVR's /HWB pin to GND (I assume that's what that jumper is designed to do) while resetting the AVR. Try shorting the jumper while powering up the board.

Ok, I found a description of this now. Very confusing that the xplain hardware manual mentions PF4 needs to be shorted to ground instead. Also the HWB pin is not routed and shorting it does not seem to solve it. It just boots with the com port. Guess I'll try an SVF player with a generic JTAG adapter.

Quote:

I think I remember that some of the boards were supposed to have been released without a DFU bootloader installed on the AT90USB1287; perhaps you were unlucky enough to have received one of those.

My board is from Mouser. It looks like the board shown in the "minimizing power" doc8267.pdf. The board layout is different than the schematics in AVR1907. See attached pic.


If anyone from Atmel is here: I've never done AVR and this xplain board is not helping much in this way. I've not experienced such a poorly launched dev board in some time. No source code, a manual with mistakes and undocumented boards being sold. I know it is cheap, but something done poorly is worse.

Attachment(s): 

Pages