Serial port weirdness

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

I'm doing my first project with the Xmega128AU and just got to the serial port part. It is driving me into an early grave

Has anybody, I implore,
Seen anything like this before?

CRLF'O'.jpg

That is the first three characters of CR, LF, 'OK', CR, LF, sent immediately after reset. You'll perceive that it stars with TXD negative, as it should because it's proper RS232 and not TTL. It gets as far as 'O' and then stops, with TXD HIGH. Nothing will induce it to complete the string.

 

However, if I back up with the JTAG ICE and run that signon routine again, this is what I get -

CRLF'OK'.jpg

Now that is the complete CR, LF, O, K, CR, LF sequence - but it's upside down. Nothing except a hard reset gets the serial port back the right way up, and then it flips again on the third character.

 

I've tried several of the different ports and they all behave the same way. I suspect that somewhere in one of the multiple manuals I have to keep open with this damn chip there's probably a line or two about it, but I can't find it for looking. I'm starting to deeply regret picking an XMEGA for this project - it's just one thing after another.

 

Attachment(s): 

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

Two things:

 

1) this new forum lets you inline images :-)

 

2) the xmega are unusual in that you need to set the DDR for the pins involved when you use UART (it doesn't take control automatically) - are you doing that?

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

but it's upside down

In addition to Cliff's comment, note that there is a register which will invert the actual output state of a port.pin, in hardware.

IIRC it is discussed in the section that discusses the pin output modes, (totem pole, etc).

Perhaps you could also search your code and make sure no ASF routines, if you are using them, is mis-setting this in an ISR, etc.

 

I'm not on my main computer this week.

Does that uC have USB, and have you tackled that hurdle yet?

I think most Xmega USB Threads recommend Dean's LUFA instead of Atmel's ASF USB software, in case that saves you a headache or two.

 

JC

 

   

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

Thanks, gents. I did have the ports and directions properly set. It's just that the double buffering doesn't work. If I write to the data register before the previous character is completely sent, "undocumented conditions" occur. I just changed the routines to test the TXC flag instead of the DRE flag and all is well.

 

Doc, this Xmega does have USB and that's on my list. I used Dean's LUFA on several projects with AVR and will do so again, if I stay with Xmega, but I'm at a stage in the project where it's possible to change the hardware, and I've been cursing myself for a fool in going with Xmega instead of ARM.

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

peret wrote:
I used Dean's LUFA on several projects with AVR and will do so again, if I stay with Xmega,

Dean himself will tell you that LUFA+Xmega is not a concrete solution. If you want to do USB on Xmega use ASF.