| Author |
Message |
|
|
Posted: Nov 19, 2009 - 04:14 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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 by js on Nov 25, 2009 - 08:03 PM; edited 2 times in total
|
| |
|
|
|
|
|
Posted: Nov 19, 2009 - 09:56 AM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
| 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. |
|
|
| |
|
|
|
|
|
Posted: Nov 19, 2009 - 12:13 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 19, 2009 - 12:50 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 19, 2009 - 02:35 PM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 19, 2009 - 10:02 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 20, 2009 - 04:48 PM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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..... |
|
|
| |
|
|
|
|
|
Posted: Nov 20, 2009 - 08:43 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
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? 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
|
| |
|
|
|
|
|
Posted: Nov 21, 2009 - 04:07 AM |
|

Joined: May 27, 2007
Posts: 39
Location: Portland, OR
|
|
| 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. |
|
|
| |
|
|
|
|
|
Posted: Nov 21, 2009 - 04:42 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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.  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
Last edited by js on Nov 21, 2009 - 05:10 AM; edited 1 time in total
|
| |
|
|
|
|
|
Posted: Nov 21, 2009 - 04:57 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| 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
|
| |
|
|
|
|
|
Posted: Nov 21, 2009 - 08:18 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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?? |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 24, 2009 - 11:20 AM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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. |
Last edited by j0n90 on Nov 24, 2009 - 06:39 PM; edited 1 time in total
|
| |
|
|
|
|
|
Posted: Nov 24, 2009 - 01:08 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
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) |
|
|
| |
|
|
|
|
|
Posted: Nov 24, 2009 - 09:17 PM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 24, 2009 - 09:27 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 12:06 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 01:12 AM |
|


Joined: Jul 02, 2005
Posts: 6039
Location: Melbourne, Australia
|
|
|
abcminiuser wrote:
- Dean
ahh, look who has new "sunnies" ... |
_________________ Ross McKenzie
ValuSoft
Melbourne Australia
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 02:39 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 04:24 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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-lib/sourc ... INBridge.c
See how much better it all is with the new framework?
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 06:19 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 07:47 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:25 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:28 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:34 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| 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
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:35 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:36 AM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
| 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
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:53 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 10:28 AM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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!).
Code:
// 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
Code:
// 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!! |
|
|
| |
|
|
|
|
|
Posted: Nov 25, 2009 - 08:09 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 26, 2009 - 06:17 PM |
|

Joined: Nov 12, 2009
Posts: 4
|
|
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 |
|
|
| |
|
|
|
|
|
Posted: Nov 26, 2009 - 06:31 PM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 02:15 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 06:53 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 09:24 AM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 27, 2009 - 10:35 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
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. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 09:27 AM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 05:40 PM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 08:20 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 09:31 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| 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
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 10:01 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 10:18 PM |
|

Joined: Nov 23, 2009
Posts: 4
|
|
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. |
|
|
| |
|
|
|
|
|
Posted: Nov 28, 2009 - 10:19 PM |
|

Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ
|
|
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 |
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 03:44 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
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  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 04:03 AM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
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
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 04:06 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
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-lib/sourc ... oaderDFU.c
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 04:08 AM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
|
Quote:
because they haven't released the source code to my knowledge
The old guys work from the hex files.  |
_________________ Chuck Baird
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 06:40 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
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
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 06:43 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
Hey Chuck you should really reveal the number you are holding against your chest in the mugshot.
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
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 07:06 AM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
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
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 11:15 AM |
|

