Prueba de ALU, RAM y ROM para LPC 1778

Navega tus respuestas
1

Estoy trabajando en un proyecto que no es de seguridad y, como parte de las pruebas de inicialización, quería comprobar si la memoria interna del LPC1778 funciona correctamente antes de comenzar la aplicación.

No tengo la intención de probar todas las direcciones ya que no es posible para la aplicación. Estoy planeando implementar este 3 en 1 (ALU, RAM y ROM) de la siguiente manera:

1. Almacene una matriz de 32 números en la ROM (matriz const) cuyos valores de miembro son potencias de 2. Ejemplo- > 1,2,4,8 ... hasta 2 de potencia 32 (ya que LPC1778 tiene un bus de datos de 32 bits)

2.Lea estos valores de la ROM (matriz const) y escríbalos en una matriz de tamaño 32 ubicada en la RAM (matriz no constante asignada en la pila llamando a una función que declara dicha matriz localmente).

3. Compare cada valor en la matriz local con un valor calculado por la ALU (desplazamiento a la izquierda bit a bit).

¿Esto es suficiente para probar o también debo verificar que no haya un bus de dirección (si están en corto y trato de escribir en una ubicación no válida, no se activará el controlador de excepciones)? Además, también debo verificar otras operaciones por parte de ALU, como la suma, resta, NO, XOR, etc. También tengo el Code Checksum almacenado en una memoria flash externa que se comparará con el cálculo en el código durante el tiempo de ejecución. (La suma de comprobación se calcula en el código == La suma de comprobación se lee en flash)

Cualquier sugerencia. Por favor ayuda.

Estoy usando Keil IDE.

    
pregunta Akshay Immanuel D

2 respuestas

4

¿A qué le tienes miedo? ¿Que una ruta interna entre puertas dentro del chip se rompa o se acorte? Si fuera el caso, ciertamente significaría que el chip estaba físicamente roto. Quiero decir, roto como en "dividido en dos mitades debido a un poco de estrés térmico". En cuyo caso no funcionaría en absoluto. Lo que intenta probar aquí no vale la pena, la probabilidad de que una traza interna sea incorrecta es más que improbable.

Lo que sería más probable es evento único molesto , que no puede evitarse mediante pruebas previas (y que es muy difícil de manejar de todos modos, probablemente necesitarías algo de núcleo de paso de bloqueo y memoria ECC).

Finalmente, use un CRC para datos críticos en la memoria, para reaccionar en caso de que se corrompa. Eso es lo mejor que puedes hacer.

    
respondido por el dim
2

Comprobación de memoria: ejecute un CRC sobre todo el contenido de la memoria, excepto el lugar donde almacena el valor esperado, y determine el valor esperado durante el tiempo de construcción. Dado que el valor esperado es diferente para cada compilación, esto también detectaría el firmware escrito de forma incompleta (lo cual es mucho más probable que la memoria rota)

Verificación de ALU: no tiene sentido, realmente. Una comprobación exhaustiva sería una gran cantidad de código, y una comprobación rápida probablemente se pierda algo. Sin el conocimiento del cableado interno, no sabría qué pruebas tienen sentido (por ejemplo, agregar 0x55555555 a 0x55555555 para verificar si hay bits adyacentes conectados accidentalmente solo funciona si la implementación real no está intercalada). La ALU se prueba en fábrica, tanto con una inspección óptica antes del embalaje como con una prueba apropiada para la disposición física que tiene.

    
respondido por el Simon Richter

Lea otras preguntas en las etiquetas

Analizador de espectro: Resolución de ancho de banda frente al tiempo de adquisición ¿Diseñando un circuito que calcule la distancia de Hamming?