Atmega1284P USART to USB output is garbage

[Solberg]

Hi

I'm trying to print a char over USART, with a Atmega1284P on the STK500 to my computer.
But all i get is garbage on the output.
I have used the built in UART to RS232 converter on the STK500 before, with no problems. With an Atmega16L.

I am using the internal oscillator.

Anyone know what is wrong with my code?
What do i miss?

Code: [Select]

#include <avr/io.h>
#include <util/delay.h>

#define F_CPU 8000000
#define BAUD 19200
#define MYBRR ((F_CPU/(BAUD*16UL))-1)

void USART_Init(unsigned int ubrr)
{
UBRR0H = (unsigned char)(ubrr>>8);
UBRR0L = (unsigned char)ubrr;

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

UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}

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

UDR0 = data;
}

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

return UDR0;
}

int main(void)
{
USART_Init(MYBRR);
    while (1)
    {
_delay_ms(500);
USART_Transmit('a');
    }
}


[oPossum]

You may have to calibrate the internal oscillator. AVR don't have very accurate default calibration.

It is possible to use a UART with a precise clock (USB to UART is fine) to determine the osc cal value...

https://forums.adafruit.com/viewtopic.php?t=5078
https://forum.arduino.cc/index.php?topic=8553.0

[TK]

Maybe the problem is that you configured the DataFrame as 2 bytes and you are sending 'a' as single byte?

[Siwastaja]

I highly recommend you buy or get an access to an oscillosscope. It's very difficult to debug such problems without one. With an oscillosscope, you can measure the bitrate you actually are getting, and also verify the data bits if that needs to be done.

The most likely suspects are:

1) some calculation error on setting the baud configuration registers. Note, many MCU UART peripherals have a configuration bit which changes the rate by 2x, can be called "oversampling", "half mode" or similar

2) the clock source isn't what you think it is, the whole MCU is running at a completely different clock rate. Easy to see on an oscillosscope,

3) the clock source is an inaccurate RC oscillator, and it's off by more than about 3%, which will be too much error for UART. The solution is to calibrate the RC, or use a crystal oscillator instead.

Note about coding style, I recommend you document, in comments, what the register settings are, even briefly. Cryptic bit names like "USBS0" are impossible to understand without the datasheet in hand. Write in comments what you are doing, for example, if this is related to data width, add a comment // data width = 8 bits

[NiHaoMike]

A cheap FX2 logic analyzer (using the Sigrok software) would be a better debug tool for beginner microcontroller projects.

[Syntax Error]

I note on your image the data rate is 19200 8N2
Is that 8 bit no parity TWO stop bit?

[Siwastaja]

I note on your image the data rate is 19200 8N2
Is that 8 bit no parity TWO stop bit?

Extra stop bits on the sending side never cause trouble, and can actually only help, by forcing longer idle times. If you send with 2 stop bits, it doesn't matter if the receiver is configured for 1 or 2 stop bits. This shouldn't be the problem.

If you send with 1 stop bit though, a misconfigured receiver expecting to see 2 stop bits may detect an error and/or not receive.

Edit: misread, you were commenting about the receiver setting. Clearly this can be the problem right here.

[cv007]

The avr is already already set to 2 stop bits, and is only sending once every 500ms in any case (9600 stop bits). The code posted looks like its straight from the datasheet, and with internal 8MHz/19200, you have 0.2% error and I doubt even with internal clock you are going to have problems unless you are in a freezer or furnace. Now if you have CKDIV8 fuse programmed (default), that would cause a problem as your clock is 8x slower than you calculated.

First stop, check CKDIV8.

A terminal program with 1000 settings probably doesn't help.

edit-
I would also add that the CKDIV8 fuse causes problems for everyone at some point. Even when you know about it and have 'been there' many times, its still easily forgotten. A better habit to get into is to simply always set the prescale to the desired value in your init code, so you always know what you have regardless of fuse setting.

[Solberg]

i would like to thank everyone who commented, thanks. sorry i haven't been able to write back before now.

The avr is already already set to 2 stop bits, and is only sending once every 500ms in any case (9600 stop bits). The code posted looks like its straight from the datasheet, and with internal 8MHz/19200, you have 0.2% error and I doubt even with internal clock you are going to have problems unless you are in a freezer or furnace. Now if you have CKDIV8 fuse programmed (default), that would cause a problem as your clock is 8x slower than you calculated.

First stop, check CKDIV8.

A terminal program with 1000 settings probably doesn't help.

edit-
I would also add that the CKDIV8 fuse causes problems for everyone at some point. Even when you know about it and have 'been there' many times, its still easily forgotten. A better habit to get into is to simply always set the prescale to the desired value in your init code, so you always know what you have regardless of fuse setting.

Thank you so much, that was precisely the problem. Now it works

[Solberg]

I highly recommend you buy or get an access to an oscillosscope. It's very difficult to debug such problems without one. With an oscillosscope, you can measure the bitrate you actually are getting, and also verify the data bits if that needs to be done.

The most likely suspects are:

1) some calculation error on setting the baud configuration registers. Note, many MCU UART peripherals have a configuration bit which changes the rate by 2x, can be called "oversampling", "half mode" or similar

2) the clock source isn't what you think it is, the whole MCU is running at a completely different clock rate. Easy to see on an oscillosscope,

3) the clock source is an inaccurate RC oscillator, and it's off by more than about 3%, which will be too much error for UART. The solution is to calibrate the RC, or use a crystal oscillator instead.

Note about coding style, I recommend you document, in comments, what the register settings are, even briefly. Cryptic bit names like "USBS0" are impossible to understand without the datasheet in hand. Write in comments what you are doing, for example, if this is related to data width, add a comment // data width = 8 bits

An oscilloscope is definitely on the wish list