Mikrokontrolleres eszköz "felejt"

Van egy speckó mikrokontrolleres eszköz, aminek néhány dolgot meg kell "tanítani" a normál működéshez. Ez meg is történt, viszont egy idő után ezeket "elfelejti" - újratanítást követően megint működik ideig-óráig, aztán goto 10, tanítható újra. A mikrovezérlő blokkdiagramja meg a panel tanulmányozása után úgy tűnik, hogy egy soros eeprom-ban kéne tárolódnia ezeknek az információknak, ami egyébként egy 9386-os tipus, "természetsen" SO8 tokban, úgyhogy inentől kezdve kéne valaki, aki ezt a gyanút igazolni tudná, illetve utána ezt dögöt ki tudná cserélni (M93C86-WMN3P) Budapesten. (A cserealkatrész beszerzését intézem, bát ahogy nézem, a legtöbb helyen a 80°C-ig használható darabokat lehet kapni...)

( kleinie | 2019. 03. 03., v – 08:27 )

SO8 még nem is annyira kicsi. Ha TSSOP lenne, ahhoz már lehet kell 2 feles, hogy ne remegjen a kezem.
Mindenesetre fura hiba. Ha egyszer beállítod, akkor csak kimegy az eepromba, ha valameddig működik.

Nekem is ez a fura - sajnos nem én csináltam a teszteket, úgyhogy még ki kell nyerni azt az infót, hogy pontosan mi is történik - meg mi nem, és mikor, de első blikkre nekem ez a komponens a gyanús. Lehet, hogy a mikrokontoller nem tudja felprogramozni az eepromot a saját hibája miatt, ekkor persze az egész motyó mehet a kukába e-hulladékba - ezt viszont csak beépítve éles működés közben lehetne tesztelni értelmesen.

Nekünk volt egy olyan - saját - hibánk, hogy bekapcsoláskor a mikrokontroller random folyamatot indított a soros rom felé, minek következtében az első (jó, a nulladik) címen levő adat átíródott.
Speciális eset, mert a mikrokontroller egy Xilinx, ami csak a saját bootolása után lesz elérhető a szoftver számára. Huszáros megoldás született: nem használtuk a 0. címet :(

Nem ismerjük a cuccodat, de nem lehet, hogy egyszerűen a szoftvere "elírja" az eeprom élettartamát? Amúgy safety területen becsültek a kollégáim anno kb 7-8 évet a memória alapú ic-re. Szóval van olyan termékünk, amiben x évente a fél készlet félvezetőt cseréljük.

( Hiena v | 2019. 03. 03., v – 13:00 )

Ha újratanítható, és utána ideig-óráig működik, akkor nem biztos, hogy ROM hiba lesz.
Kell szerezni egy olvalsót és kiolvasni a tanítás előtt, tanítás után és a meghibásodás utáni kódot.
Ha többszöri nekifutásra is ugyanazon a helyen keletkezik hiba a memóriában, akkor kuka a memória.
Ha ciklikusan van írva a memória (loggolás, stb), akkor hibás tápellátásnál jelentkezhet konfig felülírási hiba. Egyszerűen vagy ráül a tápzaj az adat/címbuszra, vagy a proci kap egy olyan berántást, amitől eldobja a lantot.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( answ | 2019. 03. 03., v – 15:55 )

Elvetted teljesen az eszkoz tapjat, amikor nem "felejtett"? En kiirom EEPROM-ba a configot, de a working set az SRAM-ban van. Ezert csak akkor olvasom be EEPROM-bol ujra, ha reset volt. Ugyanigy mukodnek peldaul regi Panasonic kozpontok is, jol megy a beallitas hibas EEPROM eseten is mig nem kell ujra beolvasnia, de akkor mar szemetel a DOS-os program. Az EPROM wear jellemzoen bithibakban jelentkezik, igy az egesz beallitas elfelejtese gyanus (bar nem lehetetlen). Tapfeszultseget mindenkepp ellenoriznem iras kozben, mert arra erzekenyek. Meg az is lehet, hogy idonkent ir az eszkoz bele (akkor is mikor nem allitod) es ingadozik a tap.

> Az EPROM wear jellemzoen bithibakban jelentkezik, igy az egesz beallitas elfelejtese gyanus (bar nem lehetetlen).

A bithibák miatt szokás ellenőrző összeget is tenni bele, és ha az nem stimmel, akkor inicializálatlannak venni a memóriát és alapbeállításokkal indulni. Ilyen megvalósítás is elképzelhető.

Én pontosan így csinálom, de egy rakás implementációba nem raknak ellenőrzést. Tapasztalat.

Érdekes egyébként, hogy a bithiba nem állandó. Én mindig visszaellenőrzök írás után és eleinte elég 2x, aztán később 3x újra törölni (ugye ~0-ba) és írni, majd végül sok-sok ezer írás után már az sem segít és teljesen beragad. Érdemes egyébként cirkuláris puffert alkalmazni, illetve készül egy érdekes cikkem a témában, ami túlmutat azon.

Wow, jó sok knowledge szagát érzem!

Én eddig egy termosztátban használom csak a kontroller belső EEPROM-ját úgy, hogy mindig felülírom az értéket, ha a felhasználó kattint. Például egy 20->23 állítás összesen 6 írás, mert félfokonként ír.

Ez már sok lehet? Mennyi az annyi?

Ez attól függ. Az MCU specifikációjában benne kell legyen az élettartama az EEPROM-nak + a blokkmérete (létezik sajnos flash EEPROM emuláció is).
Én ATmega sorozatban azt tapasztaltam, hogy erősen alul van becsülve a megadott adat. Akár 10x-es eltérés is lehet (pozitív irányban), ha rövid időn belül ölöd meg a cellát. Az írás előtt érdemes mindig várni x időt az utolsó felhasználói interakció után (másodperces nagyságrendben), hogy a felhasználó ide-oda állítgatása ne okozzon túlzott elhasználódást. Ha külön lehet bontani az adott MCU-nál az írást és a törlést, akkor érdemes megnézni a kiíró rutinban, hogy szükség van-e egyáltalán törlésre vagy elég a megfelelő bitet átbillenteni. Érdemes cirkuláris puffert alkalmazni ellenőrző összeggel úgy, hogy mindig átléped az adott memóriahelyet, ha rossz benne a checksum. És van még egy trükk, ami például neked nagyon bevált volna (de ha követed amiket mondtam, akkor nincs rá szükséged), ami majd cikkben lesz, ezért így publikusan nem szeretném leírni, de ha akarod magánban elmondom.

Nekem is tetszik az MSP430, csak a Linux támogatása ne lett volna olyan, amilyen...

...helyesebben anno MSPGCC-vel viszonylag körülményesen sikerült felépíteni egy fejlesztőkörnyezetet, ami jól működött az MSP430G2 LaunchPaddel, ill. egyéb, Spy-Bi-Wire programozható kontrollerekkel.
Időközben az MSPGCC elavulttá vált és ajánlgatták helyette az MSP430-GCC-OPENSOURCE akkori, akkortájt még elég korai változatát... tehát ezt a korai fordítót próbáltam anno, de nagyon elment az egésztől a kedvem, mert irtózatosan nagyméretű binárist fordított az MSPGCC binárisához képest.

Ha az ember <=16kB flash és <=512 byte RAM mellett szeretne dolgozni, akkor ez nagyon nem mindegy...

Meg kellene próbálni, hogy most hol tart a projekt, használható-e már a kisebb kontrollereken is - de némileg elriasztanak a régi tapasztalataim a felélesztésével, és valahogy mostanság kevésbé fontos... sajnos.

Mondjuk néhány hete elővettem az MSP430-at, mert készítettem egy egyszerű mod-ot egy DMM-hez - két gombbal megvalósított kombinációk hatására kapcsol egynéhány gyárilag nem aktivált funkciót, ill. háttérvilágítást gyakorlatilag nem észrevehető fogyasztás mellett.
A régi fordító / fejlesztőkörnyezet még működik, valamikor talán adok egy új esélyt az OpenSource fordítónak is...

Mondjuk ők alapvetően fizetős keretrendszereket szerettek volna adni hozzá...

Mondjuk ez megérhet egy próbát.

Anno a CCS-t (Code Composer Studio) és IAR-t ajánlgatták, az egyik kódlimites volt, a másikkal már nem tudom, mi volt a gondom (lehet, hogy az teljesen fizetős volt akkoriban?)...

A CCS viszont elérhető Linuxra, így lehet, én is ránézek valamikor.
Nem tudom, mennyire kell alakítani rajt, de a múltkori kódomat megnézném, mennyire fordítja másként, egyáltalán működik-e - bár biztosan nem programozom fel újra a céleszközöket. :)

