2
\$\begingroup\$

I am using an ATmega64A for my project with ESP8266 and RFM75. But the ATmega64 hangs on power up and I have to pull reset low to make my code work. I'm using an external 8 MHz crystal.

I have connected all VCC and GND pins properly with 0.1 µF capacitors on each VCC PIN. The RESET pin is pulled high with 10 kΩ resistors and 10 µF capacitors are connected between RESET and GND (I have tried 0.1 µF capacitors as well).

I need a some kind of help to get out of this issue. All comments or suggestion will be appreciated.

EDIT 1: My Schematic attached here. ATmega64 Schematic.

I have measured voltage level on RESET PIN on power-on condition.

RESET PIN voltage on power on. RESET PIN voltage on power on

EDIT 2: Only LED Blinking Code works well on the same hardware, I have checked so many times by switching the supply ON/OFF. I thing Code have some issues. I'm trying to figure it out.

EDIT 2: I have flashed Simple LED blinking code on start up before I start ESP8266 or RFM Initialization. I have a Debug option in my code as well. ATmega64 UART1 is used as Debug Terminal. I have tried flashing LED before Debug Initialization. Led Blinking works like charm! I have a Function in Debug Terminal to print banner on start up. It prints Date time of compile and reboot causes and a version of code. when I have commented the function , my code started working fine. I have tested many time on different boards by the issue disappear from then. here the function which I have removed.

    static void PrintBanner(void)
{
    unsigned char status = MCUCSR;
    unsigned char moreThanOne = 0;

    printf_P(PSTR(CMD_LINE_MSG_WELCOME));
    printf_P(PSTR("Firmware: v%S [Compiled on "__DATE__" "__TIME__"]\r\nBoot cause: "), PSTR(APP_VERSION));

    if(status & (1 << PORF))
    {
        printf_P(PSTR("Power On"));
        MCUCSR &= ~(1 << PORF);
        moreThanOne = 1;
    }
    if(status & (1 << EXTRF))
    {
        if(moreThanOne)
            printf_P(PSTR(", "));
        printf_P(PSTR("External"));
        MCUCSR &= ~(1 << EXTRF);
        moreThanOne = 1;
    }
    if(status & (1 << BORF))
    {
        if(moreThanOne)
            printf_P(PSTR(", "));
        printf_P(PSTR("Brown-out"));
        MCUCSR &= ~(1 << BORF);
        moreThanOne = 1;
    }
    if(status & (1 << WDRF))
    {
        if(moreThanOne)
            printf_P(PSTR(", "));
        printf_P(PSTR("Watchdog"));
        MCUCSR &= ~(1 << WDRF);
        moreThanOne = 1;
    }
    if(status & (1 << JTRF))
    {
        if(moreThanOne)
            printf_P(PSTR(", "));
        printf_P(PSTR("JTAG"));
        MCUCSR &= ~(1 << JTRF);
        moreThanOne = 1;
    }

    printf_P(PSTR(" Reset.\r\n"));
}

What would be the cause for the RESET issue of the ATmega64 with this piece of code? Does it because of fetching data from program memory to print over UART? Still I'm trying to go to root cause for this issue. If anyone have any idea about this kindly throw some light on it. Thanks.

\$\endgroup\$
  • \$\begingroup\$ It would be helpful to see some of your setup code or at least an overview. It sounds like your code is running into an unexpected state during startup. The quick and dirty (and not recommended) solution might be to have the MCU loop (empty for loop) a few thousand times on startup up, in order to wait for everything to stabilize. \$\endgroup\$ – John Evans Apr 1 '17 at 20:19
  • \$\begingroup\$ Taher - I can think of a few potential hardware-related causes for this behaviour. However to consider those potential causes efficiently, you would need to (a) supply a complete, correct schematic & photos of the hardware; (b) list what test equipment you have available e.g. oscilloscope? Or only DMM? (c) explain the history of the design e.g. did a previous prototype work? If so, what has changed since that design? (d) explain what troubleshooting you have done so far e.g. have you tried running just a simple "blink LED" program in the MCU and disconnecting everything else from the MCU? \$\endgroup\$ – SamGibson Apr 1 '17 at 22:47
  • 3
    \$\begingroup\$ It's highly likely that your power supply rises too slowly. You can add a supply supervisor (brownout detector) like the MAX809 (onsemi.com/pub/Collateral/MAX809S-D.PDF) to ensure consistent startup. These early ATMega's had the POR set at only about 1.5 V (as opposed to BOD set at 2.5 V), so if the power supply then rose from that level slowly it's possible the startup delay is too short and the processor hangs. \$\endgroup\$ – Jack Creasey Apr 2 '17 at 0:50
  • \$\begingroup\$ @Jack - Agreed (+1), this is one of the potential issues I considered, and it's why I asked about the availability of a 'scope, in order to measure that power supply rise time. When the OP reveals the history of events which I asked for, it might also contain data points which are relevant (e.g. perhaps a previous prototype worked with different power supply). Let's hope the OP replies with some updates and data... \$\endgroup\$ – SamGibson Apr 2 '17 at 1:29
  • \$\begingroup\$ @SamGibson: a) Sure I will provide complete schematic, right now I'm not able to do that.b)I have DMM, DSO, Oscilloscope available here. c) Yes previous prototypes worked well. at that time i was running CPU at 5V, now CPU is running at 3V3. that is the only change. I didn't change components or schematic but PCB Design in later prototypes. also this RESET issue, in new prototype, observed very often. Some times it works correctly some time need external reset. \$\endgroup\$ – Taher Kawantwala Apr 2 '17 at 5:28
1
\$\begingroup\$

Some hints:

  1. AVRs have clock startup delay fuses (SUT1/SUT0 for ATmega64) - check if problem happens at different settings of the startup delay.

  2. Use brownout detection (also a fuse setting).

  3. Try adding a busy-wait loop at the beginning.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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