fallos de uC de 32 bits y detectar el fallo como usuario

-2

Estoy trabajando con 32 bit ifx uc.

He visto errores de campo de bits en los registros, errores de RAM, errores de flash como muy comunes ...

¿podría decirme algún problema más en el que un uC de alto nivel de 32 bits tenga errores?

¿O recursos para encontrar tal información?

Tengo que crear programas de prueba para atraparlo.

Esperando tu respuesta,

saludos cordiales ...

    
pregunta user3777

3 respuestas

6

Este tipo de error es muy difícil de detectar utilizando software. Esencialmente, estás tomando algo que es inestable cuando ejecutas el software y ejecutas el software para detectar el error. Y si te atrapa el error, ¿entonces qué? Si un registro se está corrompiendo, tendrá dificultades para sondear las señales dentro de la CPU. Esto podría ser un esfuerzo inútil. En su lugar, me concentraría en los conceptos básicos de la ingeniería eléctrica.

Esto es lo que estaría viendo:

  1. Poder. Si el poder es cuestionable, entonces podría tener problemas. Aparte del nivel promedio de DC, hay que mirar el ruido. Esto puede ser difícil de probar, ya que necesita mirar el ruido directamente a los pines de alimentación de la CPU usando un buen alcance con consideraciones cuidadosas de la sonda o-scope para que no detecte otro ruido. Revisa los recuerdos externos también.

  2. Pines de alimentación. Realmente he visto que los chips funcionan con algunos o todos los pines de alimentación desconectados. En un caso, los pines de potencia PLL para un chip no estaban alimentados, pero el chip funcionaba en su mayoría bien, excepto en uno o dos casos específicos. Revisa los recuerdos externos también.

  3. Relojes. Asegúrese de que los relojes tengan buena integridad de señal. Al igual que la alimentación, esto debe comprobarse en los pines de la CPU con una buena configuración de la sonda.

  4. Restablecer. Asegúrese de que no haya fallos ni ruidos en las líneas de reinicio. Un fallo momentáneo podría hacer que solo una parte de la CPU se reinicie, sin que se produzcan problemas de finalización.

  5. Conectores JTAG / Debug. ¿Están los pasadores tirados hacia arriba o hacia abajo, o se dejan flotando? El ruido en estos pines puede causar un comportamiento realmente extraño.

  6. Pines "no utilizados" flotantes. En algunos casos, las CPU pueden tener un gran número de pines de E / S no utilizados que deben ser extraídos, controlados o vinculados a un nivel lógico válido. Incluso si el pin no se usa, un pin flotante puede causar mucho ruido dentro de la pieza.

  7. La mala integridad de la señal en la PCB puede causar lugares de ruido que no desea. Una placa que vi tenía largas huellas en un bus de memoria, y nada se terminó correctamente. Hubo 2 voltios de rebasamiento / subestimación en esas señales que ocasionalmente causan que algo "no relacionado" falle. En ocasiones no raras, causaría un bloqueo y algunas fichas literalmente explotarían.

respondido por el user3624
1

He escrito algunos códigos para aplicaciones que requieren una resistencia extrema a fallar de manera insegura. El código se escribió completamente en lenguaje ensamblador y se guardaron dos copias de muchas variables importantes, con un delta fijo entre ellas. En lugar de calcular y almacenar el valor de la segunda variable en función de la primera, el código sería algo así como:

' Code to add reg1a to reg2a and maintain delta invariants
  if reg1b  reg1a + REG1_DELTA then error
  if reg2b  reg2a + REG2_DELTA then error
  reg2b += reg1b - REG1_DELTA
  reg2a += reg1a
  if reg2b  reg2a + REG2_DELTA then error

Cualquier registro que se dañó se marcaría inmediatamente como un error. Sería improbable que varios registros se corrompan de tal manera que evite casualmente un error. Debido a que los registros 'b' no se calculan en base a los registros 'a', un error que golpea un registro 'a' no causará el correspondiente cambio correspondiente en un registro 'b', sin importar cuándo ocurra.

    
respondido por el supercat
0

Por lo que recuerdo, hay algunos procedimientos de prueba estándar para microcontroladores en el estándar IEC 60730 Clase B. Lo mejor que pude encontrar en una búsqueda rápida fue una Nota de aplicación de Freescale . OTOH No puedo decir si estas cosas mejoran la confiabilidad (los estándares a veces son estúpidos).

    
respondido por el jpc

Lea otras preguntas en las etiquetas