ATmega64 debe reiniciarse después del encendido

Estoy usando un ATmega64A para mi proyecto con ESP8266 y RFM75. Pero el ATmega64 se cuelga al encenderse y tengo que hacer un reinicio bajo para que mi código funcione. Estoy usando un cristal externo de 8 MHz.

He conectado todos los pines VCC y GND correctamente con condensadores de 0,1 µF en cada PIN VCC. El pin RESET se eleva con resistencias de 10 kΩ y se conectan condensadores de 10 µF entre RESET y GND (también probé condensadores de 0,1 µF).

Necesito algún tipo de ayuda para salir de este problema. Todos los comentarios o sugerencias serán apreciados.

EDIT 1: Mi esquema adjunto aquí.Esquema ATmega64.

He medido el nivel de voltaje en el PIN DE REINICIO en la condición de encendido.

RESET PIN voltaje al encender. RESET PIN tensión al encender

EDICIÓN 2 : solo el código de parpadeo LED funciona bien en el mismo hardware, lo he comprobado muchas veces al encender/apagar el suministro. Creo que Code tiene algunos problemas. Estoy tratando de averiguarlo.

EDICIÓN 2: he mostrado un código de parpadeo de LED simple en el inicio antes de iniciar la inicialización de ESP8266 o RFM. También tengo una opción de depuración en mi código. ATmega64 UART1 se utiliza como terminal de depuración. He intentado hacer parpadear el LED antes de la inicialización de depuración. ¡El parpadeo de LED funciona de maravilla! Tengo una función en la terminal de depuración para imprimir un banner al inicio. Imprime la fecha y la hora de las causas de compilación y reinicio y una versión del código. cuando comenté la función, mi código comenzó a funcionar bien. Lo he probado muchas veces en diferentes placas por lo que desaparece el tema a partir de entonces. aquí la función que he quitado.

    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"));
}

¿Cuál sería la causa del problema RESET del ATmega64 con este código? ¿Se debe a la obtención de datos de la memoria del programa para imprimir a través de UART? Todavía estoy tratando de ir a la causa raíz de este problema. Si alguien tiene alguna idea sobre esto, por favor arroje algo de luz sobre esto. Gracias.