Joined: Nov 23, 2009
Posts: 4
|
|
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.
<rant>
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.
</rant> |
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 11:55 AM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
Your photo is very different to my XPLAIN board.
Do you have a serial# or any rev# ?
As far as I can remember you will get to the DFU bootloader by putting a jumper over pin #0,#1 of the J200 AT90USB1287 JTAG header. It explains in AVR1907.
David. |
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 12:02 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
I have changed the "uart_soft.S" file in the xplain_cdc LUFA project. This "uart_kbv.c" is an alternative soft UART that copes far better with heavy traffic.
The original design is from danni. It uses the hardware to set the OC2B pin for the TX. This ensues rock solid TX timing.
Code:
#include <avr/io.h>
#include <avr/interrupt.h>
#include "soft_uart.h"
#define BAUD 9600
#define BIT_TIME (uint16_t)((F_CPU + BAUD/2) / BAUD)
#define SRX PD0 // Tiny2313 INT0/INT1 PD2/PD3
#define SRXPIN PIND // Mega32 INT0/INT1 PD2/PD3
#define SRXPORT PORTD // 90USB1287 INT0/INT1 PD0/PD1
#define STX PD1 //PB2
#define STXPORT PORTD
#define STXDDR DDRD
#define W(sfr, x) {sfr ## H = (x) >> 8; sfr ## L = (x);}
#define R(sfr) ((x16 = sfr ## L), x16 += (uint16_t)(sfr ## H) << 8)
#define ADD(dst, src, val) {x16=src##L;x16+=(uint16_t)src##H<<8;x16+=(uint16_t)(val);dst##H=x16>>8;dst##L=x16;}
volatile uint8_t srx_done, stx_count;
volatile uint8_t srx_data, srx_mask, srx_tmp, stx_data;
unsigned char Uart_tx_ready(void)
{
return (stx_count == 0);
}
unsigned char uart_putchar(unsigned char c)
{
while (stx_count);
stx_data = ~c;
stx_count = 10;
return c;
}
unsigned char uart_test_hit(void)
{
return srx_done;
}
unsigned char uart_getchar(void)
{
while (!srx_done);
srx_done = 0;
return srx_data;
}
void uart_init(void)
{
OCR2B = TCNT2 + 1; // force first compare
TCCR2A = (1 << COM2B1) | (1 << COM2B0); // T1 mode 0
TCCR2B = (1 << FOC2B) | (1 << CS21); // CLK/8, T1 mode 0
TIMSK2 = (1 << OCIE2B); // enable tx and wait for start
EICRA = (1 << ISC01); // -ve edge
EIMSK = (1 << INT0); // enable INT0 interrupt
stx_count = 0; // nothing to send
srx_done = 0; // nothing received
STXPORT |= 1 << STX; // TX output
STXDDR |= 1 << STX; // TX output
SRXPORT |= (1 << SRX); // pullup on INT0
}
ISR(INT0_vect) // rx start
{
OCR2A = TCNT2 + (BIT_TIME / 8 * 3 / 2); // scan 1.5 bits after start
srx_tmp = 0; // clear bit storage
srx_mask = 1; // bit mask
TIFR2 = 1 << OCF2A; // clear pending interrupt
if ((!(SRXPIN & (1 << SRX)))) { // still low
TIMSK2 = (1 << OCIE2A) | (1 << OCIE2B); // wait for first bit
EIMSK &= ~(1 << INT0);
}
}
ISR(TIMER2_COMPA_vect)
{
if (srx_mask) {
if (SRXPIN & (1 << SRX))
srx_tmp |= srx_mask;
srx_mask <<= 1;
OCR2A += BIT_TIME / 8; // next bit slice
} else {
srx_done = 1; // mark rx data valid
srx_data = srx_tmp; // store rx data
TIMSK2 = (1 << OCIE2B); // enable tx and wait for start
EIMSK |= (1 << INT0); // enable START irq
EIFR = (1 << INTF0); // clear any pending
}
}
ISR(TIMER2_COMPB_vect) // tx bit
{
OCR2B += BIT_TIME / 8; // next bit slice
if (stx_count) {
if (--stx_count != 9) { // no start bit
if (!(stx_data & 1)) // test inverted data
TCCR2A = (1 << COM2B1) | (1 << COM2B0);
else
TCCR2A = (1 << COM2B1);
stx_data >>= 1; // shift zero in from left
} else {
TCCR2A = (1 << COM2B1); // START bit
}
}
}
|
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 05:57 PM |
|

Joined: Nov 23, 2009
Posts: 4
|
|
|
david.prentice wrote:
Your photo is very different to my XPLAIN board.
Do you have a serial# or any rev# ?
Yes it has several numbers, but at the back bottom it says: A08-0551 Rev 2.
Note that the pictures is from an Atmel document about measuring power. The shunt resistor on the picture is on my board but not on the schematics.
david.prentice wrote:
As far as I can remember you will get to the DFU bootloader by putting a jumper over pin #0,#1 of the J200 AT90USB1287 JTAG header. It explains in AVR1907.
Yes, but then it still boots with the virtual com port. Not with the jungo interface needed by FLip. |
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 06:59 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
My XPLAIN has several stickers:
A08-0551 Rev A
A09-0560/02
SN0300000265
I am not using Flip at the moment. But surely it will boot into DFU if you Reset the board with pin#0=pin#1. You either cycle the power or bring the Reset pin #6 of J200 to GND.
David. |
|
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 09:13 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
You need to install 2 USB driver for the Xplain, 1 for the bridge and 1 for FLIP.
Revision 1 of the board does NOT have a booloader installed in the 1287.
David do you have a finihed hex file for the bridge and the updated soft usart? |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Nov 29, 2009 - 10:02 PM |
|