Feltettem az aktuális CSS-t (v8.3) és lefordítottam vele az egyik korábbi programom - a kódon nem kellett módosítani hozzá.

Működést nem próbáltam, és optimalizáción nem állítottam (alapértelmezetten hagytam).
Ilyen feltételek mellett GCC-vel (v7.3.2.154) 2146 byte lett a lefordított kód mérete, a TI v18.1.5 fordítójával pedig 1794 byte ugyanez.

Szintén ez a kód az MSPGCC-vel fordítva - ez mondjuk -O3 kapcsolóval ment - pedig 1708 byte-ra fordult.

Ami furcsa, hogy a CSS v6-os verziójától kezdve Linux / MAC alatt a régi launchpad integrált programozójának támogatását dobták - bár van egy olyan sejtésem, hogy ezeket a rendszereket a korábbi verziók nem támogatták, vagyis valószínűleg egyszerűen nem készítették el hozzá és a létező megoldást sem integrálták.
Az eredeti (G2) Launchpadból csináltak egy új verziót, amire már az újabb programozójuk került, amit támogat a CSS.

Valahol van egy komolyabb programozóm is az MSP430 sorozathoz, de azt elraktam egy ideje és nem olyan egyszerű előkeresnem... az MSP430F5529 launchpadján lévő programozót próbáltam, azzal működik...

Mondjuk jobban örülnék, ha a régi Launchpad támogatása benne lenne...

Igen, ezt en is mindig kulsos eszkozkent hasznaltam/hasznalom. Altalaban I2C-s valtozatot, de van raktaron SPI-s valtozat is ha epp' valami olyasmire van szukseg es/vagy az az egyszerubb. A gyakorlatban nem kell nagy terulet (van olyan alkalmazasunk ahol 8-16 byte miatt kell ez az egesz). De mar csinaltunk beagyazott gepekbe (pcengines/alix) olyan kis modulkat is, amit utana egy egyszeru vfat-os vagy minixes filerendszerkent is fel lehet csatolni :) Na, az mondjuk relative draga, valoban. De ha ez kell, hat... akkor ez kell.