2
\$\begingroup\$

I have an ATmega644 connected to another device using the UART. After receiving a few characters on the UART the device resets and/or acts weird. Some examples of this behavior:

  • Code before the main loop is executed again but MCUSR is 0 (i.e. no "real" reset)
  • Code inside the main loop is executed even though the switches connected to the inputs were not pressed (pullups are configured properly).
  • Sometimes the MCU just hangs
  • Sometimes ports that were not configured as outputs act as outputs (e.g. LEDs connected to them light up even though the DDR for that port is 0).

The device is using an external 18.432 MHz crystal and the UART is set to 19200 baud. It is powered with 5V; the RX pin is connected to a 3V3 RPi.

\$\endgroup\$

4 Answers 4

Reset to default
4
\$\begingroup\$

Even if it the problem with this particular setup was something else (as pointed out by another answer), another common reason is that the controller is being operated outside the "safe operating area" with respect to Vcc VS clock speed.

atmega644 Vcc VS clock speed

With 18.432 MHz clock speed the device would require at least about 4.2V to function properly.

\$\endgroup\$
0
2
\$\begingroup\$

Intermittent behavior is often the result of missing or insufficient power decoupling caps near yourcontroller? As a rule of thumb 100nF for every pin labeled Vcc, as close to the controller's power pins as possible. While you're at it, it is always good to double check your power rails with a voltmeter (and an oscilloscope when available).

\$\endgroup\$
0
\$\begingroup\$

This is usually caused by incorrect CKSEL fuses. The ATmega644 needs to be configured to drive the crystal in "Full Swing Oscillator" mode for clock rates higher than 16 MHz; for certain other MCUs this option seems to be a separate fuse bit called CKOPT or CLKOPT

In my case using CKSEL=0111 fixed it but the best way to find out the proper fuses is by using a fuse calculator and then verifying the results against the data sheet before writing them.

\$\endgroup\$
0
\$\begingroup\$

Is it possible that you have connected the RS232 port from the computer directly into the UART pins of the ATmega MCU?

The + and - voltage swings of RS232 port would wreak havoc with the proper operation of the MCU silicon. That havoc could result in any of the failure symptoms that you have described.

Normally a PC computer RS232 port has its lines buffered through a voltage level translator part that converts them to voltage levels compatible with the MCU. If you do not have this in place then a change in your setup is required.

\$\endgroup\$
2
  • \$\begingroup\$ The other device is a raspberry pi which uses 3.3v so nope, that wasn't the problem. But wouldn't the ~15V simply fry the AVR instead of just causing it to act weird? Anyway, I posted this question mostly in case someone else has the same issue so he doesn't waste hours trying to debug it (which is why I immediately posted the answer, too). \$\endgroup\$
    – ThiefMaster
    Commented Dec 5, 2013 at 0:15
  • \$\begingroup\$ @ThiefMaster -- Hehe I did not notice that you were both questioner and the answerer. RS232 ports rarely ever used 15V. Instead the original used +/-12V. Current technology mostly uses charge pump transceivers that produce signaling in the +/-5V to +/-9V range. You never know if a higher voltage signal will outright fry an IC or if it can just create aberrant behavior. Often the strange symptoms may persist for a time and then the part fries after a period of continued torture from the high voltage. \$\endgroup\$
    – Michael Karas
    Commented Dec 5, 2013 at 2:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.