Во время тестов на запуск я должен проверить все местоположения ОЗУ с помощью теста galpat, я написал функцию для этого, но столкнулся с проблемой, что переменные функций существуют в ОЗУ и, следовательно, вымываются как часть теста.Как остановить тест RAM, разрушающий собственные переменные, встроенные C?
Какой был бы лучший способ обойти это?
Возможный подход может быть - особенно заботясь о стеке процессора, .data и .bss является то, что вы можете избежать - но нет простого способа иметь C работу без надлежащего стека:
(Это предполагает код запускается с ПЗУ, что обычно делалось бы на такой ранней стадии запуска). В случае сбоя памяти в областях, где вы выделяете стек, ваш код просто сработает (что он делает до этого - Реактиватор расплавлен ... - зависит от приложения).
При перемещении стека вокруг вне контроля C вы должны быть очень осторожны, что вы на самом деле храните там - указатели на стек переменных становятся недействительными - или, скорее, неопределенными - после перемещения стека. Однако простые скалярные переменные и указатели на вне стека, как правило, используются в тесте ОЗУ.
Вы можете попробовать и объявить переменные, как register, чтобы попытаться сохранить использование памяти как можно ниже - Но вы не силы C может поставить некоторые переменные в регистрах, и хороший C компилятор поместит их там так или иначе ,
Насколько это лучше, чем написать весь memtest на ассемблере (вам все равно нужно выполнить настройки стека на ассемблере, так как нет возможности переместить стек процессора на C). Я осмеливаюсь бросить вызов. Я не вижу здесь много смысла, используя C на этом низком уровне, тем более, что ассемблер полностью запускает процедуру memtest из регистров без использования какой-либо ОЗУ. Это делает его гораздо более неуязвимым для любой проблемы с ОЗУ. Процедура тестирования оперативной памяти не должна полагаться на рабочая память.
Обычно вы не можете скопировать стек, потому что стек может содержать указатели на объекты, состоящие из стека. Кроме того, утверждение о том, что сбои памяти просто вызовет сбои, вызывает сомнения. На встроенной системе (вероятно, нет защиты памяти) код может легко нанести небольшой урон, прежде чем он будет жестким. Я бы посоветовал написать регистрационный сборник только для регистрации. – EOF
@EOF Вы правы, но: то, что хранит стек, в основном зависит от вас. Если он хранит указатели в самом стеке или другом неперемещаемом материале - ваша ошибка. Я просто пытался указать метод, который имеет некоторый потенциал, что кто-то может заставить его работать - я сам никогда не попытаюсь написать такую низкоуровневую процедуру на C, также (и в основном) относительно второй части вашего комментария , Процедура тестирования памяти не должна * полагаться на * память. – tofro
Не может быть стека. – Olaf
Суть в том, что вы не можете, у вас есть два варианта: вы можете либо тестировать только часть плунжера, либо часть бара за раз, что означает, что вы не проводите полный тест адреса. Или вы не бежите от барана, который вы тестируете, что в основном является правилом, если вы действительно хотите проверить ram. Таким образом, вам нужно бежать из романа, используя стек в тестируемом бассете, или вы используете другой баран, возможно, есть кеш где-то, где можно использовать прямой доступ, чтобы дать вам небольшой баран.
Тестирование половины или некоторой другой фракции за раз, которая не является полным тестом, но лучше, чем не тестировать ее часть, может выполняться либо с независимым от положения модулем, либо с несколькими компиляторами теста, которые зависит от положения.Нет причин для того, чтобы стек был проблемой, копирование кода на основе rom и переход к тестируемому коду могут устанавливать указатель стека на основе тестируемой фракции или не тестироваться, а затем повторять. Относитесь к модулю как к функции, не похожей на целую программу, и сохранение проблемы стека или «перемещение теста» исчезает, и возвращается к коду на основе романа, который может возобновить дальнейшие тесты.
Один сумасшедший способ сделать это - попытаться включить кеш I, получить тестовый код в кеш (до того, как он ударит сам), а затем взорваться у барана, включая код, стоящий за баром. (у меня нет стека) Я бы попробовал это только как забавный эксперимент, но не для чего-то реального. Множество проблем для решения с таким подходом.
Мой подход был бы это:
Сделайте тест, прежде чем что-либо инициализации (переменные стека). В НКУ вы можете: void RAM_test(void) _attribute_ ((section (".init0")));
записать его в сборке. Убедитесь, что тест не использует/не сохраняет какие-либо переменные в ОЗУ, использует только регистры процессора.
магазин результат где-то, так что вы можете использовать его в дальнейшем в обычной программе.
Если у вас есть ROM пространство и может позволить себе тратить время во время загрузки, я бы осуществить тест в сборке или в голой функции С помощью директивы поместить переменные в регистрах, так что ни RAM не потребляется часть теста. Однако это будет довольно сложной архитектурой и компилятором, и ни один из них не упоминается.
Проведите тест перед установкой стека? – EOF
Запустите тест на свободной части памяти. Скопируйте тестовый код в тестируемый регион, перейдите туда и снова запустите на непроверенную область. –
Не могли бы вы расширить этот @EugeneSh. ? Как именно я могу переместить код? – nodee3345