Nunca me he ocupado de piezas defectuosas directamente de digikey, pero 3 nuevos Atmel ATmega164A que he recibido han mostrado un comportamiento extremadamente extraño.
Lo reduje a algo relacionado con el reloj y resultó que la señal de reloj resultante del oscilador interno supuestamente "calibrado de fábrica" oscilaba entre 650-700 kHz en lugar del sólido 1 MHz que se supone que debe ser. Pude escribir en el byte de calibración para acercarme mucho a 1 MHz (todavía con algo de fluctuación) y la mayoría de las cosas funcionan, pero los UART simplemente no se comportan correctamente, parecen generar un flujo continuo de pulsos cortos sin importar lo que les pides que hagan.
He tratado con la versión de baja potencia de este microcontrolador antes (164P) sin problemas y decidí colocarlo en su lugar y verificar la salida del reloj, y es un 1 MHz sólido sin fluctuaciones. Me inclino hacia la conclusión de que estos chips 164A son defectuosos, pero ¿habría alguna otra prueba que pudiera probar para confirmarlo?
Editar: Solo pensé en describir el proceso por el cual estoy midiendo el reloj. Habilité el bit de fusible de salida del reloj y medí el pin apropiado con un analizador lógico de muestreo a una velocidad muy alta. Tengo un programa que escribe en el registro de calibración OSCCALy he podido hacer pruebas y errores hasta llegar a 1 MHz.
Edición n.º 2: después de una mayor investigación, parece que el microcontrolador comienza a actuar después de un cierto tamaño de programalímite. Un proyecto básico con un solo archivo fuente que parpadea un LED parece estar bien, pero compilar y vincular cualquiera de mis otros archivos (por ejemplo, biblioteca UART o lo que sea) sin siquiera hacer una llamada de función a esos métodos hace que el microcontrolador se comporte en el comportamiento descrito anteriormente. Las conexiones de alimentación están bien y se ha realizado un desacoplamiento adecuado. No tengo tiempo para depurar más esto en este momento, así que hemos seguido adelante con la versión de bajo consumo. No estoy seguro de dónde podría estar exactamente el problema: 1) 164A y 164P no son compatibles con el código 2) El procedimiento de programación es diferente para estos dos uC 3) Las unidades están defectuosas. Confío en el diseño de nuestra placa y descartaría problemas de alimentación. Desafortunadamente, realmente no puedo elegir una respuesta correcta, así que dejaré esta pregunta como está, tal vez Volveré al problema nuevamente en el futuro. Gracias a todos los que proporcionaron comentarios o respuestas perspicaces, pueden ser útiles para alguien más con problemas de uC listos para usar.
Es raro tener ese tipo de falla. Es posible que espere ver un poco más de ruido en un pin, o que ese pin no funcione en absoluto. Pero tenerlo "algo de trabajo, pero no de una manera útil" es raro. Sospecho que hay problemas de diseño que están causando los problemas y tienen algo que ver con la diferencia entre el 164A y el 164P. Dado que el jitter es alto, miraría las cosas relacionadas con la energía. ¿Están conectados todos los pines de alimentación/tierra? ¿Están los pines de E/S impulsados o tirados hacia arriba o hacia abajo? Etc.
Pero aún queda la posibilidad de que las piezas sean malas. Es raro, pero no inaudito. La única forma real de saberlo es obtener más piezas, de un proveedor diferente, y probarlas. Si funcionan, entonces debe investigar más a fondo y ver si los mató al manipularlos o soldarlos o si realmente procedían de Digikey.
Una vez tuve un problema muy similar con las piezas básicas de Microchip. Estábamos estropeando la programación ICSP y estábamos encontrando una forma de borrar el ajuste del oscilador, lo que provocaba graves errores en la precisión del reloj interno. Asegúrese de que su accesorio de programación y/o sus herramientas de programación estén conectadas correctamente y se estén utilizando correctamente.
No hay una manera fácil de verificar la precisión del oscilador sin programar las partes, así que solo escribiría un programa trivial de cambio de puerto (uno que no haga nada más que mover una línea de E/S) y pedirle a alguien más que programe el partes, preferiblemente con hardware de programación diferente. Una vez que verifique el movimiento, puede volver a actualizar con su propio código y ver si el problema persiste.
Kellenjb
Kortuk
jon l
Kellenjb
jon l
olin lathrop
garrett fogerlie
jon l