Estoy trabajando en un proyecto que no es de seguridad y, como parte de las pruebas de inicialización, quería verificar que la memoria interna de LPC1778 funcione correctamente antes de comenzar la aplicación.
No tengo la intención de probar todas las direcciones ya que no es factible para la aplicación. Estoy planeando implementar esta prueba 3 en 1 (ALU, RAM y ROM) de la siguiente manera:
1. Almacene una matriz de 32 números en ROM (matriz const) cuyos valores de miembro son potencias de 2. Ejemplo-> 1,2,4,8... hasta 2 potencia 32 (ya que LPC1778 tiene un bus de datos de 32 bits)
2. Lea estos valores de la ROM (matriz constante) 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).
¿Es esto suficiente para probar o también debo verificar si hay un bus de direcciones corto (si están en cortocircuito e intento escribir en una ubicación no válida, no se activará el controlador de excepciones?) Además, también debo verificar otras operaciones de la ALU
como suma, resta, NO, XOR, etc. También tengo la suma de verificación del código almacenada en un flash externo que se comparará calculándola en el código durante el tiempo de ejecución. (Suma de comprobación calculada en código == Suma de comprobación leída desde flash)
Alguna sugerencia. Por favor ayuda.
Estoy usando Keil IDE.
¿A qué le temes? ¿Que una ruta interna entre puertas dentro del chip se interrumpa o se cortocircuite? Si ese fuera el caso, ciertamente significaría que el chip estaba físicamente roto. Quiero decir, roto como en "partido en dos mitades debido a algún estrés térmico". En cuyo caso no funcionaría en absoluto. Lo que está tratando de probar aquí no vale la pena, la probabilidad de que un rastro interno sea incorrecto es más que improbable.
Lo que sería más probable es el trastorno de un solo evento , que no puede evitar mediante pruebas previas (y que es muy difícil de manejar de todos modos, probablemente necesite un núcleo de paso de bloqueo y memoria ECC).
Eventualmente, use algo de CRC para datos críticos en la memoria, para reaccionar en caso de que se corrompa. Eso es lo mejor que puedes hacer.
Verificació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 compilación. Dado que el valor esperado es diferente para cada compilación, esto también atraparía el firmware escrito de forma incompleta (que es mucho más probable que la memoria rota)
Comprobación de ALU: no tiene sentido, de verdad. Una verificación exhaustiva sería una gran cantidad de código, y una verificación rápida probablemente perdería algo. Sin el conocimiento del cableado interno, no sabría qué pruebas tienen sentido (por ejemplo, agregar 0x55555555 a 0x55555555 para verificar si los bits vecinos conectados accidentalmente solo funcionan si la implementación real no está intercalada). El ALU está probado en fábrica, tanto con una inspección óptica antes del embalaje como con un ensayo adecuado a la disposición física que tiene.
AlfaGoku
oscuro
AlfaGoku
oscuro