¿Cómo determina si un nuevo microcontrolador está defectuoso?

11

Nunca traté que las partes sean defectuosas desde Digikey, pero los 3 nuevos Atmel ATmega164A que he recibido muestran un comportamiento extremadamente extraño.

Lo reduje a algo que tenía que ver con el reloj y resultó que la señal de reloj resultante del supuestamente oscilador interno "calibrado de fábrica" oscilaba entre 650-700 kHz en lugar del sólido 1 MHz que se supone que es. Pude escribir en el byte de calibración para obtener esto muy cerca de 1 MHz (aún con cierta inestabilidad) y la mayoría de las cosas funcionan pero los UART simplemente no se comportan correctamente, parece que emiten un flujo continuo de pulsos cortos, sin importar lo que les pidas que hagan.

He tratado con la versión de bajo consumo de este microcontrolador anterior (164P) con cero problemas y decidí dejarlo en su lugar y verificar la salida del reloj en eso, y es un sólido de 1 MHz sin fluctuaciones. Me inclino hacia la conclusión de que estos chips 164A son defectuosos, pero ¿habría otras pruebas que podría intentar confirmar?

Editar: Pensé que describiría el proceso mediante el cual estoy midiendo el reloj. He habilitado el bit de fusible de salida de reloj y he medido el pin apropiado con un analizador lógico que muestrea a una velocidad muy alta. Tengo un programa que escribe en el registro de calibración OSCCAL y he podido probar & error mi camino a 1 MHz.

Editar # 2: Después de una investigación adicional, parece que el microcontrolador comienza a actuar después de un cierto umbral de tamaño de programa . Un proyecto básico con un solo archivo fuente que destella un LED parece estar bien, pero compilar y enlazar en cualquiera de mis otros archivos (por ejemplo, la biblioteca de UART o lo que sea) sin siquiera llamar a esos métodos hace que el microcontrolador se comporte El comportamiento descrito anteriormente. Las conexiones de alimentación están bien y se ha realizado un desacoplamiento adecuado. No tengo tiempo para depurar esto más en este momento, por lo que hemos seguido adelante con la versión de bajo consumo. No estoy seguro de dónde podría ser 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. Tengo confianza en el diseño de nuestro directorio y descartaría los problemas de poder. Desafortunadamente, realmente no puedo elegir la respuesta correcta, por lo que dejaré esta pregunta tal como está, tal vez vuelva a abordar el problema en el futuro. Gracias a todos los que proporcionaron comentarios o respuestas perspicaces, podrían ser útiles para alguien más con problemas de la UC listos para usar.

    
pregunta Jon L

2 respuestas

3

Es raro tener ese tipo de falla. Puede esperar ver un poco más de ruido en un pin, o tener ese pin completamente no funcional. 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 el poder. ¿Están todos los pines de encendido / encendido conectados? ¿Las clavijas de E / S están accionadas o tiradas hacia arriba o hacia abajo? Etc.

Pero todavía queda la posibilidad de que las partes sean malas. Es raro, pero no inaudito. La única forma real de saberlo es obtener algunas piezas más de un proveedor diferente y probarlas. Si funcionan, entonces necesitas investigar más y ver si los mataste en el manejo / soldadura o si realmente provienen de Digikey.

    
respondido por el user3624
1

Una vez tuve un problema muy similar con las partes básicas de Microchip. Estábamos arruinando la programación de ICSP y estábamos encontrando una manera de borrar el ajuste del oscilador, lo que causaba graves errores en la precisión del reloj interno. Asegúrese de que su dispositivo de programación y / o sus herramientas de programación se conecten correctamente y se usen correctamente.

No hay una manera fácil de verificar la precisión del oscilador sin programar las partes, así que solo escribo un programa trivial de conmutación de puertos (uno que no hace nada más que mover una línea de E / S) y tengo a alguien De lo contrario programe las partes, preferiblemente con diferente hardware de programación. Una vez que verifique el movimiento, puede volver a flashear con su propio código y ver si el problema persiste.

    
respondido por el Adam Lawrence

Lea otras preguntas en las etiquetas