RAM, ROM & MCU tests in embedded applications

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Hello, Alexey Krasnov !

 >>>>> Идеология такая: либо работаем правильно, либо - выходим в отказ, не
 >>>>> пытаясь самостоятельно что-то придумать. Поэтому в процессе всего
 >>>>> цикла жизни контроллера фоновой задачей выполняется проверка всех
 >>>>> возможных контрольных сумм.

 >>> DO> Hа чем контроллер и много ли наловил сбоев?

 >>> Hа AVR. очень редко, но нарушается целостность EEPROM, по невыясненным
 >>> причинам.

 > DO> А с ОЗУ/ПЗУ проблемы бывали?

 > flash слетает

У AVR? И как часто, и если можно сказать, в каких условиях? Я видел слетевший
флеш только у MC68HC908 и сказать при каких условиях это произошло не могу. У
PC16F не видел такой неисправности ни разу практически в тех же условиях (и при
заметно больших тиражах). Выявлялось это не рантаймовыми (как я уже говорил
бесполезными в нашем случае) тестами, а анализом нескольких вернувшихся
отказавших устройств с многотысячными тиражами. У единиц из них после
перепрошивки программы все восстанавливалось. Последние года два-три таких
отказов не было. Подозрения на конкретно плохую серию 908 мотороловских
контроллеров.

Учитывая, что контроллеры у нас работают в крайне тяжелой с точки зрения EMI
обстановке, правда в не особо ответственных применениях (худший случай -
погаснет какая-то лампа, которая может погаснуть по сотне других, куда более
вероятных причин), я считаю для своих задач  subj совершенно бесполезной тратой
ресурсов контроллера и своего рабочего времени.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
    Hello, Alexander!

Пят Маp 11 2005, Alexander Golov писал к Rifkat Abdulin по поводу "Re: RAM, ROM
& MCU tests in embedded applications."
 AG> Традиционно у Microchip кристалл в 28- и 40-выводных МК один и тот же.
Типа и device id и revision number один и тот-же...
 AG> Так что твои 876 и 877 это в сущности один и тот же МК.
А в реальности - разные.
 AG> Александр Голов, Москва, snipped-for-privacy@mail.ru
  WBR!  Maxim Polyanskiy.


Re: RAM, ROM & MCU tests in embedded applications
Здравствуйте.

 >> DO> А с ОЗУ/ПЗУ проблемы бывали?
 >> flash слетает
DO> У AVR? И как часто, и если можно сказать, в каких условиях?

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

---
Алексей Краснов





--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: RAM, ROM & MCU tests in embedded applications
       Доброго здоровья, Alexey!

11 Mar 05 11:01, Alexey Krasnov написал для Sergei Tuchinski:

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

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

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

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

    WBR, Сергей.                                     ICQ: 101347299

... Мужчины во всем превосходят женщин: и в мудрости, и в глупости.

Re: RAM, ROM & MCU tests in embedded applications
Здравствуйте.

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

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

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

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

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

---
Алексей Краснов





--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: RAM, ROM & MCU tests in embedded applications
Здравствуйте.

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

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

---
Алексей Краснов





--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru

Re: RAM, ROM & MCU tests in embedded applications
Hello, Leha Bishletov !

 >  ??>>  Очень уж ты обширную тему затронул :) Минимум, реализуемый всеми,
 >  ??>> ИМХО, это при включении, проверка СRC ROM + тест RAM. Что бы
 >  ??>> кто-то

 >  DO> Я точно знаю, что всеми, кто использует pic16 проверка rom не
 >  DO> делается ввиду отсутствия к нему доступа в подавляющем большинстве
 >  DO> кристаллов.

 >  Это для старых PIC16C, сейчас в PIC16F ROM доступен, хотя бы для
 > чтения.

16F73 - это старый?

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

 >  В каких-то случаях это допустимо, в каких-то лучше ничего не
 > делать, чем делать не пойми что.