Joined: Nov 23, 2009
Posts: 4
|
|
|
david.prentice wrote:
My XPLAIN has several stickers:
A08-0551 Rev A
A09-0560/02
SN0300000265
Mine are:
A08-0551, Rev 2
A09-0560/04
SN:0200004884
david.prentice wrote:
I am not using Flip at the moment. But surely it will boot into DFU if you Reset the board with pin#0=pin#1. You either cycle the power or bring the Reset pin #6 of J200 to GND.
Thanks for the tip about resetting on pin #6. Booting with pin#0=pin#1 and power cycling does nothing. But with resetting it now works!
With Flip my bootloader version for the AT90USB1287 is 1.F.0. I can't read the flash as it is protected.
Thanks for your help |
|
|
| |
|
|
|
|
|
Posted: Nov 30, 2009 - 12:28 AM |
|


Joined: Jul 02, 2005
Posts: 6039
Location: Melbourne, Australia
|
|
|
yopper wrote:
david.prentice wrote:
My XPLAIN has several stickers:
A08-0551 Rev A
A09-0560/02
SN0300000265
Mine are:
A08-0551, Rev 2
A09-0560/04
SN:0200004884
Mine on the board are:
A08-0551, Rev 2
A09-0560/04
SN:0200000506
... and on the box
A09-0620/04
SN:0200000204
2009.07.17
Obviously the serial numbers have zero correlation with version numbers.
Why on your deity's little earth would anyone issue a "Rev A" and then (or not) a "Rev 2". Is "A" before "2" in any rational sequencing scheme? Sheesh ...
Waiting for the dust to settle before doing anything ...
Cheers,
Ross |
_________________ Ross McKenzie
ValuSoft
Melbourne Australia
|
| |
|
|
|
|
|
Posted: Dec 01, 2009 - 09:54 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Attached is a new build of the project, using the above C software UART. Depending on which version has the highest reliability, I'll see if I can use that in the final version of the bridge (once I get permission from all authors).
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 01, 2009 - 10:29 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
I put a 25k asm file through the new bridge and could not see any garbage on the screen.
Unfortunately the terminal program cannot send and receive a file as far as I can tell so I saved the screen buffer (uCon terminal, Hyperterminal could not keep up) to a file and then used fc in dos mode. There were differences but I suspect it was just the way screen capture works.
Eye capture looks ok scrolling trough the screen buffer.
If I have some time later on I may try and send some project files and recapture the screen buffer, see if the project still compiles correctly. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Dec 01, 2009 - 10:39 PM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
| Speaking of permission, what do you do about VID/PIDs for LUFA and the DFU bootloader? Just curious... |
_________________ Chuck Baird
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 04:31 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Atmel have generously donated a block of 16 PIDs in their VID range for my LUFA project use -- they seem to realise that having a silly muppet put in all that work for free is a good thing, which they should support (at least in that way).
As for the DFU bootloader, I'm forced spoofing Atmels' DFU PID, since their crummy driver won't allow any other VID/PID pair to work. With any luck they won't notice or care .
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 06:06 AM |
|


Joined: Aug 13, 2006
Posts: 6758
Location: Bellingham, WA - USA
|
|
|
Quote:
With any luck they won't notice
Well, I'll keep your secret. That's great news about their support of LUFA. |
_________________ Chuck Baird
"It's better to catch the trapeze than test the safety net" -- RPi book
http://www.cbaird.org
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 10:05 AM |
|

