I have an atmega644p on a breadboard. Minimal setup, just a 16Mhz resonator, 10K pull-up on the reset pin and a LED on a digital IO pin. Power (3.3v) is provided by an FTDI adapter and its RX/TX lines are connected to the 644p on Serial0.
The problem I have is after every few bytes of data received on the serial RX pin, the 644p will reboot. This occurs even if I don't initialise or read the serial port. ie. It will reboot even with a blank sketch!
I'm using IDE v 1.5.6r2 but have also tried 1.0.5. I'm using the Arduino core with a variant (arduino_pins.h) from the mighty1284p project GitHub - maniacbug/mighty-1284p: Mighty 1284P Platform for Arduino. I've also tried the mighty1284p core. I've tried both the Arduino IDE serial monitor and an external serial terminal app.
Anyone got any ideas what's going on?
Here's the sketch I'm using - just enough to detect a reboot.
void setup()
{
pinMode(1,OUTPUT); // pin 1 is a digital IO on the 644p
digitalWrite(1,HIGH);
delay(100);
digitalWrite(1,LOW);
}
void loop()
{
}
I am using the IDE's serial monitor to send data to the device.
The minimal code I posted was just to show that even without any serial code, the processor reboots on receiving serial data.
Apart from the reboots, sketches seem to work properly and even processing serial code works (e.g. echoing back the character received).
There's not much to show with a diagram. It's an ATmega644p connected via TX & RX to an FTDI board connected via USB to a PC. I'll post a diagram as soon as I can.
You are running out of spec. The Speed Grades graph shows that 3.78V is needed to run & be fully within spec at 16 MHz.
0.1uF caps at each Vcc and Avcc pin are needed.
DTR is not connected - reset is pulled high. That only comes into play if software created Reset was needed, like during a serial download. Bit of a red herring in this discussion. More than likely the lack of decoupling caps and running overspeed are more the issue.
Was there some discussion a while back about issues caused by the proximity of the RXD0 pin and the XTAL1 pin? Was there anything to that? If so, was a solution found? (Not to take anything away from Crossroads' reply -- all good points there.)
Some have reported better results with Low fuse set to 0xf7 vs 0xff I think. Not 100% sure on the values. I have not seen any problems reported with my boards using 0xff. I pay careful attention to grounding & traces around the crystal.
I agree with Crossroads. You've already violated the manufacturers rules . The datasheet is like a bible of sorts in that it is a sin to violate what is written in the datasheet. You should expect to continue to have problems as long as you do that and you should not expect to find a solution that does not involve lower the clock speed or raising the supply voltage. One or the other will have to happen before you can rule out overclocking as the cause of your issues. Once you raise the voltage, and continue to see the same issue , then you can proceed with troubleshooting the issue with the knowledge that it is not related to clock speed. You really can't cheat when it comes to uC specs.They are what they are and thousand of man hours and $ have gone into ensuring that the information is reliable. the GAMERS who "cheat" resort to special cooling techniques that keep the temp down. They still obey the laws of physics.
Thanks all for the great responses. I didn't realise I was running out of spec at 3.3v/16Mhz, so after trying at 5V, the problem went away! I need to pay more attention to data sheets
