Svenska ElektronikForumet

Har ett 2764 eprom till ett Intel 8031-chip som inte dumpas 100% säkert, verifieringar ger fel på som värst fyra adresser (lite slumpmässigt) alltid bara första biten som skiljer mellan läst data och omläst data i de fall det blir verifieringsfel. Kan förstås vara så att det är fler fel i koden men att dessa inte ändrar sig.
Det ligger en del text sist som är på tyska, verkar vara interface om man kopplar upp sig eller nåt.

Vill gärna disassemblera för att se om det ser vettigt ut och försöka avgöra vad de fyra svaga bitarna ska vara. Har förstås skinande blanka ben så det är inte anslutningen mellan sockel och krets som krånglar.

Hexadecimala siffror:
174: 14/15
3D6: DF/DE
785: 94/95
1476: 78/79

Såg en annan tråd här som tipsade om en disassemblator men jag hittade inte 8031 i listan:
https://www.onlinedisassembler.com/odaweb/
Nu är det kanske nördigare beteckningar på plattformar än vad jag känner till Intel 8031 passar kanske på något alternativ?

Tacksam för hjälp.

Min erfarenhet av EPROM som började säga upp kontraktet är att det blev mer fel när den var varm. Så jag kylde ner kretsen så gott jag kunde (med nåt jag råkade ha i frysen) och läste ut koden samt skrev den i en ny EEPROM. Sen kunde jag köra på utan problem.

Jag hade sådana funderingar också, kanske lika bra att testa och se om det blir stabilt.

Det blev betydligt fler fel och större variation med kylklamp på (plast emellan). Inte en enda gång gick den igenom verifiering.


7
27
86
124
125
127
150 9C/9D/9E/9F !
155
184
osv

Programmet stannar efter första verifieringsfel så man får jämföra filerna för att få hela "bilden".
Ser inte ljust ut då...

En disassembler för 8031 är ganska trivial. https://itsme.home.xs4all.nl/projects/disassemblers/

Just det, har ju IDA på andra datorn, men med tanke på läsresultatet kanske det inte är någon idé att hålla på.

Cirka 50 bytes some varierar (utspritt ganska jämnt över hela filen) i huvudsak på första biten... Bitrot?

Det är nog risk för bitrot - är Epromarna typ 10 år gamla och/eller inte korrekt brända exakt efter tillverkarens instruktion/eller haft vanliga pappersklisterlappar som täcker fönstren och inte av ljustät aluminium så kan de fallera långt tidigare än lovad tid. Lysrörsljus som når och lyser på ett eprom med vit papperslapp för fönstren kan radera den så att den börja ge de första bitfelen efter ca 3 år...

Inte alls ovanligt att man brände Epromar med en 'generisk algoritm' eller den valda algoritmen som lämnades sist i brännaren med både fel spänning och tid per bränd byte när man tex. gick från 27C32-eprom av Texas Instruments modell till en 27C32 av Signetics-Tomson (ST) eller blandad kompott ut lådan med raderade prommar.

Gör man fel i bränningen så kan man tappa flera år hållbarhet och bitpositioner som börja 'fladdra' är typisk indikation att minnesscellen är på detekteringsgränsen att ha tappa så mycket laddning att det visar fel.

Det finns your-tube snuttar där man läser av Eprom och visa bitarna som matris på monitor, samtidigt som man UV-raderar dessa, - dom första bitarna börja fladdra redan efter kort tids UV-belysning och man ser snabbt tydliga blockstrukturer hur det raderas ojämt med strukturer i rad/kolumn där bit 7 i Byten kan hålla 8 ggr längre i tiden än bit 1 under raderingen

---

Ha du (korrekt!) hex-fil på eprommets innehåll ?? (för att verifiera så måste man ha något att jämföra emot, eller är det verifiering mot inbyggda checksummor som gör att du upptäcker felet??)

Jag gissar på över 20 år...

AEG Logistat A020 står det i slutet på eprom-dumpen, googlade och hittade likadana PLC-lådor på nätet men den jag har har annan text, den är från Italien så... inte så förvånande.

Frågan är om det är någon slags standard-programvara i Eprommet och det bara är programmet som är sparat i det eeprom som är lödat på kortet. Testade SRAM:et med (MB8416) - det var inga problem där (slumpvis skrivning med verifiering x gånger).

Finns som "Modicon" med:
http://www.spares4less.com/bilder/produ ... 628_b3.jpg


Nä, som jag nämnde så kan det ju vara massor med fel, noterade bara de bitar som ändrar sig från gång till annan.
Hade jag haft korrekta data så kunde jag ju bara gjort ett nytt - disassemblering fanns i tankarna när jag bara hade fyra flaxande bitar.

Antar att det inte hjälper att ändra på matningsspänningen, det är kört?