Joined: Dec 16, 2005
Posts: 3094
Location: Bratislava, Slovakia
|
|
|
js wrote:
Unfortunately the terminal program cannot send and receive a file as far as I can tell so I saved the screen buffer (uCon terminal, Hyperterminal could not keep up)
Not really germane to this thread, but since you mentioned...
The only ready-made terminal program I came across so far, capable of capturing and saving inbound serial stream at any speed up to 115200Bauds, while correctly handling hardware handshake, was realterm (realterm.sf.net).
Has its quirks, though - besides a hard-to-get-used-to user interface - never use it to *send* a binary file, as it simply drops all 0x1A-s - found out the hard way, although it IS documented...
JW |
|
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 12:37 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
David,
Are you able to release that software UART code under the MIT license for inclusion in LUFA? I'd want to include whichever software UART is the most reliable, so that it can benefit the largest number of users.
To all those with XPLAIN boards: fear not, I'm busy unwrapping the XPROG PDI protocol as we speak!
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 02:01 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
Yes. That is fine by me. But please mention Peter Danneger 'danni', because the method came from him.
As far as I can see, the PDI protocol is fairly straightforward at the lowest hardware level. But I have not come across any public code that writes the raw JTAG commands. They tend to interface with a JTAG-1 or JTAG-2 device rather than the raw TCK, TMS, TDI, TDO signals.
Obviously the first stage is to implement program upload. But eventually Studio would use the interface for full JTAG debugging.
Presumably the STK600 could function as a debugger if Atmel chose. After all it has the same connectivity as a JTAGICEmkII. And they could fit the code into the XPLAIN 1287 if they chose. It all depends on whether they want it to be an attractive evaluation kit for their Xmega devices.
David. |
|
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 02:03 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Thanks, I'll add the code to the XPLAIN Bridge code now and remove John's (sorry John, but reliability is key!).
I've finished the AVRISP-MKII PDI unwrapping code, so now I just need to implement the low level PDI commands. I'd expect to have something ready for testing in only a few days.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 08:58 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
The only ready-made terminal program .... was realterm
uCon has no problems keeping up, just did not know how to send and capture at the same time.
These are the files used, sent: AVRA README.txt file (24K) echoed and captured: xplain_test.txt
The FC screen shot seems to show just 1 char difference but it may just be some incorrect setup as it is an extend character.
edit yep, it's a capture setting problem. The uCon screen shows the correct charater, so it's 100% correct with 24K. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Dec 02, 2009 - 09:10 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
John,
I can assure you that you can crash most soft UARTs + Terminal echo if you try hard enough.
Either by a massive load of regular text, or a massive load of fancy Terminal escapes. (as in the attached file)
In practice you are only going to send a human digestible quantity of text. In which case you will probably get no glitches.
David. |
|
|
| |
|
|
|
|
|
Posted: Dec 03, 2009 - 08:20 AM |
|

Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ
|
|
Dean;
So what you're doing is getting the 1287 to program the Xmega and let the PC see it as a AVRISP-MKII, correct? Thats just awesome if i'm ever in Oz or you're ever in NZ, i would like to buy you a beer  |
|
|
| |
|
|
|
|
|
Posted: Dec 03, 2009 - 08:41 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
Dean;
So what you're doing is getting the 1287 to program the Xmega and let the PC see it as a AVRISP-MKII, correct? Thats just awesome Smile if i'm ever in Oz or you're ever in NZ, i would like to buy you a beer Smile
Yes, exactly -- I'm doing what Atmel can't, apparently. I've already got a working AVRISP-MKII clone in my LUFA project which does ISP, but now that the latest AVRStudio can do PDI programming through the AVRISP-MKII, I'm using that as a base for the XMEGA programmer.
To remain compatible with the real XMEGA programmer I'll be using software PDI on the same pins as the real AVRISP-MKII, even through the XPLAIN board has it connected to the AVR's hardware USART. Once I get it going I'll probably make it automatically change over to the faster hardware UART when compiled for the XPLAIN board.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 03, 2009 - 09:39 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
Suggestion from bootloader thread in case you miss it.
Quote:
In order to switch between usart bridge and programmer the 2 pins near the SDRAM could be used (GND and PDI), if a link is fitted then go into programming mode otherwise usart bridge mode.
|
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Dec 03, 2009 - 09:41 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Good idea. Once I get the AVRISP project working with PDI programming, I think I'll edit it into the XPLAINBridge project code to do just that.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 06, 2009 - 05:10 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
Reporting some more experiences with the Xplain board:
Communicating from windows with the Xmega via the usb1287 chip works well (at least with an Xplain rev.4 board) without the need to flash an alternate usb bridge. The usb-to-serial bridge has be installed first using the inf file supplied with the AVR1907 (11/9) zip file from Atmel's web site.
Flashing the usb1827 can be done easily, but be aware: After flashing the usb1287 chip as decribed at the end, I was not able to revert to the original USB bridge (maybe the freaks here can give a solution). I was stuck to use one of the usb bridges posted in this forum (and of course using the corresponding inf files for installing a suitable windows driver for communication with the usb1287 USART). Those drivers however seem to lose characters unlike the original factory supplied code which works very well at 32 MHz Xmega frequency using bsel=104 and bscale=1. The nasty thing with this driver however in contrast to the others posted in this forum is that after unplugging the usb connector and reconnecting it, the respective com port at the PC cannot be accessed unless flashing the Xmega with a code that does not use the USART (like a simple LED flashing code), and subsequently reflashing the Xmega with the code using the USART.
Anyway, I decribe here how I was able to program the usb 1827:
Using Atmel's Flip program, the 1287 can be programmed via usb. First put one of the supplied plugs across pins 1 and 2 of the upper left 10-pin post. Then connect the usb plug to the PC with this bridge in place. Windows will ask for a new driver. Follow the instructions up to point #7 as written p.7 of the AVR1907 pdf file. Flip then can be used to program the usb1287. For using the usb bridge for communication with the Xmega, the bridge across the pins 1 and 2 has to be removed and the usb cable be reconnected. Windows then uses the com port that has been installed from the 1907 zip file.
Flashing the Xmega through the usb1827 still waits for a solution. |
|
|
| |
|
|
|
|
|
Posted: Dec 06, 2009 - 06:57 PM |
|

