Я работаю над проектом, не связанным с безопасностью, и в рамках тестов инициализации я хотел проверить внутреннюю память LPC1778 на предмет правильной работы перед запуском приложения.
Я не собираюсь тестировать все адреса, так как это невозможно для приложения. Я планирую реализовать этот тест 3 в 1 (ALU, RAM и ROM) следующим образом:
1. Сохраните массив из 32 чисел в ПЗУ (массив констант), значения элементов которого являются степенью 2. Пример-> 1,2,4,8... до 2 степени 32 (поскольку LPC1778 имеет 32-битную шину данных)
2. Считайте эти значения из ПЗУ (постоянный массив) и запишите их в массив размером 32, расположенный в ОЗУ (непостоянный массив, размещенный в стеке путем вызова функции, которая объявляет такой массив локально).
3. Сравните каждое значение в локальном массиве со значением, рассчитанным ALU (побитовый сдвиг влево).
Этого достаточно для проверки или я также должен проверить наличие короткого замыкания адресной шины (если они закорочены и я пытаюсь записать в недопустимое место, не будет ли запущен обработчик исключений?) Кроме того, я должен также проверить другие операции ALU, такие
как сложение, вычитание, НЕ, XOR и т. д. У меня также есть контрольная сумма кода, хранящаяся во внешней флэш-памяти, с которой можно сравнивать, вычисляя ее в коде во время выполнения. (Контрольная сумма, рассчитанная в коде == Контрольная сумма, считанная из флэш-памяти)
Какие-либо предложения. Пожалуйста помоги.
Я использую Keil IDE.
Чего вы боитесь? Что внутренний маршрут между гейтами внутри чипа сломан или закорочен? Если бы это было так, это, безусловно, означало бы, что чип физически сломан. Я имею в виду, сломанный, как в «расколотом на две половины из-за какого-то термического напряжения». В таком случае это вообще не сработает. То, что вы пытаетесь проверить здесь, того не стоит, вероятность того, что одна внутренняя трассировка неверна, более чем маловероятна.
Что более вероятно, так это одиночное событие upset , которое вы не можете предотвратить с помощью предварительного тестирования (и с которым в любом случае очень сложно справиться, вам, вероятно, понадобится некоторое ядро с блокировкой шага и память ECC).
В конце концов, используйте CRC для важных данных в памяти, чтобы реагировать на их повреждение. Это лучшее, что вы можете сделать.
Проверка памяти: запустите CRC для всего содержимого памяти, за исключением места, где вы храните ожидаемое значение, и определите ожидаемое значение во время сборки. Поскольку ожидаемое значение отличается для каждой сборки, это также может выявить не полностью написанную прошивку (что гораздо более вероятно, чем неисправная память).
Проверка ALU: на самом деле нет смысла. Полная проверка потребовала бы слишком много кода, а быстрая проверка, скорее всего, что-то упустила бы. Без знания внутренней проводки вы бы не знали, какие тесты имеют смысл (например, добавление 0x55555555 к 0x55555555 для проверки случайно соединенных соседних битов работает только в том случае, если реальная реализация не чередуется). ALU проходит заводские испытания как с оптическим осмотром перед упаковкой, так и с тестом, соответствующим его физической компоновке.
АльфаГоку
тусклый
АльфаГоку
тусклый