Sería útil ver parte de su código de configuración o al menos una descripción general. Parece que su código se está ejecutando en un estado inesperado durante el inicio. La solución rápida y sucia (y no recomendada) podría ser tener el bucle MCU (vacío para bucle) unas miles de veces al inicio, para esperar a que todo se estabilice.
Taher: se me ocurren algunas posibles causas relacionadas con el hardware para este comportamiento. Sin embargo, para considerar esas posibles causas de manera eficiente, deberá (a) proporcionar un esquema completo y correcto y fotos del hardware; (b) indique qué equipo de prueba tiene disponible, por ejemplo, un osciloscopio. O solo DMM? (c) explicar la historia del diseño, por ejemplo, ¿funcionó un prototipo anterior? Si es así, ¿qué ha cambiado desde ese diseño? (d) explique qué solución de problemas ha realizado hasta ahora, por ejemplo, ¿ha intentado ejecutar un programa simple de "parpadeo de LED" en la MCU y desconectar todo lo demás de la MCU?
Es muy probable que su fuente de alimentación aumente demasiado lentamente. Puede agregar un supervisor de suministro (detector de caídas de tensión) como el MAX809 ( onsemi.com/pub/Collateral/MAX809S-D.PDF ) para garantizar un inicio uniforme. Estos primeros ATMega tenían el POR establecido en solo alrededor de 1,5 V (a diferencia del BOD establecido en 2,5 V), por lo que si la fuente de alimentación aumenta lentamente desde ese nivel, es posible que el retraso en el inicio sea demasiado corto y el procesador se cuelgue.
@Jack: de acuerdo (+1), este es uno de los posibles problemas que consideré, y es por eso que pregunté sobre la disponibilidad de un 'alcance' para medir el tiempo de subida de la fuente de alimentación. Cuando el OP revela el historial de eventos que solicité, también puede contener puntos de datos que son relevantes (por ejemplo, tal vez un prototipo anterior funcionó con una fuente de alimentación diferente). Esperemos que el OP responda con algunas actualizaciones y datos...
@SamGibson: a) Claro que proporcionaré un esquema completo, en este momento no puedo hacerlo. b) Tengo DMM, DSO, osciloscopio disponibles aquí. c) Sí, los prototipos anteriores funcionaron bien. en ese momento estaba ejecutando la CPU a 5V, ahora la CPU se ejecuta a 3V3. ese es el unico cambio. No cambié componentes ni esquemas, pero sí diseño de PCB en prototipos posteriores. también este problema RESET, en el nuevo prototipo, observado muy a menudo. Algunas veces funciona correctamente, en algún momento necesita un reinicio externo.
@SamGibson: d) Acabo de agregar Crystal y cambié los bits de Fusible y los Capacitores de desacoplamiento y el capacitor RESET. No he probado código diferente en hardware como Blink LED, pero lo haré y lo actualizaré pronto.
@JackCreasey: Le ruego me disculpe, pero ¿puede explicarme esto mejor?
En los ATMega, tiene dos condiciones de reinicio muy importantes... las establecidas por el reinicio de encendido (Vpot), que al aumentar la potencia es de aproximadamente 1,4 V... cuando se supera este umbral, se ejecutará el tiempo de encendido (t(TOUT)). . Sin embargo, el VCC del procesador debe ser de al menos 2,5 V en el '64L y 3,6 V en el '64. Si VCC está por debajo de estos niveles, es posible que el procesador no funcione... puede bloquearse. Lea la hoja de datos sobre la Tabla 19 Características de restablecimiento para obtener más detalles... y especialmente la Nota 2. ...si el suministro no aumenta lo suficientemente rápido, puede esperar en el encendido.
@JackCreasey Muchas gracias, lo miraré y volveré aquí.
@TaherKawantwala - Gracias. Aunque a esas respuestas les faltaba algo de información (por lo que no entendí completamente los detalles finos), un breve análisis es que tiene una situación de solución de problemas casi ideal: el prototipo anterior funcionó, pero este tiene su síntoma de "a menudo necesita reinicio manual". Por lo tanto, puede comparar las placas que funcionan y las que fallan para encontrar los errores causados ​​en el diseño actualizado. Dijiste "No cambié componentes", pero tus otros comentarios dicen que lo hiciste. De todos modos, si su trabajo con Jack no tiene éxito, existen técnicas de solución de problemas que se pueden aplicar. ¡Buena suerte!
Intente eliminar el condensador de reinicio y la resistencia por completo del circuito. Dejar el pin de reinicio flotando causará POR sin ninguna influencia (y debería ser una configuración compatible). El pin de reinicio tiene un pull-up interno de 30-60 kOhm.
@Anónimo Eliminé Cap y RES de un PIN de REINICIO, todavía hay un problema. Funciona en algún momento, pero en algún momento tengo que tirar de RESET LOW para hacer funcionar el microcontrolador.
Además, puede optar por realizar una medición de alcance de la transición de energía cuando se enciende el dispositivo y, si no encuentra nada especial allí, solicite el soporte de Atmel. Interesante, no veo cómo abrir un ticket de soporte con ellos, si fuera un desarrollador, sería uno de los principales obstáculos en el uso de sus productos. Probablemente necesite iniciar sesión en "mi Atmel" para poder crear tickets de soporte.
¿Tiene un enlace serie o cualquier otra cosa que aplique una señal a un pin de E/S antes de encenderlo? Ese tipo de cosas pueden retroalimentar parcialmente un procesador a través de los diodos de protección y hacer que el encendido no sea realmente un encendido real.
¿Ha cambiado el fusible de nivel de apagón? Si está configurado a 4V todavía causará problemas.

Respuestas (1)

Algunos consejos:

  1. Los AVR tienen fusibles de retardo de inicio de reloj (SUT1/SUT0 para ATmega64): verifique si el problema ocurre en diferentes configuraciones de retardo de inicio.

  2. Utilice la detección de caídas de voltaje (también una configuración de fusible).

  3. Intente agregar un ciclo de espera ocupada al principio.