Joined: Nov 29, 2007
Posts: 3219
|
|
| My experience with a Rev. 4 is different, as just summarized elsewhere yesterday. |
|
|
| |
|
|
|
|
|
Posted: Dec 06, 2009 - 07:47 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
|
ArnoldB wrote:
My experience with a Rev. 4 is different, as just summarized elsewhere yesterday.
ArnoldB, either there are sub-families of the Rev.4's or I am lucky to have a rare board with an usb-serial bridge functioning by design. It is no joke. As stated above Hyperterminal screen fills nicely with numbers on which I believe..javascript:emoticon(' '). The box tells me A09-0620/o6, SN..., 2009.10.16. Looking underneath the board is not so easy anymore since it is mounted on a plate. But I have another one, will test it maybe tomorrow. |
|
|
| |
|
|
|
|
|
Posted: Dec 06, 2009 - 08:32 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
Addition: I am trying to find out why there are so many users considering the factory-programmed usb-serial bridge to be totally faulty. Maybe it is because of this: It is very easy to lock the usb-serial channel irreversibly in one session (see my previous post), for instance by unplugging the usb during a transmission. On reconnecting the USB, the red LED next to the plug goes on and stays on, regardless of trying to reset either the hyperteminal or the usb1287, and Hyperteminal refuses to connect to the com port. Also, rebooting the PC does not help.
I repeat the sequence to be followed exactly to restore the transmission:
a) Disconnect Hyperterminal by pushing the hang-up button.
b) Flash the Xmega with some stupid stuff
c) Unplug USB.
d) Flash the Xmega with the USART addressing code (printf..)
e) Plug-in USB-connector
f) Press Connect-button in Hyperterminal.
g) Enjoy the printout to the terminal.
As long as the USB stays connected, the connection remains stable, and the Xmega can be flashed without doing harm.
Would be interesting to hear from others. But the problem might be, if one fiddles around with the usb1287 (flashing it) it might be difficult to revert to the original state, and then one needs a different usb-serial bridge such as posted in this forum.
Certainly, this behaviour, requiring to intermediately flash some nonsense stuff to the Xmega after unplugging the USB connector is a bug in the Xplain board software. I repeat that this behaviour is absent in those usb-serial bridges posted recently in this forum. But I was not able to achieve stable transmission using those. Avrfreaks should easily have an explanation for these observations? |
|
|
| |
|
|
|
|
|
Posted: Dec 07, 2009 - 01:43 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
I programmed the usb-serial bridge supplied to me by Atmel and the results are lots of missing characters as shown on the 1st page of this thread.
The recent "home cooked" versions are very good.
I'm posting the Atmel supplied code you may want to try with your board. If it works well then we need to chase some hardware issues. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Dec 07, 2009 - 05:33 PM |
|

