Казуса е следния:

Батерийно захранено изделие с едночипов процесор. С една батерия трябва да работи няколко години (почти непрекъснато трябва да е в слийп режим).
Има включен WDT, който буди периодично проца, за да свърши малко полезна работа.
Браун аут-а работи само докъто процесора е в активен режим и е изключен докъто процесора спи.

проблема е, че данните в рам-а понякога се скапват (предполагам заради бъг в програмата ми), но това не води до WDT ресет Проца си рабори с грешните данни, опреснява си WDT таймера и никаква не я върши ...

Та въпроса ми е принципен - при една коректно написана програма ( без бъгове ) - как да гарантираме коректното функциониране на изделието ? Т.е. как да направим някаква проверка на валидността на данните в РАМ-а?

CRC на РАМ-а не е решение, тъй като той непрекъснато се модифицира.
Айде примерно проверка на стека лесно може да се направи с маркери в началото и края му и периодичното им проверяване, но това не е всичко.

От друга страна изделието е батерийно и трябва да държа процесора колкото се може по-дълго в приспано положение, а не да изтощавам батерията с дълги проверки ...

Разбирам, че изискванията ми са противоречиви и не съвсем дефинирани, но трябва да намеря някакво компромисно и работещо решение.

Някой сблъсквал ли се е с подобен казус?

Пробвай да направиш "CRC проверка" при събуждане на процесора, вършиш си работата, след това прваиш ново "CRC за проверка" и приспиваш процесора.

коректно написана програма няма нужда от проверка
на програма с бъгове колкото и проверки да слагаш няма гаранция че и проверката няма да се бъгне и ако още не са оплескани данните да ги оплеска... никога не е късно

ако все пак държиш на проверките редно е първо да разбереш какво и как ти скапва данните, за да може и проверката да е ефективна срещу евентуалните проблеми

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

А ти познаваш идеалния програмист, който пише винаги коректни програми???

Няма програма без бъгове. Има такава, на която бъговете не са се проявили

@emilvtc - аз за друго освен CRC не се сещам. Логически погледнато РАМ-а ти се променя по два начина - законно (от твоя софтуер) и незаконно (от нещо неизвестно, възможно и твоя софтуер).

Та според мен CRC-то трябва да се ъпдейтва всеки път като пишеш законно. Реципрочно CRC-то трябва да се проверява всеки път като четеш данните. И/или това да е условие да нулираш WDT. Оформяш си две процедури за вход и изход и само през тях работиш с данните. CRC-то може и да е нещо по просто - например събиране без пренос. Самите данни трябва да са обособенни в някакъв масив и да са достъпни легално само през процедурите за вход-изход.

Това вероятно товари доста процесора, особенно ако данните са много. И не решава проблема ако твоя софтуер "нелегално" използва законните процедури да пише в РАМ-а

То след това остава и много по-сложния въпрос - кво праим като установим, че данните са омазани??? Как да го съобщим на клиента, без да предизвикаме оправдания му гняв?

Цецо - писали сме по едно и също време



+1

Да не говорим и за уърк араундите и хардуерните бъгове и "особенности" на самите процесори ...

Та това за което се сещам към момента е всички процеси да използват обособени областти от рам-а за променливите си.

При събуждане на проц-а той проверява CRC-тата САМО на процесите (тасковете) които ще стартира докъто е буден. В болшинството от буденията тези таскове не са много.
Преди приспиване - изчислява CRC-тата на данните САМО на активираните през последното събуждане процеси. Така няма да се губи излишно време в сметки на неизползвани области на РАМ-а.

CRC-то може би може и да е тъпа чек сума (събиране).

Консумацията (времето когато проц-а не е приспан) е критично за мене и трябва да е възможно по-кратко ...

Разбира се маркерите в началото и края на стека се проверяват при всяко събуждане.

Не знам до колко идеите ми са ефективни, но за момента не се сещам друго

За мен ще е достатъчно процесора да се ресетне и да възстанови работоспособността си. Т.е. не е критично да се ресетне. Критично е да даботи с обозени данни.

исках да кажа че ако сам си създава главоболията по добре да потърси къде е грешката вместо да прави проверки на грешките

Това всеки програмист задължително трябва да се опитада го направи

Махни това CRC, ще загубиш доста време и батерия. Ако данните са малко, просто ги дублирай, или пък по три. Паметта свършва бързо, но пък ако имаш много данни и CRCще е доста. Иначе ако имаш хардуерен CRC е друго, тогава това не е лош вариант, въпреки че ако са повече данните и 32 битово не е гаранция че няма да има грешки, ще трбява да ги разделяш на парчета.
Но иначе не би трябвлао да имаш подобен бъг при който данните да не са верни, поне не в номинален режим, т.е. докато си на батерия, ако речем батерията умре и не успееш да запишеш, или нещо такова, това по може да с епреживее, въореки че не е вариант.

