USB AVR Programmer serial port issue

Support Other Pololu products
1

Hi,

I am having a issue with the serial port on the Pololu USB AVR Programmer. I am running Windows 7, AVR Studio 5, and Br@y++ terminal and using this on a Baby Orangutan B-328. My programmer has firmware version 1.06 so that it works with AVR Studio 5. I have used AVR Studio 5 and the programmer to change the program in my 3pi, so I know that set up works.

What is happening is I set up the usart on the Orangutan to read the from rx, copy the data, and send it back out tx. The code I am using comes straight from the Atmega328P datasheet. So using Br@y++ terminal I send a character to the Orangutan, and it is supposed to send the same character back. What I get back is garbbled. I don’t get the same character I sent, I get strange characters, some with accents.

I have both the AVR and Br@y set for 9600 baud 8N1, rx of programmer to tx on orangutan, and tx of programmer to rx on orangutan.

Below is a copy of my code

#include <avr/io.h>
#include <stdint.h>
#include <util/delay.h>
#define BAUD9600 ((F_CPU / 9600 / 16) - 1)

void serial_init(unsigned int baud);
void serial_write(unsigned char data);
unsigned char serial_read(void);

int main(void)
{
  unsigned char rx_data;
  serial_init(BAUD9600);
  while(1)
  {
    rx_data = serial_read();
    serial_write(rx_data);
    }
  return 0;
}

void serial_init(unsigned int baud)
{
  UBRR0H = (unsigned char) (baud >> 8);
  UBRR0L = (unsigned char)  baud;

  UCSR0B = (1 << RXEN0) | (1 << TXEN0);

  UCSR0B = (3 << UCSZ00);
}

void serial_write(unsigned char data)
{
  while(!(UCSR0A & (1 << UDRE0)));

  UDR0 = data;
}

unsigned char serial_read(void)
{
  while(!(UCSR0A & (1 << RXC0)));

  return UDR0;
}

I don’t know if the code helps, but there it is. It must be some setting, somewhere, that I haven’t set up, because on the programmer I took the tx line and tied it to the rx line and Br@y++ output exactly what I sent.

Thanks for your help,
Tony

2

I was wondering if it has anything to do with my fuse bit settings. Everything I have read on AVRfreaks forum says it has something to do with a timing issue. Either wrong baud rate or incorrect fuse settings. So I check my oragnutan’s settings:

I get 0xFC D9 F6, under SUT_CKSEL it is set to EXTFSXTAL_1KCK_14CK_4MS1

Just as a comparison I checked my 3pi:

0xF9 DF CF, under SUT_CKSEL it is set to EXTXOSC_8MHZ_XX_1KCK_14CK_65MS

They are both running a mega328P with 20Mhz clock. Do the clock settings seem right? I guess what I will try next is to see if I can get the code to run on my 3pi. I will also try the Pololu library serial communication code. If the Pololu code works and my code still does not work, at least I will know it is my code. Then I’ll try the Pololu code on my orangutan to make sure my hardware has no issues.

Other than that I am out of ideas,
Tony

3

Hello, Tony.

Did you remember to define F_CPU? It’s not defined in your source code at least, but I don’t know if you defined it in your AVR Studio 5 project settings. Try adding this line to the very top of your program:

#define F_CPU 20000000

–David

4

In AVR Studio 5 I added the F_CPU symbol and set it, but that still didn’t help. I am still wondering if my fuse setting are wrong. I am going to try the Pololu serial library and see if that code works. Other than that I really don’t know what could be the issue. The code is sending data to the terminal program, but there must be some timing error since it is getting garbled.

Let me know if you have any other ideas.

Thanks,
Tony

5

Hi Tony.

Your Baby Orangutan fuse settings look right, but your 3pi fuse settings aren’t. Assuming your 3pi and Baby Orangutan really both have ATmega328Ps, they should both have the same fuse settings:

efuse: 0xFC (AVR Studio) or 0x04 (avrdude)*
hfuse: 0xD9
lfuse: 0xF6 (full-swing crystal oscillator, ceramic resonator w/ fast rising power: 1k CK startup, 14 CK + 4.1ms additional delay)

  • The extended fuse byte doesn’t use its upper five bits. AVR Studio reports these unused bits as set while avrdude reports them as cleared, which is why you will see two different values for these bytes depending on what you’re using. The important bits of this fuse byte are the three lowest ones, and these are the same for both 0xFC and 0x04.

Please note that setting the fuses incorrectly can permanently disable your Orangutan/3pi, so be very careful when changing them! If your 3pi seems to be working fine, I would not change the fuses.

Can you try using the serial functions in the Pololu AVR library and see if you get a different result?

- Ben

6

Hi Ben,

I know my 3pi hardware works so I am using that for my testing. Since the 3pi is working I am not going to mess with the fuse bits. I just thought they were wrong on the Baby O.

So I compiled the serial example from the latest Pololu lib. Downloaded it into the 3pi, and I am still getting garbage. I send a character, and get crazy characters back.

Here is my hardware set up: 3pi and Pololu USB AVR programmer - firmware version 1.06 to work with AVR Studio 5. TX from 3pi to RX of programmer, and RX of 3pi to TX of programmer. My software set up: AVR Studio 5 for compiling and downloading and Br@y++ terminal program - set to 9600 baud, 8N1, no handshaking. Also at the top of the code (mine and the Pololu example) I define F_CPU, just in case.

What I know works: AVR Studio, 3pi, and programmer. I can compile the 3pi demo program and download it into the 3pi with the programmer and it works fine. The serial port on the programmer works because I can jumper TX to RX and send characters that get echo’d back correctly.

That is why this is driving me nuts. Each part by itself works, and most of it works together. It is just the last little bit not working. I don’t think it is hardware as it would be unlikely that I damaged both the 3pi and Baby O serial port pins. I just don’t have any other ideas.

Let me know what you think,
Tony

7

When you listed your connections, you didn’t say anything about ground. Are you connecting your Baby Orangutan ground to the programmer’s ground? If not, this could explain why you’re seeing garbage. With very few exceptions, all the devices in your system should have a common ground.

It doesn’t sound to me like anything is damaged. Typically, when something is damaged, it manifests as no response from the damaged part. That you’re seeing garbage means that something is generating signals, and the signals are just not getting through right, so I’d be looking for a software problem or a connection issue.

- Ben

8

Thanks Ben.

I am an electrical engineer by trade, so how I forgot to hook up ground I will never know. All this time wasted for just a missing connection. After adding the ground, the example code was working. Now to go back to the Baby O and my code.

Thanks again for your help,
Tony

9

I’m glad to hear that it was such a simple fix and you have it working now. Thanks for confirming that was your problem.

- Ben

10

I programmed the Baby O with the Pololu example serial code, made sure the ground was hooked up, and it worked. So of course I decided to try my original code, and it does not work. At least now I know it is my code that needs fixing. So back to working on my code.

Thanks again.