RAM, ROM & MCU tests in embedded applications

RA>> У меня есть статистика по 876-877м пикам - по 200-300 шт в устройствах. RA>> ПЗУ не крошилась. EEPROM крошилась в 877х - при исследованиях RA>> выяснилось, что падали начальные ячейки EEPROM при сильных помехах по RA>> первичке 220В - работала болгарка. Хотя были и керамические емкости, и RA>> кренки, и дросселя, и супервизоры питания. В этих же условиях EEPROM в RA>> 876х не крошилась.

AG> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же. Так что AG> твои 876 и 877 это в сущности один и тот же МК.

Статистика - вещь сильная, однако. Может - играла роль длина проводников от чипа к пинам?

Здравствуйте.

Было неоднократно у 8515 и mega163. Вероятно, в момент включения питания. Хотя супервизор питания стоит. По новым мегам статистики пока нет.

Здравствуйте.

AK>> Hа AVR. Hа начальном этапе в основном программные сбои, AK>> приводившие к AK>> порче EEPROM, вылету за пределы прошитой flash, переполнению стека, AK>> нарушению логической структуры рабочих переменных, порче их AK>> контрольной суммы. Затем все более-менее устаканилось - очень AK>> редко, AK>> но нарушается целостность EEPROM, по невыясненным причинам.

ST> если это AVR, то надо ставить монитор питания. мы таким образом ST> победили

Вот именно, что ставим. Мистика какая-то.

RA>> У меня есть статистика по 876-877м пикам - по 200-300 шт в устройствах. RA>> ПЗУ не крошилась. EEPROM крошилась в 877х - при исследованиях RA>> выяснилось, что падали начальные ячейки EEPROM при сильных помехах по RA>> первичке 220В - работала болгарка. Хотя были и керамические емкости, и RA>> кренки, и дросселя, и супервизоры питания. В этих же условиях EEPROM в RA>> 876х не крошилась.

AG> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же. Так что AG> твои 876 и 877 это в сущности один и тот же МК.

Статистика - вещь сильная, однако. Может - играла роль длина проводников от чипа к пинам?

Здравствуйте.

DO> я считаю для своих задач subj совершенно бесполезной тратой DO> ресурсов контроллера и своего рабочего времени.

Тем не менее, тестирование довольно полезно для отлова программных ошибок.

Здравствуйте.

AK>>>> Hа AVR. Hа начальном этапе в основном программные сбои, AK>>>> приводившие к AK>>>> порче EEPROM, вылету за пределы прошитой flash, AK>>>> переполнению стека, AK>>>> нарушению логической структуры рабочих переменных, порче их AK>>>> контрольной суммы. Затем все более-менее устаканилось - очень AK>>>> редко, AK>>>> но нарушается целостность EEPROM, по невыясненным причинам.

ST>>> если это AVR, то надо ставить монитор питания. мы таким образом ST>>> победили

AK>> Вот именно, что ставим. Мистика какая-то.

ST> возможно, большие помехи по питанию? а нагрузочная способность блока ST> питания ST> достаточная? а то при записи EEPROM потребление сильно и скачкообразно ST> растет

Вероятно всего, какая-то особенность схемы. У меня нет склонности винить в этом кристалл.

DO> > DO> Да и во многих случаях эта проверка совершенно бессмысленна. Hе DO> > DO> работает программа вообще (не прошла проверку), или работает DO> > DO> неправильно - все одно устройство не работает. DO> DO> > В каких-то случаях это допустимо, в каких-то лучше ничего не DO> > делать, чем делать не пойми что. DO> DO> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя DO> нет возможности контролировать что делает твоя программа, так как DO> делать не то она может начать сразу вместо процесса самопроверки.

Вероятность "сразу вместо" можно сделать намного меньше 100%...

Есть много реальных задач, где требуется относительно редкая, но очень быстрая реакция на события. Приходиться ставить более производительный процессор, который на основную задачу тратит лишь малую часть от своей полной производительности.

Если все остальное время будет работать тест, то чисто статистически сбой вероятнее произойдет именно во время теста и будет с достаточно ненулевой вероятностью обнаружен.

В тестирующем коде, в отличие от рабочего, неправильное исполнение части команд с ненулевой вероятностью приведет к обнаружению сбоя.

Если же произойдет вылет из тестирующего кода, то должен сработать вотчдог (лучше внешний). Есстно, не 100%, но вероятность высока...

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

Естественно, если в конкретном случае высокая надежность важна... Впрочем, в таких случаях можно исскуственно завысить долю тестов.

<< Поцелуй мой *б*л*е*с*т*я*щ*и*й* зад... << ... (c) Bender [8E] Dmitry Kuznetsov, Moscow, Беговая Черепаха] [Team LEXX] *