Если у тебя слетел флеш программ, да не весь, а какие-то биты, у тебя нет
возможности контролировать что делает твоя программа, так как делать не то она
может начать сразу вместо процесса самопроверки.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Привет, Dima!
Вы писали to Leha Bishletov on Fri, 11 Mar 2005 14:06:00 +0300:

 DO>>> Я точно знаю, что всеми, кто использует pic16 проверка rom не
 DO>>> делается ввиду отсутствия к нему доступа в подавляющем
 DO>>> большинстве кристаллов.
 ??>>  Это для старых PIC16C, сейчас в PIC16F ROM доступен, хотя бы для
 ??>> чтения.
 DO> 16F73 - это старый?

 Это новый, и он может читать свою ROM.

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

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

With best regards, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru



Re: RAM, ROM & MCU tests in embedded applications

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


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


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

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

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

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

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

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






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

Re: RAM, ROM & MCU tests in embedded applications
Hello, Alexey Krasnov !

 >>> DO> А с ОЗУ/ПЗУ проблемы бывали?
 >>> flash слетает

 > DO> У AVR? И как часто, и если можно сказать, в каких условиях?

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

По-моему, это "звоночек" не применять такие кристалы вообще... Если я правильно
тебя понял что слетает именно программная память.

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Hello, Alexey Krasnov !

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

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

Тестирование чего? Тестирование программы и изделия с ней - однозначно. А
проверка контрольной суммы ПЗУ чем поможет?

С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications
Привет Alexey!

11 Mar 05 10:31, Alexey Krasnov писал Dima Orlov:

 >>> flash слетает
 DO>> У AVR? И как часто, и если можно сказать, в каких условиях?

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

    А одтягивающие резисторы на выводах программирования (как минимум на SCK)
стояли?

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Собака - вдруг человека...

RAM, ROM & MCU tests in embedded applications
Здравствуй, Alex!

Friday March 11 2005 18:32, you (2:5054/70) wrote to Alexey Krasnov:

 AK>> Было неоднократно у 8515 и mega163. Вероятно, в момент включения
 AK>> питания. Хотя супервизор питания стоит. По новым мегам статистики
 AM>     А одтягивающие резисторы на выводах программирования (как минимум
 AM> на SCK) стояли?

А это пох. У мег убpать внешние цепи RESET нахеpъ... Пин pезет подтянуть на
Vcc. Юзать встpоенный BOD... Пpавильно pазвести печатную плату.

ЗЫ Изощpенное извpащение над tiny26, mega16 и mega128 косяков со слетанием
флеша
не выявило. Условия эксплуатации, вообще, конские - мегаваттные девайсы
под боком... Хотя, да - SPI юзается внешними девайсами...Это нащщет SCK.

Alex


RAM, ROM & MCU tests in embedded applications
Привет Alex!

12 Mar 05 02:01, Alex Gavrikov писал Alex Mogilnikov:

 AK>>> Было неоднократно у 8515 и mega163. Вероятно, в момент включения
 AK>>> питания. Хотя супервизор питания стоит. По новым мегам
 AK>>> статистики
 AM>>     А одтягивающие резисторы на выводах программирования (как
 AM>> минимум на SCK) стояли?

 AG> А это пох. У мег убpать внешние цепи RESET нахеpъ... Пин pезет
 AG> подтянуть на Vcc. Юзать встpоенный BOD... Пpавильно pазвести печатную
 AG> плату.

    У 8515 внешний супервизор нужен, а reset припаять к vcc нельзя если юзается
внутрисхемное программирование. Отсутствие подтяжки - это ИМХО распространенная
ошибка разработчика, в результате которой как раз возможно стирание ПЗУ.
Подтяжка его устраняет. Может я какие-то еще тонкости и забыл, давно avr нигде
не применял, но суть бага именно в том, что кристалл при включении входил в
режим программирования.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.

RAM, ROM & MCU tests in embedded applications
Здравствуй, Alex!

Tuesday March 15 2005 17:53, you (2:5054/70) wrote to me:

 AG>> Пин pезет подтянуть на Vcc. Юзать встpоенный BOD... Пpавильно
 AM>     У 8515 внешний супервизор нужен, а reset припаять к vcc нельзя
 AM> если юзается внутрисхемное программирование. Отсутствие подтяжки -
 AM> это ИМХО распространенная ошибка разработчика, в результате которой

