Ребята привет.

Подскажите встречался ли кто нибудь с изменением данных во внутреннем озу контроллера под действием наводок.

Как оценить надежность ОЗУ.

Крайне маловероятно. С очень давних времен подобного замечено не было.
У меня на платах 30A комутируются около процессора и все ОК.
Наводки могут перезагрузить проц. (зависит от того как сделан сброс) и очень хорошо влияют на работу всяких JTAG-ов.
Ищите ошибку в программе, посмотрите правильно ли описана видимость переменных в прерываниях и проверьте, достаточно ли выделено стека.
Ну и конечно выход индекса за границу массива.
Попробуйте изменить уровень оптимизации.

Не исключены ошибки компилятора - загрузчика.
У меня недавно опять была проблема с 2313 на IAR - проявления похожие, но достаточно было сменить название процессора на 26 и все стало ОК. Но это врятли Ваш случа.

не согласен с предыдущим постом: Еще как могут.
Вы не шутите? 30 ампер комутируете возле камня?
У вас нет индуктивностей ни в нагрузке ни в проводниках? ... уверен что есть. а это чревато гиганскими выбросами напряжения. согласен , что первым делом страдает ресет, но данные могут измениться еще как!
2 автор топика: на счет ЭМС - опишите ЭМ обстановку вокруг камня.

Woodoo а вы сталкивались с изменение данных в ОЗУ из-за наводок?

Иногда по требованию заказчика делал различные тесты ОЗУ на разных МК. Эксперементировал с наводками. Ни разу не удалось с пом. наводки повредить озу. В настоящий момент считаю такие тесты нецелесообразными. Добится чтобы МК "вылетел" обычно несложно. Специально создаю такие условия чтобы отработать watch dog. Если прога написана на С, то возможно неправильно оценён и определён размер стека. Если на ассемблере, то возможно "плывёт стек" или повторный вход в прерывание. Либо наложение имён переменных в голове и прерывании.

2Serega Doc:
Возможно немного погоречился со словами "Еще как могут", но всетаки считаю что могут. На правтике 100%-ой достоверности такого факта наблюдать не удавалось, но исходя из проанализированных сбоев(специфика работы такая) приходили к выводу, что кроме как изменением содержимого озу объяснить факт сбоя не удастся. Могу точно сказать, что ЭМ помеха может привести к некоректной работе программы, тоесть, спонтанному переходу ядра на выполнение иной инструкции, нежели следующая, что может привести к фатальному исходу.

Достаточно сильная помеха в первую очередь повлияет на вывод сброса МК. Это несомненно.

2SasaVitebsk: интересно, насколько энергичную помеху вы создавали, и в каком диапазоне, испытывая озу МК?
Не могли бы вы меня убедить в нецелесообразности проведения подобных тестов? (дело в том, что в скором времени буду заниматься именно этим)

2автор топика:
Ну так, как на счет более подробной информации о вашей проблеме? Или же уже все разрешилось? Сообщите, интеренсо.

Убеждать не буду.
Более/менее серьёзные исследования делал давно. На нескольких МП. Одним из них был 8951. Запускал тест озу (шесть ступеней, по науке) и создавал импульсные помехи по питанию. Пробовал при разном напряжении питания. И при разной частоте кварца. Каждый этап теста завершался ответом.

Не было ни одного случая ошибки теста внутреннего озу. При этом при подключении и использовании внешнего ошибки наблюдались.
Обычно МП просто "вылетал". Для каждого МП бывал характерен свой "вылет". Например для 8951 возникало ощущение, что он осуществлял переход не по тому адресу. Особенно часто это проявлялось при оверклокинге. Ещё одна интересная деталь для этого процессора. Можно сказать - мистика. Проги с короткими переходами работали в два/три раза устойчивей чем с длинными. Сначала думали, что причина в большом колличестве смен 1/0 в регистре адреса, но эксперименты не подтвердились. Важной была только длина перехода. Как будто "недопрыгивал".

При переходе на AVR делали тестирование, но слабенькое. Особо не экспериментировали. Наблюдали вылет по резету и потерю флэша. (90s4414) Писали на сайт. Нам порекомендовали резисторы и кондёры на SPI и RESET. В дальнейшем хомут был убран. На MEGAх глюк не наблюдался.

При запуске нужно проиницилизировать переменные в озу значениями иначе после сброса что в них будут за значения хрен знает.
Так что если у Вас проходит сброс, то стартовые условия работы проги могут измениться если не инициализировали переменные.

Проводили эспытания на ЭМС (электромагнитную совместимость) в процессе разработки изделия. Долбили 2 кВ нано и микро секундными импульсами через емкостные клеши по кабелю, через который общались устройства. И получилось так, что этот кабель связи лежал рядом с коробушкой в которой молотил МК (ATmega162 в корпусе PDIP) так у нее весь FLASH нахрен снесло (потом считывали FLASH и смотрели). Так что я думаю и ОЗУ выбить может как нечего делать, и не только ОЗУ.

Но такое было замеченно только один раз. Но ситуация вполне реальная, удар молнией например.

Почитайте мой пост выше. Выбить флэш для AVR, - достаточно не сложно. Наблюдали такое много раз. Из старых однокристалок типа 4414 или 1200 сиутация настольто тяжёлая, что не надо киловольтных импульсов. Несколько раз наблюдались ещё более интересные глюки. Так в модеме есть тест Флэш. Приносят на ремонт. Модем полностью исправен. Работает правильно. Диагностируется. CRC флэш Ok. Но один из светодиодов (OH - "трубка снята") по включению питания горит. После выполнения любой из команд, далее работает верно. После перезаписи - всё заработало нормально. Второй случай - вроде всё нормально, но не совсем корректно работает UART. Переписывали раз 10. В какой-то момент всё заработало.
Явно иногда не верно работала какая-то процедура инициализации. Которая работает по сбросу (не пользовательская, а скрытая). Но как она восстанавливается.

Я не исключаю ситуации когда портится ОЗУ. Просто момент когда это происходит, очевидно уже все узлы однокристалки готовы к сбою. Таким образом тестирование ОЗУ ни к чему не приводит. Если происходит "вылет", то серьёзный. В такой ситуации уже бессмысленно что-то тестировать диагностировать. Надо обрабатывать ситуацию "авария". Обычно типа WatchDog.

Кстати в одном из изделий, по WatchDog-у я проверяю озу и если оно номально, то не инициализирую. И в общем-то наблюдал такие случаи.

сбои во флеш и еепром были, но не на пустом месте. В проге были процедуры изменения во флешь и еепром и при сбои в работе мк (сторт с произвольного адреса) иногда они стартовали. Уменьшали вероятность усложнением процедур записи, а от флеш записи кое где вообще отказались. ну и схематехнику с разводкой думали.

В своей практике встречал ситуацию когда
ЭМ помеха в хлам разбивала RAM память меги и плисины. Проверял специальным тестом. Иногда слетало все, вплоть до watchdog'а

Специфика следующая:
Конструктивно рядом с камнем и плисиной внутри прибора проходили линии RS485, который хватал чудовищную помеху от приборного шкафа с усилками как раз в момент излучения (). Выброс наблюдал на осциллографе. Он был ужасен.

Сообщение отредактировал SeriouSerg - Aug 17 2006, 02:19

Можно уточнение. Вы говорите о том что помеха наводясь на контроллер может выбить и ОЗУ и ФЛЕШ но не могли бы вы указать порядок амплитуды помехи?