Man kan prova att justera matningsspänningen lite upp och med (inom rimlig nivå) och se om fladdret minskar/upphör, likaså kyla och värma samtidigt som man justera spänningen.

Problemet är att veta om innehållet är felfritt om man inte har en checksumma eller liknande som kan kvittera att innehållet är troligt rätt - finns det en checksumma, vilket det ofta finns, kanske tryck på prometiketten, ofta med 4 hexadecimala siffror (ofta sista siffrorna i en större checksumma som tex. din 'A020') och vet man hur den räknas fram (om det är prombrännar-checksumma så går det ofta leta fram algoritmen) så kanske man får ta en stor mängd avläsningar av innehållet - pussla olika delar tills checksumman stämmer

Medans du läser ut så har du påverkan av tex. 50/100 Hz i övertonerna som smittar av sig på de fladdrande bitarna vilket också kan ge 'tips' vilket status de egentligen är om man analyserar samma bit på varje avläst image över en längre tid med en lång rad samplingar - det du vill fånga är om en '1' plötsligt läses som '0' på en viss adress vid upprepande kontinuerlig avläsning.

En av de första sakerna att prova vid analys är med 'regler' som att en konstant '1' förmodligen har varit '1' sedan programmeringen gjordes medans en bit som ibland slår till en '0' (om så bara en gång i månaden vid konstant avläsning dygnet runt) förmodligen har varit en '0' vid programmering (Epromar går från '0' till '1' vid UV-radering och likaså vid åldring) och den vägen bör få fram ett trolig bitmönster.


Har man 50 bitar som är osäkra så blir det många kombinationer att prova och checksumman med den relativa enkla algoritmer som används kommer att ge rätt i ett flertal fall av dessa bitkombinationer. Kan man med många kompletta tagna image över en större tid och behandla/filtrera så att man bara har 15 helt osäkra bitar kvar så har man större chans att prova genom alla alternativ och få fram helt felfri image. (CRC har också svagheten att flertal olika kombinationer av 'mutationer' i en lite större datasträng ger chans till samma CRC-summa)

Se det lite som att försöka knäcka ett krypto eller vaska fram krypterad/scramblad passord... att disassemblera och se om bitmönstren ger helt orimliga instruktioner är också en del i att minska antal osäkra bitar som komplenet av ovan nämnda metoder

Jo, det är väl nästan som att försöka rädda någon gammal datakassett...

Ska testa lite imorgon, även med annan eprom läsare om det nu kan göra någon skillnad.
Hade ju bara fyra fladdrande bitar innan nedkylningen. En disassemblering borde väl ge lite ledtrådar tycker jag.

När jag tänker på det lite så skulle jag jaga på att om en bit i en byte någon enda gång blir '0' vid en rad avläsningar efter varandra så är den att betrakta som just '0', då att sannolikheten att en '0' blir '1' av åldring är väldigt mycket större än att '1' skulle bli '0'!!

Att det blivit fler fladdrande värde nu kan vara tecken på att många synliga "stabila" '1' egentligen har varit '0' i tidigare liv och helt osynliga vid dom första avläsningarna, och att många nu synliga '0' också börja blinka till '1' då de är på gränsen att trilla över kanten, du vill egentligen räkna in så många 'fladdrande' bit-värden som du kan då dessa är att betrakta som '0'

att ändra spänningar upp och ned och temperaturen upp och ned ändrar detektorgränserna och därmed om en cell läses ut som '1 eller '0' om den är urladdad till precis gränsen att slå om eller precis har gjort det.

Kan testa att läsa dem med min läsare.....

Swech

Om de fladdrande bitarna är 0:or så skulle man ju vilja ha ett program som läser kontinuerligt och låser alla 0:or...

Tack Swech, jag kanske skickar över den till dig då.

Ja, typ men det blir nog att skriva egen lösning i så fall - eller så får man (med automatik) läsa ur image efter image från epromet under lång tid och sedan med liten programsnutt i ett språk man är bekväm med, läsa in image efter image och låsa 0:or i en resulterande image.

xxargs resonemang låter logiskt. Har du lagrat resultaten av de tidigare läsningarna? De går ju att kombinera efteråt.

Kylningen verkar ha hjälpt att hitta fler osäkra bits, ...men samtidigt också visat hur illa det är.

Hur mycket vågar man kyla? Intels datablad säger 0 till +75 C vid läsning och -10 ... +85 under bias, men tillåter ned till -65 grader för lagring. Skulle jag vara desperat så vågade jag nog gå ned en god bit under noll, men att värma kretsen vore jag mer försiktig med.

Beträffande den ursprungliga frågan om disassembler, kanske här finns nåt. http://www.edaboard.com/thread21987.html Visserligen för 8051, men det är samma arkitektur.

Ja ett tiotal läsningar är sparade.
Bitvis AND på inläsningarna då borde spara alla 0:or.