Дык, я пpо пулап и толкую. Hасчет этого можешь не сумлеваться =)

Alex


Re: RAM, ROM & MCU tests in embedded applications
Hello, Dmitry Kuznetsov !


 >>  >  Контроллер, который этим управляет, делает постоянную фоновую
 >>  > диагностику согласно его документации.

 >> Вот это самое интересное. Во-первых, в документации на контроллеры я
 >> никогда не встречал ничего про фоновую проверку, во-вторых, какие были
 >> ее результаты? Что наловила проверка?

 >  Да уж полтора десятка годков прошло... где те доки...

Тогда это вообще не интересно. Интересна информация по современным
однокристаллкам, а не по каким-то древним модулям.

 >  Правильное действие при контролируемом отказе (используется
 > именно термин "отказ") - это отключение выходов. А это ловится
 > аварийными блокировками.

Правильное действие зависит от назначения устройства и больше ни от чего.


С уважением, Дима Орлов.


Re: RAM, ROM & MCU tests in embedded applications

Quoted text here. Click to load it

 ???  Электроника, естественно, меняется, но некоторые решения
 могут очень долго оставаться современными...

Quoted text here. Click to load it

 Разработчикам универсальных устройств типа PLC ничего не известно
 об конкретном назначении систем на их базе и они ориентируются на
 на общий случай.

 Реализация конкретных правильных действий лежит на разработчике
 системы (интеграторе).

 Принцип простой - Отключенное состояние контроллера не должно
 приводить к созданию на объекте опасных технологических ситуаций.





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

Re: RAM, ROM & MCU tests in embedded applications
Hello, Leha Bishletov !

 >  DO>>> Я точно знаю, что всеми, кто использует pic16 проверка rom не
 >  DO>>> делается ввиду отсутствия к нему доступа в подавляющем
 >  DO>>> большинстве кристаллов.
 >  ??>>  Это для старых PIC16C, сейчас в PIC16F ROM доступен, хотя бы для
 >  ??>> чтения.
 >  DO> 16F73 - это старый?

 >  Это новый, и он может читать свою ROM.

Да, действительно может.

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

 >  ??>>  В каких-то случаях это допустимо, в каких-то лучше ничего не
 >  ??>> делать, чем делать не пойми что.

 >  DO> Если у тебя слетел флеш программ, да не весь, а какие-то биты, у
 >  DO> тебя нет возможности контролировать что делает твоя программа, так
 >  DO> как делать не то она может начать сразу вместо процесса
 >  DO> самопроверки.

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

Это зависит от характера слетания флеша. Тот немногий опыт, что был у меня с
HС908 от Моторолы показывал, что процессор вообще ничего не делал.


С уважением, Дима Орлов.


 > --- ifmail v.2.15dev5.3
 >  * Origin: Golden Telecom (2:5020/400)


RAM, ROM & MCU tests in embedded applications
Fri Mar 11 2005 20:10, Dima Orlov wrote to Leha Bishletov:


 DO> Это зависит от характера слетания флеша. Тот немногий опыт, что был у
 DO> меня с HС908 от Моторолы показывал, что процессор вообще ничего не делал.

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

 VLV
  

 "Быть честным - лучший способ оставаться бедным"  (c) Hаполеон Бонапарт


RAM, ROM & MCU tests in embedded applications
Hello, Vladimir Vassilevsky !

 >  DO> Это зависит от характера слетания флеша. Тот немногий опыт, что был у
 >  DO> меня с HС908 от Моторолы показывал, что процессор вообще ничего не
 > делал.

 >  Если есть бутлодер, который сам умеет стереть flash, то с ненулевой
 >  вероятностью возможна активация этой функции. Hа эти грабли

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

 > пришлось наступить с ATMega323. Правильный бутлодер должен быть только
 > загрузчиком собственно процедуры апгрейда софта.

Я предпочитаю возможность вообще запретить низквольтное программирование.

С уважением, Дима Орлов.


Site Timeline