Simple USART communication error, ATMega168-20PU

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

Hello, I'm very new to AVR Programming in general and am trying to configure my ATMega168 for USART serial communication. I am programming the chip using a USBTinyISP and attempting to communicate through an FTDI cable. Here is my code below:


serialLoopback.c

#include <avr/io.h>
#include <util/delay.h>
#include "pinDefines.h"
#include "USART.h"
int main(void) {
  char serialCharacter;
  // -------- Inits --------- //
  LED_DDR = 0xff;                            /* set up LEDs for output */
  initUSART();
  printString("Hello World!!!!\r\n");                          /* to test */
  // ------ Event loop ------ //
  while (1) {
    serialCharacter = receiveByte();
    transmitByte(serialCharacter);
    LED_PORT = serialCharacter;
                           /* display ascii/numeric value of character */
  }                                                  /* End event loop */
  return 0;
}

Makefile 

The original Makefile can be found here: https://github.com/hexagon5un/AVR-Programming/blob/master/Chapter05_Serial-IO/serialLoopback/Makefile

The only things that I have edited are the following:

MCU   = atmega168
F_CPU =  1.0E6
BAUD  = 9600

When I open a terminal (in my case, CoolTerm), I connect to the FTDI port, set the baudrate to 9600, data bits = 8, parity = none, stop bits = 1. When I type a character into the terminal, I should get that character returned back to me. Instead, I get the following when I type a character:

Ä

(0x80 in hex.)

When I reset the chip, I get the following:

..ÄÄÄ.Ä.ÄÄ.ÄÄÄÄÄ..ÄÄÄÄÄÄÄ..Ä.ÄÄ..ÄÄ..Ä..Ä..Ä..ÄÄ..Ä.

which should be "Hello World!!!!". I have the Rx of the FTDI connected to the Tx on the chip, and vice versa. I have the FTDI cable grounded to the chip's ground. When I isolate the FTDI cable and connect Rx to its own Tx, I get the character I typed returned back to me, which should rule out any computer/terminal issues I would think. 

I have a feeling that it has to do with the F_CPU value, but I have tried setting this value to all values of Fosc outlined in table 17-9 of the atmega datasheet (1MHz,  1.8432MHz, 2 MHz, etc.), without any luck.

Any help at all would be appreciated.

This topic has a solution.

R M Janovic

Last Edited: Fri. Nov 3, 2017 - 03:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it is a virgin chip, the default fuse settings are for 1MHz. This will give you unaceptable error. You really want an external crystal and to set your fuses to suit. This is a common problem, so google avr fuses

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

Are 1MHz clocks always too slow for USART communications?

R M Janovic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
int main(void) {
  CLKPR = 0x80;
  CLKPR = 0x00;
  

Okay, it seems like adding the above code to the top of main() does the trick. It's not entirely clear where this comes from in the datasheet, but if it works, it works. If anyone has any further explanation for this, please let me know. Thanks!

R M Janovic

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David (aka frog_jr)

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

Generally no, but if you look at the baud rate table in the datasheet you’ll see the error for 1MHz and 9609 baud is too great.
Also, note that the internal oscillator is not really accurate, so serial comms might work one day and not the next. Best be using a crystal and avoid the problem.

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

Thanks guys, I think this makes much more sense now. I appreciate it!

R M Janovic