Getting weird characters in hyper-terminal on serial connection of PC and Atmega-16

I have a Atmega-16 based board, connected via Max232 to pins 2,3,5 of a db-9 connector. The connector connects to a PC. I am getting weird characters on hyper-terminal instead of normal "Hello World" for the serial test program. I have set both baud rate in Atmega-16 as well as hyper terminal to be 4800. I am not getting any faults. Please help. Thank you!

Edit: I am using this kit : http://roboshop.nextsapiens.com/index.php?route=product/product&product_id=55 The Serial pins of the Atmega16 are routed through a max232 to db-9, the circuit is same as this one:

The settings on terminal are:

Data bits: 8
Stop bits: 1
Parity: none
Baud rate: 4800

The bascom code is:

$regfile = "m16def.dat"$crystal = 2000000
\$baud = 9600
Config Lcd = 16 * 2
Config Lcdpin = Pin

Cls

Cursor Off

Dim A As String * 1
Do
A = Waitkey()
Print A
Cls
Lcd A
Loop

End


The problem can further be viewed as: http://i.stack.imgur.com/dmnJo.png

The images showing the characters(10) i am receiving are:

and the corresponding hex code that i am reciving is:

• Make sure the polarity of the signal is correct, as the Max232 inverts it if I recall correctly. Aug 10, 2012 at 16:12
• @Oli - Yes, but that's a property of RS232: logic 1 = -12 V, logic 0 = +12 V. the receiver should invert it again. Aug 10, 2012 at 16:14
• @Steven - I know, but I was thinking the OP may have set the UART up with logic 0 = +5V already, so when passed through the Max232 it ends up with logic 0 = -12V. Many uC UART peripherals have a polarity selection bit. Aug 10, 2012 at 16:21
• @user636177 can you post a (link to) schematic please? Are you connecting the hardware UART of the ATMega16 to the MAX232? Aug 10, 2012 at 17:04
• Can we see the initialization code for the Atmega USART and the frame definition in Hyper Terminal (number of start/stop bits, number of data bits, parity)? Aug 10, 2012 at 17:09

Check the baud rate on the hyper terminal or the oscillator settings.

• I have already checked them, and its fine, some other problem is there Aug 10, 2012 at 15:51
• @user636177 If you have access to a oscilloscope try to check that the correct data is being transmitted. Aug 10, 2012 at 15:56
• Either measure the actual baud rate (inverse of the period of the shortest pulses) or verify that the baud divisors are being correctly set for the clock actually in use on the board. Also, the ATMEGA family has an additional divide-by-two bit in another register. Aug 11, 2012 at 5:00

It is relatively unlikely that the 2 MHz clock frequency given in your code is appropriate. More likely candidates would be 12 or 16 MHz, or even 8 MHz.

If you cannot determine the actual crystal frequency, you could "measure" it by figuring out the number of bit periods per byte of transmitted data (iirc 10, but check that) and diving your chosen baud rate by that to find the number of bytes per second. Multiply that by say 5 and write a for loop to turn on an LED, send that many bytes, then turn it off. Time how long it takes.

• The clock operates at a frequency of 8 MHz, but has to be scaled down to 2 MHz for proper functioning of the serial communication as told by manufacturer of kit. Is the variable type a problem? Aug 13, 2012 at 19:47
• That statement is hard to find credible; if anything, the higher the clock rate the more precisely you can generate a UART baud rate. Likely the message has been confused somewhere along the way, or the concern has to do with something unrelated to the UART. Try the timing experiment. Aug 13, 2012 at 20:13
• The data sheet atmel.com/Images/doc2466.pdf includes baud divisor tables all the way up to 20 MHz clock. Aug 13, 2012 at 20:30
• i tried timing experiment, through LEDs and the baud rate seems correct. Please see this apsim.info/Wiki/… . Aug 14, 2012 at 5:53
• @user636177 The relevance of your link isn't immediately apparent. I take it you do not have an oscilloscope? How about dropping the baud rate to maybe 1200 baud, sending one character over and over (0x55, 'U' would be a good choice for its bit pattern) and coupling the serial line into your sound card and plotting the data? It might take a little experimentation with resistive dividers to get a good picture, but in theory your should have 48 KHz/1200 Hz = 40 samples per bit. You could also set your PC serial port to output the same thing and compare how that looks. Aug 14, 2012 at 14:45