| Author |
Message |
|
|
 Posted: Dec 01, 2009 - 10:39 PM |
|
Joined: Aug 13, 2006
Posts: 6701
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: 9826
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: 6701
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: 3087
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: 9826
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: 16308
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: 9826
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: 20368
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: 16308
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: 9826
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: 20368
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: 9826
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: 20368
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: 16308
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. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
