ATMEGA1284 restart for an unknown reason

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

Hi,

I'm using an Atmega1284 for my project and when I send too much characters at once it sometime resets. I send some random characters using a terminal. This terminal has the possibility to send packets too. Basically what happens is

1.Send character
2.Recieve interrupt into MCU
3.Store it into my circular FIFO (The FIFO_Push is in the interrupt section)

Is Sending characters too fast a potential cause for a reset?

I don't think it's an overflow caused by the FIFO because sending as many characters more slowly does not cause the MCU to crash.

There are no other interrupts going on while im recieving characters. The only thing running is the "FIFO_POP" character processing into the while(1) section.

Could it be crashing because when a new character enters, the previous interrupt is still going on? (baud Rate 57600, 8-N-1 Flow:None)

Thanks!

There are 11 types of people in the world. Those who understand binary, those who don't and those who make nerdy pun about it.

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

Sounds like a buffer overflow. Do you have a ring buffer on the RXC?

BTW you micro is not an Xmega so I'll move this from that forum to AVR.

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

Quote:
Is Sending characters too fast a potential cause for a reset?

It shouldn't but it can if incorrect technique is used.
Shows us your ISR & buffering code!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

Quote:
Is Sending characters too fast a potential cause for a reset?

It shouldn't but it can, if incorrect techniques are used.
Perhaps shows us your ISR & buffering code!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

^^^^^^you see, that's what happens if you don't use flow control; you can sometimes get doubling up.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

There is already a thread floating around here about this problem. It seems some of the early production 1284s, when operated at near maximum clock, will reset when receiving serial data.
I have only used it with the internal 8 Mhz clock so I haven't experienced this problem, but its worth looking into.

Heres a link to a thread on the topic...

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=120716&start=0

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

I haven't seen any indication that this is fixed in "new" 1284s. In fact, recent porting of the Arduino framework to 1284 has resulting in a new flurry of such complaints.

There never were any errata or admissions from Atmel, were there?

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

Hmm, interesting post from westfw. I didn't know that Arduinos were using 1284s now. I just did a cursory search on the Arduino forums, but didn't turn up any problems corresponding to this one.

If there's anyone out there experiencing this problem, using parts with a fairly recent date code, I'd be interested in hearing from you.

I recently took delivery of a some TQFP 1284Ps, with date codes indicating March of 2012. It would require some hacking at one of my PCBs to inject a clock, but I might try cranking it up to see what happens.

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

Official Arduinos aren't using 1284s. It's just that a few of the advanced users noticed that it has more memory than any other DIP AVR, and someone designed a PCB, and modified the core libraries (644 was already supported), so now Arduino software SHOULD work on ATmega1284.

The bootloader has been having problems. Relevant thread: http://arduino.cc/forum/index.ph...
The smoking gun was that the same bootloader code worked fine on UART1 of the same chips, with no other changes. The last word that it was working on UART0 with resonators but not crystals (given a fuse change.)
We didn't get to the point of checking date codes :-(

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

Do you have "full swing" settings for xtal? usart0 is right next to xtal pins and might be problematic (and also reason why usart1 worked for "arduinos")

Computers don't make errors - What they do they do on purpose.

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

@westfw I read the Arduino thread, seems similar to the thread here from a while back.

One new twist I noticed however was crystal vs resonator. Seems resonator clocked parts work OK, while crystals were iffy.

I can inject a clean square wave , but if the problem is the chips oscillator an external clock won't shine any light on it.

Still, it seems like a worthy experiment.

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

At 57600 8N1, you have 5760 characters per second, max, from the terminal. Thats just over 170us per character. I defy you to manually send characters that fast! I'd put the practical max at maybe 50ms per character.

Now, if the terminal is packetizing - that is, storing until, lets say, a carriage return, then dumping, you will get them at the fastest possible rate, start bit immediately following stop bit of the preceding character. But, your code still has 170+ microseconds to receive each character and push into the buffer. Unless you are doing something that takes a whole lot of time, that should be dead simple. An example of something that might take too much time is implementing a FIFO that involves pushing all of the characters down, into the FIFO (shift location of characters in memory rather than shifting a pointer).

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

I have a 20Mhz crystal that works fine until then.
The reset of the MCU (1284 not p) occurs only when I send data with the RX0 interrupt is enabled.(the interrupt part sends the character to an empty callback function) If I send data with the interrupt disabled and RX and TX enabled it does not reset. Heres my USART_init function



void USART_Init(void)
{
  /* Set Baud Rate */

  UBRR0H = (uint8_t)(USART_UBBR_VALUE>>8);
  UBRR0L = (uint8_t)USART_UBBR_VALUE;
  /* 8 bits, no parity, 1 SB, U2X enabled */
  UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
  UCSR0A = (1<<U2X0);
  /* Enable RX/TX, Enable RX Intr */
  UCSR0B = ((1<<RXEN0)|(1<<TXEN0));//|(1<<RXCIE0)); <----Interrupt disabled, Pins Enabled
  USART_Flush();
}

Another thing is I'm flashing the chip with the setting of the (ATMEGA1284 not p) and the device ID is OK.

In the project properties->Device section I can build in 1284p or not p. if I build and flash the chip in the 1284(not p) mode it will not work. It is as if I flashed a big nothing. If i do it again but in the 1284p mode...everything works fine. I tried 3 times...just to be sure...but it worked so I didn't ask much questions.

I don't know if it has with the whole UART problem...Even if I wanted to go from UART0 to UART1 my PCB is already done.

There are 11 types of people in the world. Those who understand binary, those who don't and those who make nerdy pun about it.

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

Quote:

I have a 20Mhz crystal that works fine until then.

Can you confirm the fuses are configured for "full swing" mode?

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

No it is not. My crystal is set on EXTXOSC_8MHZ_XX_16KCK_4MS1.
After a brief research on the internet I just realized that I am in fact using a full swing osc.

It worked pretty well...until this UART problem.

What are the potential consequences of not setting the fuses in the appropriate OSC mode? (like I did)

Does it relate to the issues I was experiencing?

There are 11 types of people in the world. Those who understand binary, those who don't and those who make nerdy pun about it.

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

Quote:

What are the potential consequences of not setting the fuses in the appropriate OSC mode?

The drive levels to the crystal are not high enough and it either never starts to resonate or the resonance is sporadic and will affect CPU operation. As posts above show I think it's been noted before that 1284 is particularly sensitive to this. The bottom line is that for crystals over 8MHz (and perhaps even lower) the full swing mode must be chosen even though it is slightly more power hungry. As KIIV_cz also noted above the UART0 lines are adjacent the crystal so activity on them could be the thing that pushes it over the brink.

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

I tried an experiment today. This 3.3 volt board was designed for internal 8Mhz RC clock. I re-fused it for external clocking, and connected a generator. I loaded a simple 'echo' program which was set up for 115.2 Kbaud.

I started at 7.373 Mhz to verify the echo worked. Then 9.216, then 11.06, 12.9, then at 14.75 I started getting 'garbage' echos, and the chip seems to 'lock up'. I don't think it 'reset' (programmed to blink LED 10 times before main loop, doesn't show on the O'scope).

If I get some time next week I'll bypass the regulator and apply 5 volts to see what happens.