USART problem

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

On an STK500, connecting the Tx/Rx pins for loopback works great, what is typed on the computer is received back.

Then a mega16 is programmed using the following code from Dean Camera's tutorial "Using the USRART in AVR-GCC". The returned character looks like baud rate, character length, or party is wrong.

Any ideas what is wrong?

The comm program is gtkterm and AVRDUDE Terminal mode says FOSC = 1843200Hz.

// From Dean Camera's tutorial "Using the USART in AVR-GCC"
# include 

#define F_CPU 1843200
#define USART_BAUDRATE 9600
#define BAUD_PRESCALE (((F_CPU/(USART_BAUDRATE*16UL)))-1)

int main (void)
{
  char ReceivedByte;

  UCSRB |= (1<<RXEN) | (1<<TXEN);
  UCSRC |= (1<<URSEL) | (1<<UCSZ0) | (1<<UCSZ1);

  UBRRH = ( BAUD_PRESCALE >> 8);
  UBRRL = BAUD_PRESCALE;

  for (;;)
  {
    while ((UCSRA & (1<<RXC)) == 0) {};
    ReceivedByte = UDR;
    while ((UCSRA & (1<<UDRE)) == 0) {};
    UDR = ReceivedByte;
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried to
emit from your avr (say, an infinite sequence of 'U's : if there is a speech synthetiser in gtkterm it would be great)and
to find out the baud rate /parity you receive (gtktherm has some settings) your PC would receive?

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

It the orginal message it was only tried in Ubuntu using gtkterm. Now I'm using Bray's Terminal in Windows and an STK500. The STK500 is what I used in Ubuntu.

Looping back via a jumper, leaving out the mega16, what is typed is returned perfectly.

Using the mega16 this, "5&b49b0f&0&7ÀÀÀÀÀøøÀøøøøÀÀøøÀøøøøøcccc"

This tells me it is the mega16 software. The comm settings are 9600 baud, 8-bit, no parity, 1 stop.

Mike

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

Did you change the fuses to use external clock? By default the mega16 runs at 1MHz from an internal RC oscillator. Before changing any fuses, does it work if you change to "#define F_CPU = 1000000"?

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

It might be mega16 hardware (or its peripherals, say an interface circuit like a max232):

does your atmega16 use a crystal?
are PC ground and atmega 's ground equipotential?
are there intermediate circuits?
do you get more caracters than you typed/less?

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

It looks like the code you posted is the RX portion only. What about the TX side?
Also, does the tutorial say this code returns what is sent?

EDIT:
I looked at the tutorial and your code looks like deans sans the comments.

The oscillator looks like the culprit as noted above

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Quote:

Did you change the fuses to use external clock? By default the mega16 runs at 1MHz from an internal RC oscillator.

Exactly. Just because avrdude terminal mode tells you the STK500 oscillator is set to 1.8432MHz does not mean the AVR is actually taking any notice of it.

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

The problem was a combination of having the lfuse set for the internal 1MHZ oscillator. Once that was corrected part of the problem disappeared. About half of the characters were correct, half wrong.

Strapping the STK500 to use the 4MHz crystal corrected another problem.

Thanks guys,
Mike