Arduino Mega 2560 - USARTs 2 and 3 aren't working

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

Greetings avrfreaks forum. I'm trying to determine why the following code fails to operate correctly on my month-old Arduino Mega 2560.

/*
avr-gcc -c -Os -Wall -mmcu=atmega2560  -o example.o example.c
avr-gcc -o example.elf example.o -lm -mmcu=atmega2560 
avr-objcopy -O ihex example.elf example.hex
*/

#define F_CPU 16000000
#define BAUD 115200
#define BAUD_TOL 3
#include 
#include 
#include 
#include 
#include 
#include 

void init(void)
{
  DDRB |= (1 << DDB7);
  UBRR2 = UBRR_VALUE;
#if USE_2X
  UCSR2A |= (1 << U2X2);
#endif
  UCSR2B |= (1 << RXEN2) | (1 << RXCIE2);
  UCSR2C |= (1 << UCSZ21) | (1 << UCSZ20);
  sei();
}

ISR(USART2_RX_vect) {
  UCSR2B &= ~(1 << RXCIE2); }

int main(void)
{
  init();
  for(;;)
  {
    _delay_ms(500);
    PORTB ^= (1 << PB7);
  }
  return 0;
}

In short: an LED blinks once every 500ms in a loop. USART 2 is enabled for receiving, and the receive-complete interrupt vector is enabled, but the vector does nothing aside from disabling itself.

Currently, the board's LED occasionally will stop flashing. Nothing needs to be connected to the USART pin for this to happen, but adding unconnected wires or connected devices sending serial data seems to cause it to happen more frequently. This does not happen when changing the registers above to use USART1 instead and using that pin to communicate.

Using avrdude, I've extracted the fuse bits from the chip:
:0100000000FF
:00000001FF
I believe this enables the watchdog timer and selects clock source 0, which I think is a ceramic 16MHz oscillator.

Using this same board, I implemented and tested a circular-buffered serial library which now no longer works; the chip hangs at some point in execution. I'm not sure what else to try; the example above is about as simple as it can get. What's going on? Is my board defective?

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

Is there a putchar and a getchar in the lib for all 4 uarts? How does the arduino select uart0 and 1? With a 'file descriptor' like unix? I have putchar 0-3 and a switch to select which one from a global called 'fd' on my mega1280 programs with multiple ports. Try putchar('U'); to uarts 2 and 3 if you can figure out how they want you to send to them.

Imagecraft compiler user

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

I have a serial communications library that handles buffered i/o, printf, and so on, if you want to use it it's available via
svn co svn://vidya.dyndns.org/ceng547/serial
I tested it a while ago, it works. However I'm not asking about that.

My problem is that USART 2 and 3 are unusable because, even with the basic code above that simply disables the RX-complete interrupt once it happens, the AVR chip freezes, probably caught in some sort of interrupt loop. This happens sporadically whether or not anything is actually actively sending data to USART 2 (or even connected).

What's more, if I change all the registers to use USART 1 instead, the AVR chip will not freeze. This indicates that there are hardware problems, but I'm not sure what they could be.

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

It would seem that the problem lies in Fedora 14's version of avr-libc. Everything worked before the 'upgrade', and everything works great under WinAVR.

So I guess this thread is now less of a desperate cry for help and more like a public service announcement: F14's avr-libc is somehow broken for the moment, don't use it.

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

This is the reason why we again and again suggest to never use avr toolchains that come with Linux distributions.

Instead build your own from sources and patches, see the "Bingo script".

Stealing Proteus doesn't make you an engineer.

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

Can Fedora use .deb's (I think it may be .rpm based)?

If you can install .deb's then get your pre-cooked Bingo version of avr-gcc from:

www.wrightflyer.co.uk/avr-gcc/

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

I have the same problem and have been investigating quite deeply.

The interrupt vector table produced by GCC seems corrupted toward the end of the table for this part (2560). Compiling for a mega1280 seems to to produce a correct vector table.

still investigating...

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

I have open a bug on GCC regarding this matter:

http://gcc.gnu.org/bugzilla/show...

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

macdiamonds wrote:
I have open a bug on GCC regarding this matter:

http://gcc.gnu.org/bugzilla/show...

I think the fix is correct.

Anitha