Joined: Nov 29, 2007
Posts: 3219
|
|
I am not so much interested in programming the xmega on the xplain, but the at90usb1287. I'll probably use the xmega only as a means to forward data to some LCD display.
Regarding programming the 1287 via the shipped bootloader, my experience is that the procedure as described in Atmel's application note 1907 doesn't work for me.
Under Windows with FLIP and under Linux with dfu-programmer I also needed to wire up the 1287 reset pin. Just placing the jumper on pin 1 and 2 did nothing for me.
However, with the additional pushbutton on the reset line I was able to download a blinking LED application and I could also later restore the original USB bridge (which I had read via JTAG before I started experimenting with the blinking LED application). |
|
|
| |
|
|
|
|
|
Posted: Dec 07, 2009 - 05:46 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
Surely this is a common circumstance. You want to RESET an AVR with a certain hardware condition.
So you set up the hardware condition --- jumper pin#1,2 of XPLAIN J200. Then apply RESET --- touch RESET pin to GND.
This is what you have to do with any micro that I have ever come across. Most ready-made boards will have a push-button to apply the hardware condition and a push-button to apply the RESET.
Using the USART bootloader on an ARM or 8051 chip is achieved either by your fingers + two push-buttons or by the DTR/RTS pins of the RS232 connection.
If you have a JTAG connection, you can apply the RESET as a JTAG command without wearing down your fingers.
Of course the other alternative is for you to type a special character within a specified time. But there will be people who do not like that system either.
David. |
|
|
| |
|
|
|
|
|
Posted: Dec 07, 2009 - 07:01 PM |
|

Joined: Nov 29, 2007
Posts: 3219
|
|
Only that Atmel claims in AVR1907 you don't have to do anything with the reset pin, just jumper pin 1 and 2 on J200 and unplug and replug the USB cable (which also supplies the power).
My xplain couldn't care less about unplugging and replugging the power. With or without jumper the 1287 never ends up in bootloader mode. With a jumper and reset it does. |
|
|
| |
|
|
|
|
|
Posted: Dec 07, 2009 - 10:05 PM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
| I don't have any problems with the jumper and unplugging and replugging the power, it works ok. |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
Posted: Dec 23, 2009 - 11:46 AM |
|

Joined: Aug 01, 2007
Posts: 99
|
|
Blimey, I've been in the 'matrix' for a couple of weeks (sometimes i need to do some work!) and it looks like the problems with the serial port have all been sorted out.
Good stuff with the PDI programming too, will there be PDI debug support? |
|
|
| |
|
|
|
|
|
Posted: Dec 23, 2009 - 12:18 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
Good stuff with the PDI programming too, will there be PDI debug support?
Thanks! The code for PDI is now in the latest LUFA release package (as is the XPLAIN serial bridge) at http://www.fourwalledcubicle.com/LUFA.php. So far it's programming only, but only because that's all the host software will do while I pretend to be a AVRISP-MKII. I don't really want to have broken functionality by pretending to be a JTAG-MKII but only implement a few protocols, so no debugging as of yet. The code will support it pretty easily however, if someone writes a custom front-end for it.
I'm just about to start TPI protocol implementation, when Atmel releases the protocol information.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 23, 2009 - 09:01 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
Great!. But I am mostly interested in faster UART communication with the XMEGA rather than in flashing it through the USB port(bought an ISP MKII). But, prior to flashing the compiled hex file from the LUFA project (and being unsure on how to revert to the original state in case of problems), could you tell which Baud rate can be used?
In my previous post I had described the problems with the factory supplied usb bridge (I have Rev.4), but nevertheless it works reliably, however at much too slow 9600 Baud.
And, by the way, the locking of the com port (see my previous posts) can be avoided by delaying the first printf statement by 100ms. |
|
|
| |
|
|
|
|
|
Posted: Dec 23, 2009 - 09:58 PM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
The USARTC0 can only run at 9600 baud. You would struggle to go much faster.
But with the Xplain board you can use USARTD0 and USARTD1 from the 10 pin header. These are obviously TTL levels so you would need to connect via a MAX2232 or a FT2232D chip.
Then you can run the USARTs as fast as you like.
David. |
|
|
| |
|
|
|
|
|
Posted: Dec 28, 2009 - 01:27 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
| What causes the 9600 Baud constraint of USARTC0 on the Xplain board? The Xmega manual does not seem to specify differences between the USARTs. |
|
|
| |
|
|
|
|
|
Posted: Dec 28, 2009 - 10:26 PM |
|