бах, тия грешки дето стават веднъж на месец са най-забавни
аз лично подкрепям тони - дублиране на паметта. това няма да сработи ако бъга е софтуерен, но ще хване хардуерни промени в паметта.

Според мен простото дублиране на памета само ще покаже че има грешка, но няма да реши въпроса генерално, тъй като за да се излезе от ситуацията някой трябва да покаже кое парче е вярно, т.е. опираме пак до Чек Сума (проста) или CRC. Може и да се ползва контрол по четност/нечетност на всеки байт, т.е. 9-и бит, но това пак само ще покаже че байта е грешен. Комбинацията от няколко метода може да даде нужното решение.
Може да се използва и кодиране с код за откриване и изправяне на грешки - код на Хеминг например. Това се използваше масово (поне навремето) за да се контролират RAM масиви-те на по - сериозните машини. Та доколкото си спомням при добавянето на 3 информационни бита в един байт се коригира единична грешка(т.е. само в един бит от байта) и се регистрира двойна грешка, а при 5 инфо бита се коригира двойна и се регистрира тройна грешка, но може и да бъркам, трябва да се провери.
Ако изделието е много отговорно би могло да се помисли и за хардуерно решение, например външна FRAM или MRAM. Щом проца предимно ще спи, вероятно данните дето ще ги пази не са чак толкова много.

Е то памет с ECC не е нужно да се изобретява, има я отдавна - май идваше 36 бита широка
за 32 та да може да коригира еднобитови грешки.

Но в случая става дума за MCU - какви ECC-та.

В такива ситуации диагностиката е основното нещо. Трябва да се разбере дали проблемът
е хардуерен или софтуерен, няма как да се мине без това. Слепешката работа не става.

Ако е софтуерен проблемът, лечението е едно - обикновено лесно.
Ако е хардуерен, прави се хардуер който да го няма. Не е толкова голяма работа
една памет да кара в standby с години без да се скапе ако е направена свястно.
Ако е сбъркана хардуерно и преходните процеси я скапват, значи не става и
трябва да се прави наново.

Достатъчно би било при детектване на омазване в РАМ-а да се предизвика WDT ресет и програмата за се стартира на ново.

Проблема идва от това, че това детектване някак си трябва да се направи от процесора възможно за най-кратко време, след което да изпадне в слип режим за да си пести батерията. "Цялата пара не трябва да отива в свирката ..."
Е, всичко е въпрос на някакъв разумен компромис.

Идеята е някак си да се защити устройството от хардуерни (вътрешно-процесорни уърк араунди или "фичърси"), а също и от софтуерни бъгове.

И понеже проблем може да се появи примерно веднъж на месец - гадорията става пълна ...

абе пичове, къде се отнесахте... глупаво е да се поправя софтуерна грешка с хардуер и обратно, едно е да търсиш решение на проблем по задание, друго е да поправиш грешка създадена от теб, първо трябва да изчисти програмата си от грешки и тогава

какво е заданието? да оставим грешките и да направим хардуерни и софтуерни проверки или да си изчистим грешките

Целта на задачата е след като се изчистят всички познати бъгове в SW и HW - да се вземат мерки за "гарантирано" поддържане рабоспособността на устройството. Също така да се помисли и за някаква превенция на все още неоткрити бъгове в HW и SW.

Очевидно както вече обясних - само на WDT не може да се разчита за детектване на "невалиден" РАМ.

от моя скромен опит
софтуерно - ако нещо плеска и маже из рама, бозата става голяма, добавянето на още код, добавя не само провека, но и още възможности за плескане, keep it simple, ако все пак искаш да проверяваш работоспособността на рама или програмата си има много методи и алгоритми за проверка, вики и гоогле могат да те заринат с математика, дори има алгоритми за възстановяване на загубени данни, в общия случай CRC най използван, но в зависимост от типа данни и конкретната задача може да се измисли нещо по подходящо, за един проект ползвах дублиране на данните, за друг само 8 битова сума, друг път данните са ми били в диапазон, ако е по голямо от 10 значи има грешка, или разликата между 2 съседни байта примерно ако семплираш синусуида 50хз горе долу знаеш диапазона на следващия байт, ако искаш да опростяваш и да пестиш ресурси всичко е строго индивидуално

хардуерно - кондензатори от точен тип на точното място, ако не метална кутия то поне дебела алуминиева пластина залепена върху процесора, само така успях да спра силни високочестотни магнитни смущениям които триеха и еепрома и флаша, ценери на всички входове и изходи извън кутията, също така и през резистор и кондензатор на маса ако позволява, правил съм и глезотии от рода да си следи захранването и при промяна да записва данните в еепрома преди да са се разредили кондензаторите, за батерийно захранване бих го препоръчал, така след смяна на батериите няма да се губят данни

общо взето гениалните неща са прости, колкото по просто толкова по малко неща ще се повредят