[elektro] PIC16F883 EEPROM adatvesztés

[hg12345]

Hi,

A hibás információ is probléma. :-(

A 886 és 887 uC használom, tapasztalatom szerint ez a sorozat a legüzembiztosabb és EMC/EMI türő (ez be is van mérve :-) az eddig használt PIC16 sorozatból. Gondolom a 883 se különbözik ezektől. 

Semmilyen módon nincs lehetőség a tartalom kiolvasására. Sokat segíthetsz magadon, ha tesztelési időre legalább EEPROM terület védelmét felengeded.
99% hogy csak egy két adat iródott felűl.....!!!!

A tartalmat nem véded ellenörző összeggel, ill hiba javító kódot taralmaz a tárolás?
Ha van elég hely akkár megduplázhatod és hiba esetén az ellenörző összeg alapján helyreállítható a hibás darab.... (nagyon egyszerű megoldás, de nem találja meg a hibát, csak elfedi)

Ha valami csak egyszer íródik azt célszerű a FLASH területre helyezni, persze ez még nem biztositék a 100% adat tartalom megtartásra.  Minden gépben szükséges, az memória tesztelése és a PROGRAM és nem felejtő ADAT területek validitásának vizsgálata. (Érdemes elolvasni 10-40év tartalom megtartást garantálnak a gépkönyvek, ez még rendben is lenne, (40 éve nincs EEPROM...). Mi a garancia, hogy minden darab tudja ezt... Célszerű a hibát az elött felismerni, mielött a felhsználó érzékeli, vagy a folyamat.

Ha csak egyszer használod az EEPROM területet, akkor ezzel kapcsolatos kódot tartalmaz készüléked?
Ha nem akkor valami RAM pointer téved el, persze ez még kevés az átíráshoz, mert a szekvencia nélkül nem megy.  Azt ellenörizni kell, hogy a C a library-ból nem hagyja benne az ehhez szükséges rutinokat...

Ill. még egy probléma lehet, ha az LVP fuse hibásan van konfigurálva, akkor véletlenül kiadhatsz olyan kódsorozatot a külső programozó lábakon, ami törölheti az EEPROM tartalmat. Ilyenkor a teljes belső tartalom 0xFF vehet fel, de úgyan úgy innen is feltölthető adatokkal az EEPROM...

Az EEPROM/FLASH területek a legvédettebbek EMI/EMC zavarok ellen, a szükséges irási energia miatt.
Ilyen hibák esetében a leggyakoribb sérülési hely a RAM terület és a perifériák, ill a processzor regiszterei.. ezek azért ellenállóbbak mint a RAM.
A PIC esetén az EMC hiba amit sikerült kitesztelni, nagy teljesítményű külső zavar hatására, a tápon negativ tüske keletkezik (ez csak sejtés, mert ha bármit ráteszek a tápra, már nem az a táp.... és nem mérhető, a szkóp is megbolondul, pedig nem gagyi....) Ennek hatására a teljes memória tartalom 0x00 vesz fel. Ilyen állapotott csak nagyon, nagyon  kisütött táp bekapcsolása után képes produkálni. A leggtöbbször tele van szemetelve a RAM..... bekapcsolás után.




"János Zakó" <janoszako at gmail.com> írta:
>Csak felmerült bennem, hogy esetleg mindent nulláz, nincs információm.>
Kódvédett a terület, nem tudom kiolvasni.>
Csak egyszer kerül írásra az adat beállításkor, üzem közben csak olvassa.>
>
>
2011/11/8 hg12345 <hg12345 at freemail.hu>:>
> Hi!>
>>
> Kicsit nehezen elképzelhető, hogy a teljes felül íródjon az föleg, hogy minden nulláz.>
> Hogyan ellenörzöd?, mert ha tiltva van az olvasása az E2 területnek, akkor nullát olvasol vissza függetlenül a tartalomtól.>
>>
> Az endurance terhelése megfelelő a chipnek?>
>>
> Inkább valami program hibára gyanakodnék....>
>>
>>
>>
> Acs Gabor <agabor at electrodesign.hu> írta:>
>>És akkor mi van, ha az MPLAB-bal beégetsz valamit az EEPROM-ba (nem a >>
> saját szoftvereddel), az IC-t kiveszed az égetőből, és berakod a fiókba >>
> egy hónapra? Utána visszarakod az égetőbe, kiolvasod az MPLAB-bal.>>
> Tudom, nem gyors tesztmódszer, de pár dolgot kiszűrhetnél vele.>>
>>>
>>>
> Gábor>>
>>>
> 2011.11.08. 19:51 keltezéssel, Zakó János írta:>>
>> Keresek helyette valami más IC-t, de elég hosszadalmas a teszt, mert előfordul hogy 3 hétig jól működik.>>
>>>>
>>>>
>> -----Original Message----->>
>> From: elektro-bounces at tesla.hu [mailto:elektro-bounces at tesla.hu] On Behalf Of Elight>>
>> Sent: Tuesday, November 08, 2011 12:23 PM>>
>> To: elektro at tesla.hu>>
>> Subject: Re: [elektro] PIC16F883 EEPROM adatvesztés>>
>>>>
>> Szia,>>
>>>>
>>>>
>> nem hinném, mert a korrekt fordítók esetén ,>>
>> megnézhető a lefordított forrás ASM-ben is ,>>
>> és a HEX is visszafordítható ASM-re..>>
>>>>
>> Tehát nem lehet érdekük igy trükközni,>>
>> előbb utóbb kiderül, hogy szarul fordít a programk.>>
>>>>
>> Altalában a limit feletti részt nem fordítják le.>>
>> Pesze ha rosszul hackelt akkor akármi is lehet az eredmény.>>
>>>>
>> Inkább beégetési gondra gyanakodnék, vagy hibás chip>>
>> szériára.>>
>> Esetleg megpróbálnám más kipróbált és jól működő chip-re>>
>> átírni és ott is tesztelni.>>
>>>>
>> Persze az EEPROM-ot bizonyos típusoknál>>
>> elég gyorsan hülyé is lehet írni.>>
>> Akkor pedig az irásmennyiséget kell optimalizálni,>>
>> vagy más külső eszközre váltani pl: I2C RAM.>>
>>>>
>> Üdv István>>
>>>>
>>>>
>> 2011.11.08. 12:09:53 dátumon Acs Gabor<agabor at electrodesign.hu>  írta:>>
>>>>
>>> Az lenne a vicces, ha a tört fordítónak lenne ilyen védelme, hogy>>
>>> felismeri hogy tört, és a generált kód időnként ilyesmit produkál.>>
>>>>>
>>> Persze ez nem rátok vonatkozik, biztos vettet használtok, ezt nem>>
>>> tudhatom.>>
>>>>>
>>>>>
>>> Gábor>>
>>>>>
>>>>>
>>> 2011.11.07. 20:57 keltezéssel, János Zakó írta:>>
>>>> Üdv!>>
>>>>>>
>>>> Találkozott már valaki hasonlóval? Nekem még ilyen gondom sosem volt.>>
>>>> Pár hét működés után nullára íródik az EEPROM. Gyakorlatilag minden>>
>>>> darab ezt csinálja. A HI-TECH fordító lehet vicces kedvében?>>
>>>> Minden tanácsot szívesen fogadok.>>
>>>> Előre is köszönöm,>>
>>>>>>
>>>> Jani>>
>>>>>>
>> ----------------------------------------->>
>>            elektro[-flame|-etc]>>
>>>>
>> ----------------------------------------->>
>>            elektro[-flame|-etc]>>
>>>
> ----------------------------------------->>
>          elektro[-flame|-etc]>
>>
> ----------------------------------------->
>          elektro[-flame|-etc]>
>>
>
----------------------------------------->
          elektro[-flame|-etc]