Joined: Apr 25, 2004
Posts: 3817
Location: Denmark
|
|
|
ArnoldB wrote:
I could also later restore the original USB bridge (which I had read via JTAG before I started experimenting with the blinking LED application).
Arnold could you upload the "original bridge" ?
I kind if blew mine away .. including the flip loader , when i used the dragon for Deans code
/Bingo |
|
|
| |
|
|
|
|
|
Posted: Dec 28, 2009 - 10:53 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
|
Quote:
I kind if blew mine away .. including the flip loader , when i used the dragon for Deans code Embarassed
Is there still an ongoing issue with my bridge code? It should be functionally identical, and thus you should not need to use Atmel's.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Dec 29, 2009 - 12:54 AM |
|

Joined: Nov 29, 2007
Posts: 3219
|
|
|
Bingo600 wrote:
Arnold could you upload the "original bridge" ?
See attachment. It contains the complete flash of an rev. 4 - bridge and bootloader (and lots of FFs in between).
BTW, decoding the hex file gives
Code:
00e0 000c0341 0054004d 0045004c 00260358 ...A.T.M.E.L.&.X
00f0 0070006c 00610069 006e0020 00550053 .p.l.a.i.n. .U.S
0100 00420020 00470061 00740065 00770061 .B. .G.a.t.e.w.a
0110 00790012 03300030 00300030 00300030 .y...0.0.0.0.0.0
0120 00300030 00040309 04180353 00650072 .0.0.......S.e.r
0130 00690061 006c0020 0050006f 00720074 .i.a.l. .P.o.r.t
0140 00200350 0072006f 00670072 0061006d . .P.r.o.g.r.a.m
0150 006d0065 00720020 0050006f 00720074 .m.e.r. .P.o.r.t
0160 002a0008 01000000 08000001 ea0c00ff .*..............
Interesting that Atmel talks about "Programmer" in the bridge code. |
|
|
| |
|
|
|
|
|
Posted: Dec 29, 2009 - 09:38 AM |
|


Joined: Apr 25, 2004
Posts: 3817
Location: Denmark
|
|
@Dean
No problem with your code , i just didn't use Flip to put it in , so i lost the "Original"
and just wanted to have it if possible
@Arnold
Thanx
/Bingo |
|
|
| |
|
|
|
|
|
Posted: Dec 29, 2009 - 09:59 AM |
|

Joined: Feb 12, 2005
Posts: 16545
Location: Wormshill, England
|
|
|
very_new_user wrote:
What causes the 9600 Baud constraint of USARTC0 on the Xplain board? The Xmega manual does not seem to specify differences between the USARTs.
There is no limitation to the xmega USARTC0 as such. It is the same as any other xmega USART.
The limitation is only with the bridge code. i.e. the PC seeing a virtual COM port.
Since the Xplain hardware connects the xmega to the AT90USB1287 via bit-banging, a software UART is limited in speed. The software UART by itself will run perfectly at 115200 baud, and possibly faster. However the AT90USB1287 also has to service USB interrupts. It cannot manage all the interrupts involved in the software UART above a certain speed. In simple terms, a software UART has interrupts for each bit of TX and RX e.g 10 IRQs for each 8-N-1. A regular AVR hardware UART only interrupts when it has processed a full byte.
David. |
|
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 02:01 AM |
|

Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ
|
|
| Sorry to bring this back up but is it possible to have deans programmer AND a working USART bridgeto be programmed onto the same AT90USB1287 and swap between them using a button/jumper or something? |
|
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 05:41 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
You'd be surprised how many people have asked that. I actually spent much of yesterday unsucessfully trying to make the Atmel Jungo driver bind to a specific interface in a composite device I created, but had no luck. Instead, I offer the newly changed XPLAINBridge firmware, attached here.
When inserted into a USB host, it will read the TDI pin of the USB AVR's JTAG port. If left high it will work as a USB to USART bridge, if pulled low it will act as a PDI programmer for the XMEGA.
The updated source code is located in the XPLAINBridge project of the LUFA SVN.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 05:42 AM |
|


