XMEGA-A1 XPLAINED interrupt driven USART timed out

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

We try the AVR1307: "Using the Xmega USART" to run on our Xplained board (BLUE PCB!). The polling version is working well. We putting the received data on the transmit statment. So we get an echo in the terminalprog running on XP. A small change in the initialization is done by setting the TXD pin high, according the XMEGA-A manual 21.5. So far, it seems everything including the RS232 Virtual Comport works.

Now we change to the interrupt driven example and nothing is on the right way. It seems that the receiving is working, but transmitting timed out.
The COMPORT-Trace with PORTMON shows the open is done, the characters are written to the board, but the read-process hangs up.
If we close and restart the terminalprog an error "no such port" is reported. But in the XP devicemanager the port is marked operable. After restarting windows the portfunction is available again.
Also a timeout is reported by BATCHISP if we tried to flash the xmega128 by bootloader.
The USART examples are build on GCC and WinAVR-20100110. Programming the device is done with a DRAGON. The boardcontroller firmware has not been changed!

There are any questions:
May be, anybody has the same experiences with the USART on this board (XPLAINED XMEGA-A1, PCB is BLUE!)? So he or she knows the problem and a solution.
What states signals the multicolor LED nearby the USB-Connector? We can't find any useful docu about!
What is about the USB-COMPORT Bridge in XP? We guess this is a MS CDC standarddriver, is there any other driver available (LUFA?).

Advices and help are very welcome!

Thx D.C.K

Update Status:

BTW we wrote a usart-app (interrupted and poll) from the scratch: surprise surprise, it works well!
It looks as the ASF has any obstacles inside!

Meanwhile we mailed with ATMEL-Support regarding the BATCHISP. There are any open Questions about the USB /COM interfacespeed on the Xplained board. So they Atmel guys filed a bug report. If we getting some further info from ATMEL we will post it here.

Thx D.C.K

Last Edited: Sat. Jun 11, 2011 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The virtual serial port problem has nothing to do with the Xmega and is just a driver problem with windows. I have yet to use a virtual COM device that works well with windows. Keep in mind they tend to switch port numbers, so it might start as COM4, but then go to COM8 or COM9 if you unplug it, plug it in again.

What usart examples are you using?
Keep in mind Xmega interrupts are twice enabled. Global interrupts need to be set as well as the specific level that the interrupt is created on.