Mega64 UART Problem

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

When receiving serial bytes at 115200 baud the result is always 0xFF regardless of the data sent. Some of the bytes are not received at all (i.e. if 5 bytes are sent often less than 5 are received).

The application uses interrupts for UART reads/writes but I simplified it to poll UDR1. Both the interrupts and polling return 0xFF.

For testing RealTerm sends a single byte. Monitoring RXD1/PD2 on the Mega64 with a scope shows that the correct pulses appear and the bit rate is 115200 baud. I verified that the Mega64 baud is correct by transmitting bytes and measuring the bit rate with the scope.

I even copied code from several previous projects but the result is always 0xFF.

The simple answer is bad MCU. But that is usually not the problem.

char value[5] = {0,0,0,0,0};
int i=0;
char ch;

DDRD = 0b00001000;      // TX = output; INT_PAR, RX, INT_IR, INT_SER0 = inputs
ch = UDR1;			      // clear receive interrupt

UCSR1A = 0x00;        // single transmission speed, single processor communications
UCSR1B = (1<<RXEN1)|(1<<TXEN1)|(1<<RXCIE1)|(1<<TXCIE1); // Enable rx/tx, rx/tx ints
UCSR1C = (1<<UCSZ1)|(1<<UCSZ0);   // no parity, 1 stop bit, 8 data bits

UBRR1L = 3;    // set baud rate (xtal = 7.3728MHz)
UBRR1H = 0;
while(1)  //+++ TEST UART RX AT 115200 BAUD
{
    while (!(UCSR1A & (1<<RXC1)));    // wait till receive complete
    value[i] = UDR1;
    if (i < 9)
      i++;
    else
      i = 0;
 }
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Monitoring RXD1/PD2 on the Mega64 with a scope

What speed is your AVR really running at? How have you proven that?

Anyway, since you have a 'scope you put your AVR in continuous transmission of 'U' characters each time UDRE rises. At 8,n,1 that gives a 50% duty cycle square wave. Bit width/frequency can be verified.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I did not use 'U' but continuous transmissions of several other hex values and verified that the 'short' bits were 8.68usec wide (i.e. 1/115200). Also, compared screenshots of the same hex values transmitted from RealTerm and they were exact matches.

With baud rate mismatches the received bytes are normally incorrect but usually not all 1's (0xFF) regardless of the data.

Also, before scoping I tried setting different baud rates and, as expected, getting off by a factor of 4 or more stopped reception entirely.

BTW - 8,N,1 on both original host software, RealTerm and Mega64.

I am absolutely positive this is not a baud rate issue - maybe.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
UCSR1B = ...|(1<<RXCIE1)|...
...
    while (!(UCSR1A & (1<<RXC1)));    // wait till receive complete 

Either interrupt controlled, or polling. You can't "mix" it.

BTW: What is the state of the M103C fuse?

Stefan Ernst

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

What are the fuse bits set to? Is there a clk div/8 fuse seetting? Not familiar with your part hence the div/8 question.

I too think it is a code issue anad not the micro

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

 

"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 user

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

Quote:
Either interrupt controlled, or polling. You can't "mix" it.

This is a carryover from the "real" code (not this test code) but global interrupts are not enabled so enabling the TX and RX interrupts have no effect.

Quote:
What is the state of the M103C fuse?

It is not set (i.e. box not checked).

Quote:
clk div/8 fuse

My tools are disconnected and packed for a trip tomorrow so I cannot check it right now. However, since the baud rate is correct the DIV/8 fuse (if there is one) must not be selected.

When I get back later this week I will try slower baud rates and verify the pulse waveforms again.

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

Quote:
My tools are disconnected and packed for a trip tomorrow so I cannot check it right now. However, since the baud rate is correct the DIV/8 fuse (if there is one) must not be selected.


How can you be sure? Have you transmitted to the host and displayed something on the screen or scoped the txd pin on the mega to measure the baudrate that way?
Oh wait, you know the baud rate is correct so the bit must not be set.....Then why are you posting here saying you have a problem then?

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

 

"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 user

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

Quote:
How can you be sure? Have you transmitted to the host and displayed something on the screen or scoped the txd pin on the mega to measure the baudrate that way?

From my first post:
Quote:
For testing RealTerm sends a single byte. Monitoring RXD1/PD2 on the Mega64 with a scope shows that the correct pulses appear and the bit rate is 115200 baud. I verified that the Mega64 baud is correct by transmitting bytes and measuring the bit rate with the scope.

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

Quote:
... but the result is always 0xFF.

How do you verify what you have received?

Stefan Ernst

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

Here's a simple compilable program that might help.

Attachment(s): 

Imagecraft compiler user