Joined: Mar 28, 2001
Posts: 20630
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
Already discussed http://www.avrfreaks.net/index.php?name ... 852#644852
But Dean is too busy boozing up with the other Melbourne freaks to do any work.
Quote:
Might want to edit
OK so it looks like he sobered up.  |
_________________ John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
Last edited by js on Jan 19, 2010 - 06:04 AM; edited 1 time in total
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 05:50 AM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Might want to edit that John after you read my post just above yours .
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 06:00 AM |
|

Joined: Jun 10, 2007
Posts: 475
Location: Auckland, NZ
|
|
Wow, Great stuff!
Will try it out next week when my boards finally arrive ( i hate christmas break time ) |
|
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 02:11 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
Dean,
your work is really fantastic. As a very_new_user, I wonder how you freaks are able to type (?) hundreds of lines of code correctly....(which editor/compiler are you using?)
Anyway, is this XPlain_usb bridge also limited to those 9600 baud? Others, using the Silab USB-USART-Bridge CP2102 instead of Atmel's 1287 get much higher baud rates. Is it just a brand issue that the Xplain board uses the 1287? |
|
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 02:21 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
Thanks very_new_user!
Quote:
As a very_new_user, I wonder how you freaks are able to type (?) hundreds of lines of code correctly....(which editor/compiler are you using?)
Lots of practice - and trust me, lots of swearing and head-scratching. What you see here is the product of many hours of work (LUFA + AVRISP-MKII + XPLAINBridge) which a tiny HEX file doesn't really convey. I program using Programmers Notepad using the free avr-gcc compiler under Windows. Eric, another user here, helpfully packages all the required tools into a single package for you under Windows, called WinAVR.
Quote:
Anyway, is this XPlain_usb bridge also limited to those 9600 baud? Others, using the Silab USB-USART-Bridge CP2102 instead of Atmel's 1287 get much higher baud rates. Is it just a brand issue that the Xplain board uses the 1287?
Yes, it is limited to 9600 baud. This is a technical limitation because of a decision by Atmel. In theory, the onboard AT90USB1287 was supposed to do two jobs; act as a PDI programmer for the XMEGA, and act as a USB-to-Serial bridge for the XMEGA's USART. The problem with this is that the PDI programming interface of the XMEGA is encoded via USART framing as well, but the AT90USB1287 has only one hardware USART.
Since programming speed is more important than debug console speed (to the Atmel designers, anyway) they chose to hook the fast hardware USART to the PDI programming interface, and use a slower software USART for the debug channel. This is what limits the speed - the AT90USB1287 is only clocked at 8MHz. Clocking at 16MHz would increase the maximum software USART speed to 19200, so it's strange Atmel went with the lower clock.
Using another vendor's USB-to-Serial IC wouldn't help, as it would not be able to act as a PDI programmer for the XMEGA. If Atmel was unconcerned with making the board programmable without external hardware, then the AT90USB1287 could have acted as a very fast converter if the hardware USARTs were linked together.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 03:19 PM |
|

Joined: Nov 24, 2009
Posts: 38
|
|
Dean,
thanks for your remarks on programming and on the 1287 issue. But, if you do a search for "XMEGA-A1-USB" you will find an XMega board employing the CP2102 that should work e.g. at 250kBit/s compared to the 9600 (should be bits/s, right?, not baud as I wrote, that's the reason why it feels that slow) with the 1287. And, there is also the USB programmer. One can switch between the Xmega UART bridge and the programmer by means of an utility ("Change MC-Module PID"). How can we understand that?
-very_new_user |
|
|
| |
|
|
|
|
|
Posted: Jan 19, 2010 - 10:09 PM |
|


Joined: Jan 23, 2004
Posts: 9878
Location: Trondheim, Norway
|
|
It's *possible* to do it with a FTDI or other chip, but you'd either need one with dual COM port functionality, or with user-controllable GPIO pins. However, the former would require quite a complex PC program to work, while the latter would require a complex PC program and be extremely slow.
I guess Atmel choose the USB1287 due to it being an Atmel chip, and because you can do many other things with it, like turn it into a Mass Storage device for the Dataflash. It would probably have been better if they chose the hardware USART for debugging for those that need such a high bitrate, but obviously they felt that programming speed was more important.
- Dean  |
_________________ Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|