Problema de falla del microcontrolador a medida que aumenta la temperatura

Navega tus respuestas
3

Estoy usando at91sam3s8b (cortex-M3) para mi proyecto. La placa de hardware se conecta a la PC mediante el puerto USB. El firmware contiene algunos algoritmos criptográficos (incluye desplazamientos, Xors, operaciones de sustitución de memoria). La salida del algoritmo es correcta cuando la placa está encendida pero comienza a fallar a medida que pasa el tiempo.

El reloj maestro está configurado como máximo (64 MHz).

mis observaciones son:

  1. si reduzco la frecuencia MCK, la tasa de fallos disminuye. (no está relacionado con la tasa de disminución de frecuencia. La falla se desvanece completamente si uso una frecuencia de 55 MHz)

  2. Si elevo la temperatura de la placa, ¡la falla ocurre antes y si la bajo la temperatura lo suficiente, la falla se desvanece nuevamente!

  3. Algunos microcontroladores fallan (la mayoría de ellos). pero algunos otros no lo hacen. (incluso a una temperatura artificial de 85 grados centígrados)

Las tarjetas y el hardware que funcionan mal se envían a Atmel para su prueba. realizaron algunas pruebas eléctricas y respondieron que no hay ningún problema relacionado con nuestra placa o sus microcontroladores.

¿Alguna idea de cómo o dónde puedo rastrear este problema? ¿Alguna sugerencia técnica?

Editar:

Más información:

  • El proyecto se está construyendo con keil 4.7
  • Las rutinas criptográficas se implementan en ensamblado y c, y están vinculadas al proyecto principal como bibliotecas estáticas (hay 2 bibliotecas separadas. el ensamblado se construye con código fuente).
  • cambiar el orden de las bibliotecas en el proyecto desplaza la falla a otro algoritmo. cambiar el nombre, el lugar o las declaraciones de algunas funciones elimina o desplaza la falla.
  • La placa de hardware es simple. un microcontrolador, un puerto USB y una memoria flash SPI (winbond serial nand flash) + ese pequeño LED. El puerto USB y la memoria flash SPI no se utilizan en el código de prueba simplificado que todavía está defectuoso.
pregunta Taheri

2 respuestas

4

@Taheri: esto no es una respuesta, pero necesitaría 6+ (?) comentarios debido a los límites de espacio y, lamentablemente, los comentarios no pueden tener líneas en blanco para la separación de los distintos puntos. Así que, por favor, trate esto como un comentario que da sugerencias, con un mejor formato y más detalles :-)

De acuerdo con la experiencia, los lectores remotos necesitarán mucho más detalles (algunos de ellos probablemente en la NDA) para eficientemente solucionar este problema en sus tableros, lo que dificulta el logro Esto a través de la ayuda remota. La sugerencia de @BrianDrummond para eliminar su hardware mediante el uso de una placa aprobada por Atmel es buena (+1). He visto problemas similares debido a errores de diseño del sistema, nada que ver con la MCU, que la sugerencia de Brian debería ayudar a eliminar.

Hay algunos enfoques estándar de solución de problemas que no se han mencionado o que no se han concluido. Aquí hay una breve lista no exhaustiva:

(a) Simplifique el código aún más; Parece que has hecho más de esto de lo que se menciona en la pregunta original, pero aún se puede hacer más para identificar exactamente en qué lugar del algoritmo se inicia el resultado incorrecto. Continúe reduciendo la cantidad de código e insertando valores de datos fijos, hasta que no pueda eliminar más códigos sin que el problema "desaparezca". Luego mire el código "mínimo" restante.

Lo que es inusual en ese código "fallido" específico de , que podría explicar por qué está viendo un comportamiento incorrecto, pero la mayoría de los otros usuarios del mismo chip no lo están (de lo contrario, si esto fue fácil de activar , probablemente estaríamos inundados con personas que lo reportan) por ejemplo ¿Está utilizando un periférico inusual, como la unidad de cálculo CRC, que muchas otras personas no utilizarán en sus diseños? ¿Qué otra cosa está haciendo de manera diferente, lo que podría explicar por qué usted está provocando este problema, sin embargo, los otros miles de MCU similares no están fallando de la misma manera?

(b) No acepte que los datos en algún momento durante su algoritmo sean incorrectos (¿de un cálculo de código o de una memoria RAM? ¿O algo más? Es difícil dar sugerencias más precisas sin ver su código ... ). En su lugar, identifique exactamente cómo está mal, comparando los valores reales y esperados en cada punto (¿desplazamiento de bit? ¿Cambio de bit? ¿Resultado de adición defectuoso? Etc), y busque la consistencia (o falta de consistencia) En el mismo tablero y en los tableros cruzados. Luego céntrese en encontrar similitudes / diferencias entre los grupos de tableros afectados de manera similar y no afectados de manera similar. Estos datos específicos pueden ayudar, entre otros usos potenciales, a ver si su código y comportamiento observado coinciden con cualquier errata de Atmel.

(c) ¿Cuál es la historia de este proyecto? ¿Cuándo notaste por primera vez este comportamiento? Si los prototipos anteriores no se vieron afectados, ¿qué diferencia hay entre ellos, en comparación con los tableros en "falla" con los que solicita ayuda?

(d) Considere otros cambios drásticos, por ejemplo, ejecutar el código desde la RAM en lugar de hacerlo desde Flash (asumiendo que tiene un puerto JTAG para poder hacer esto más fácilmente). Si aún se observa el mismo comportamiento de tiempo de ejecución incorrecto cuando se ejecuta desde la RAM como cuando se ejecuta desde Flash, esto elimina una hipótesis de problemas de tiempo al leer desde Flash (¿no es así?) Y eso será un paso más cerca de encontrar la causa raíz .

Editar: (e) ¿Ha intentado trasplantar una MCU de una placa "defectuosa" a una placa "no defectuosa" para ver si el problema se mueve con la MCU o permanece con la PCB y los otros componentes?

Espero que ayude.

    
respondido por el SamGibson
2

Solo algunos pensamientos (no puedo comentar, no tengo suficiente reputación, lo siento)

¿Has mirado la temperatura del regulador? Si alcanza su límite de sobrecalentamiento, puede apagarse lo suficiente como para causar problemas técnicos. Esto podría ser peor para los microcontroladores más débiles.

5v a 1.8v = 3.2V y ??? amps = ??? vatios Esto será disipado en el regulador como calor. También aumentará a medida que aumenta la frecuencia, ya que el consumo de corriente también aumenta con la frecuencia.

Por último, no vi ninguna mención de cómo está desacoplando el suministro al microcontrolador, en todo caso.

Tapa de cerámica de baja ESR justo al lado del microcontrolador, ¿verdad?

Editar: Permítame aclarar esta última afirmación. Probablemente no debería haber menos de tres (3) condensadores de desacoplamiento en esto.

  1. En la entrada / tierra del regulador.
  2. En la salida / tierra del regulador.
  3. En el MCU Vdd / Vss.

El número 3 es el que más se olvida. Todos estos deben ser de baja ESR y condensadores de baja inductancia; Frecuencias auto resonantes mucho mayores que 10Mhz. Y cada uno debe ser lo más cercano a su parte respectiva que permita la ingeniería.

No olvide que el MCU también tiene probablemente su propio regulador incorporado, y que necesitará desacoplamiento. Algunas MCU incluso rompen su regulador interno (¿Vusb pin?) Y también necesitará desacoplar esto explícitamente.

    
respondido por el Charlie

Lea otras preguntas en las etiquetas

Altium deisgner: dibujo de resistencia 4x10k ¿Por qué no funciona la ley de Ohm para este simple circuito?