EPROM ST 27128A 4F6 : Kapot of gecodeerd?

Hi,

Ik heb hier een 28 jaar oude motorfiets met Fuel Injection (toen heel modern!) die met een zeer oud type ECU werkt (Weber-Marelli P7 IAW042).
(het schijnt dat 2 van zulke ECU's ook in de Ferrari F40 werden gebruikt).

De ECU /fuel injection van deze fiets werkt goed.
Voor de Ignition maps, Fuel Maps, TPS Maps etc.etc. wordt een EPROM gebruikt Type: ST 27128A 4F6 (zie Datasheet) in deze Weber-Marelli ECU.
Volgens het datasheet is het een NMOS ? EPROM .

Ik heb de EPROM uitgelezen (Zie BIN 1), en ook weer gekopieerd op een andere EPROM AMD 27C128 (een C MOS EPROM).
Vervolgens de Kopie EPROM weer getest in de ECU. Alles goed gegaan. Fuel injection werkt zoals het moet; De motor loopt goed.

Nu heb ik een tweede identieke P7 IAW042 Wber Marelli ECU die op een andere motor plotseling niet meer werkte (ca 1994), althans volgens de eigenaar.
De kast plus EPROM werd in zijn geheel vervangen door een nieuwe door de motordealer.
De defekte P7 kast werd later naar een bekende ECU reparateur gestuurd maar elektronisch goed bevonden.
Daarna werd er niets meer met deze P7 ECU gedaan ; hij is nu weer boven water gekomen bij de voormalige motorhandelaar.

Ik heb de EPROM (ook een ST 27128A 4F6) uitgelezen (zie BIN2), en bekeken in een HEX editor (HxD).
Ik constateer nu dat er een groot leeg blok zit (allemaal FF jes) , daar waar de andere (goede) EPROM meteen data heeft (beginnend met 86 16 97 03 etc).
De andere EPROM begint later ook met het blok 86 16 97 03 etc maar pas een heel eind later.

Mijn vragen nu:

1) Is de tweede EPROM kapot gegaan of misschien gecodeerd?
2) Kan het zo zijn dat er vroeger dmv Tuning Hardware EPROMS gecodeerd werden, door specifiek bepaalde blokken in de EPROM te verplaatsen?

Wanneer ik die BINS met Tuning Software (TunerPro) uitlees, krijg je bij de goede EPROM BIN 1 realistische Fuel, Ignition Maps te zien, maar bij de "kapotte" EPROM BIN 2 alleen maar lege geheugenplaatsen.
(of hij ziet de Fuel, Ignition data niet omdat ze verschoven zijn).

1 map is echter bij alle 2 EPROMS hetzelfde en goed (nl de TPS map).

Blijkbaar is de tweede EPROM dus niet helemaal defekt (of zijn niet alle blokken verschoven)

Kan iemand nog wat toevoegen aan het bovenstaande?
(Ik ben geen elektronicus of programmeur and kan ook niet met HEX omgaan).
1) Kunnen door kapot gaan van de EPROM geheugenblokken opschuiven?
2) Ik heb wel eens gelezen dat sommige Tuning EPROMS met een speciaal voetje werden geleverd (er werden dan waarschijnlijk adreslijnen verschoven).
Voor iedere EPROM werd er een bijbehorend voetje bijgeleverd (zo waren een behoorlijk aantal hardware sleutels mogelijk en was kopiëren van een EPROM zinloos als je niet het goede voetje had).
Zou iets dergelijks ook voor deze EPROM gelden (bijbehorend voetje weggelaten?).
Maar dat zou betekenen dat de eigenaar toch aan de ECU had gerommeld!

NB
In een iets latere versie P8 van Marelli Weber ECU's werd naar interne EEPROM in de ECU geschreven. (Dit EEPROM werd door de fabrikant alleen gebruikt voor opslag van foutcodes).
Maar tuning software / EPROMS gebruikten lege plaatsen ook, om differentiele maps en versleuteling op te slaan.
Maar dat is in deze P7 IAW042 ECU niet aan de orde: die had nl helemaal geen intern EEPROM!!

Alvast bedankt voor verdere info met deze puzzle!

Aan EPROM's valt niks te coderen; het is wat het is...
Heb je wel dezelfde snelheid gekozen? (een te trage eprom gaat ook niet werken)

De oude eprom is ook een NMOS, terwijl de nieuwe een CMOS is. Dat kan in sommige gevallen verschil maken.

[Bericht gewijzigd door Arco op 23 augustus 2020 11:16:14 (29%)]

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Bij mijn weten kun je niets coderen aan een eprom. Er kunnen wel delen defect raken of niet meer werken.

Ik weet dat bij Ram chips tijdens de productie wel eens delen niet werkten. De chips werden gedeclassificeerd en goedkoper in de markt gezet. Een 2048 byte werd dan een 1024 byte ram. Maar of dat ook bij eproms gedaan werd weet ik niet. Als dat gedaan werd kan ik me voorstellen dat fabrikanten van apparatuur iets deden met jumpers of speciale voetjes om de juiste memoryblokken aan te sturen zonder dat de cpu daar iets van merkt.

Als dit zo is zou je zelf de blokken kunnen verschuiven of in hardware iets kunnen wijzigen aan de adreslijnen.

Als je op alle memoryplaatsen FF leest dan zijn die geheugenplaatsen in elk geval echt leeg of gewoon stuk. Maar gecodeerd is het niet.

Arco,

Bedankt voor je reaktie.
Een EPROM kun je inderdaad niet opnieuw beschrijven (behalve na wissen met UV licht), maar je kun wel de image op de EPROM coderen (xxx mogelijkheden voor een 16K x 8 27128A EPROM).

Deze hardware matige codering werkte zoals ik eerder heb beschreven:

De EPROM werd in een speciaal voetje gezet, waarvan de adreslijnen bewust verwisseld werden (XXX mogelijkheden om te coderen).

De EPROM werd dan zo beschreven dat, in combinatie met het correct hardwarematig versleutelde EPROM voetje, toch de adreslijnen op de voet van de printplaat van de ECU weer op de correcte plaats stonden.
Zo waren er een heel scala van EPROM images en bijbehorende gecodeerde EPROM voetjes mogelijk (waardoor kopieren van zo'n EPROM moeilijk gemaakt werd).
Je moest al een bijbehorend EPROM voetje hebben.
Ik vermoed dat dat voor deze EPROM ook het geval was, maar dan klopt het verhaal van de eigenaar niet dat hij nooit aan de ECU had gezeten!

NB
De "kapotte" EPROM is correct door mij uitgelezen (ik heb 2 verschillende EPROM readers / branders gebruikt en de uitgelezen BINS waren helemaal identiek:
Er is een File Compare utility in o.a. HxD waarmee je onmiddellijk kunt zien waar eventuele verschillen tussen twee BIN's zitten.
In dit geval waren ze bit identiek: dus goed uitgelezen.

Dus nee, ligt niet aan foutief uitlezen van de "kapotte" EPROM, maar ik ben er vrijwel van overtuigd dat blokken (adreslijnen) door elkaar gehusseld zijn, maar het ontbreekt me aan de kennis om te bepalen waar ieder blok eindigt (gezien het een 16K x 8 EPROM is).

Overigens hierbij nog wat info hoe dit versleutelen softwarematig in de P8 ECU (met intern EEPROM ) werd gedaan.
Dit was al weer heel wat meer sophisticated, omdat er in de P8 ECU al EEPROM (Electrically Ereasable dus) , naast een EPROM (niet ereasable in een voetje) in de ECU zat.

De EEPROM werd versleuteld werd door de FIM EPROM.
Mooie en clevere oplossing!

@ Ex fietser,

Jouw opmerkingen mbt coderen van de EPROM mbt adreslijnen en speciale hardware matig EPROM voetjes) is IDD correct IMO, voor deze EPROM.

Mijn probleem is alleen dat dan de historie van de EPROM niet klopt.
(De EPROM zou nog helemaal origineel zou zijn, en de 1ste eigenaar zou nooit aan de ECU/motor hebben gesleuteld .

Ik had gehoopt dat jullie specialisten (door BIN 1 te vergelijken met BIN 2 en wetend dat het een 16K x 8 EPROM is, jullie mij konden vertellen hoe die lijnen verwisseld waren (NB ook de goede EPROM (BIN 1) heeft (in het midden) een groot leeg stuk met FF jes.

Dit is dus in de "kapotte EPROM" naar boven geschoven, waardoor de ECU hem niet meer kan uitlezen.
Het begin blok begint op EPROM 2 bij ofset 000200 (eerste 4 data identiek).

Maar dan zou deze EPROM (de motor) niet spontaan kapot gegaan zijn, maar is er duidelijk een andere (gecodeerde) EPROM (zonder voetje! ingezet.

Raar verhaal dus van die vorige eigenaar!

Op 23 augustus 2020 11:36:29 schreef redguuz:
maar je kun wel de image op de EPROM coderen (xxx mogelijkheden voor een 16K x 8 27128A EPROM).

Deze hardware matige codering werkte zoals ik eerder heb beschreven:

Dat heeft allemaal niks te zien met het kopiëren van een eprom, als je een geschikt kopieertoestel hebt kun je die kopieren, de rest is hardware of software.

LDmicro user.
EricP

mét CE

Er is niks te versleutelen aan EPROM.
Er is ook niks te versleutelen aan EEPROM.

Je het een stel address lijnen en een stel data lijnen. Kies een adres en de data komt eruit. Paar control lijntjes om het ding ook 'uit' te zetten zodat er wat anders bij de bus kan. Meer was het niet. Meer is het niet. En meer gaat het ook niet worden.

Wat natuurlijk zou kunnen is dat men het 'moeilijk' probeert te maken met zo'n voet. Wissel wat address lijnen om. Wissel wat data lijnen om. Dat maakt voor de werking van de EPROM niks uit. Die is gewoon uit te lezen en te copieren. Zonder enig voorbehoud.
Die voet namaken is ook geen rocket science, dus een copietje trekken daarmee ook niet. En als je wilt zien wat de ECU ziet... Dan prik je 'm met voet en al in de programmer en lees je 'm dan uit. Daarna in een nieuwe EPROM en die zonder voet de ECU in. Dan 'ziet' die precies hetzelfde als de originele met voet.

Verder zou het kunnen dat de ECU alleen 4k ofzo aan mapping gebruikt. Dan kun je met een tussenvoetje bepalen welke 4k er uit een 16k EPROM op de bus gezet wordt. En dus meerdere maps in 1 EPROM douwen en evt. snel wisselen zonder fysiek wat te wisselen. Als je het handig doet, wellicht zelfs als het ding in bedrijf is. Maar ook daar: er komt geen enkele vorm van versleuteling aan te pas.

Het door elkaar halen van address of data lijnen maakt het wel wat lastiger om je eigen maps te maken - je moet uitvlooien wat ze gedaan hebben om de juiste waarden te kunnen schrijven. Maar voor een copietje speelt dat probleem uiteraard niet.

Wij deden dat vroeger wel vaker als de routering eenvoudiger werd. Collega had een tooltje waarmee de image van de ROM eenvoudigweg naar de hardware config gemapped werd en daarmee was dat probleem ook verholpen. Voor RAM maakt het al helemaal geen zak uit.

Dus nog een keer: aan een EPROM is niks te versleutelen.

bprosman

Golden Member

Dus nog een keer: aan een EPROM is niks te versleutelen.

Als je op sommige plaatsen $FF ziet werkt ook de "data-adresverwisseltruuk" niet met een tussenvoet. Behalve dan dat op een andere EPROM die $FF op een andere plaats zit maar dan moet het patroon het zelfde zijn. (Zelfde data maar dan op een andere plaats).
Het kan ook zomaar zijn doordat de EPROM niet goed afgeplakt is geweest, of soms zelfs spontaan bitjes "omvallen".

De jongere generatie loopt veel te vaak zijn PIC achterna.

Eprom cellen worden inderdaad niet spontaan 'FF', alleen bij belichting of defect...
Het spontaan omvallen van een enkel bitje kan wel eens gebeuren. Vaak veroorzaakt doordat de eprom voor het programmeren niet lang genoeg gewist is.

Zelfs bij de Voyager 2 is een bitje omgevallen... ;) https://voyager.jpl.nasa.gov/news/details.php?article_id=16
(maar die heeft natuurlijk wel wat moeilijkere omstandigheden als de gemiddelde ECU...)

[Bericht gewijzigd door Arco op 23 augustus 2020 12:32:44 (68%)]

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Eprom cellen worden inderdaad niet spontaan 'FF', alleen bij belichting of defect...

Niet helemaal waar, de verbindingen bestaan uit materiaal in kristal vorm dat bij het programmeren plaatselijk verdampt. Maar die kristalgroei blijft doorgaan, weliswaar zeer traag, maar toch. Met UV gaat de groei zeeeer snel.
Ik weet niet wat de dataretention is van eproms, heb hier geen databoek bij de hand en ben te lui om het op te zoeken.

Groetjs,
eSe

Het jammerlijkste aspect van het leven nu is dat de wetenschap sneller kennis vergaart dan de maatschappij wijsheid. Asimov, Isaac

In eproms verdampt en groeit er (hopelijk ;) ) niets, het is een kwestie van lading verplaatsen.
Enige type waar echt iets verdampte waren oude roms: daar werden niet gebruikte verbindingen 'opgeblazen'...

Retention was vaak 20...40 jaar.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
bprosman

Golden Member

Er zit sowieso een offset in van 8K in de 2e eprom.

Je tabellen (tenminste denk dat dat de tabellen zijn) heb ik niet naar gekeken.

De jongere generatie loopt veel te vaak zijn PIC achterna.
fatbeard

Honourable Member

Als ik het goed begrijp heb jij een goed werkende ECU en een niet-werkende ECU.
Wat ik uit het verhaal niet kan opmaken is of die niet-werkende ECU van hetzelfde type/model motor afkomstig is als de goed werkende.
Wat ik ook niet kan opmaken uit het verhaal is of de niet-werkende het wel gaat doen in jouw motor als je er een succesvol gekopiëerde EPROM uit de goed werkende ECU in plaatst...

Er zijn nu een vier mogelijkheden:

  1. de niet werkende ECU is van / was voor een ander type/model motor, dan is het volkomen logisch dat de EPROM afwijkt...
  2. de niet werkende ECU werkt ook niet met een correcte kopie van de EPROM uit de goed werkende ECU, dan is die ECU echt stuk (ook al is er ooit beweerd dat-ie "electronisch in orde" zou zijn)
  3. de niet werkende ECU werkt wel met een correcte kopie van de EPROM uit de goed werkende ECU, dan is de EPROM uit de niet werkende ECU beschadigd
  4. de firmware in de processor van de niet werkende ECU is anders, dan is het een kwestie van op zoek gaan naar een correcte versie van de EPROM. Veel succes >:)

Bij mogelijkheid 3 kan er redelijk oeverloos gedebatteerd/-speculeerd worden over de oorzaak daarvan (getuige het aantal reacties), maar dat heeft alleen weinig toegevoegde waarde...

FWIW: ik denk dat de vorige eigenaar met onvoldoende kennis van zaken heeft zitten klooien en met een goed verhaal bij de dealer de zaak vervangen heeft gekregen.
Dat die 'repairshop' het ding electronisch in orde heeft bevonden ligt waarschijnlijk in het gebruik van een aparte EPROM met testgegevens...

@eSe: De informatie in een EPROM wordt opgeslagen in een minuscuul condensatortje wat de gate van een MOSFET vormt. Dat condensatortje gaat onder invloed van UV (of een paar weken op 170°) lekken en loopt dan leeg. Het opladen van dat condensatorje gebeurt met een sterk electrisch veld, dat wordt veroorzaakt door de programmeerspanning. Bij de eerste EPROMS was dat 27à28 Volt, latere versies konden volstaan met 12à13 Volt; dat komt door verbeterde productietechnieken.
Hedendaagse EPROMS lijken genoeg te hebben aan 3.3 of 5V, maar die hebben on-chip een spanningsconverter voor de programmeerspanning, de stress in dat deel van de chip beperkt het aantal programmeercycli.
De dataretention van EPROMS wordt alleen beperkt door het aantal kristalfouten in de isolatielaag rondom het condensatortje en ligt tegenwoordig op een jaar of 100.

Wat wel een verschijnsel is om rekening mee te houden is electromigratie, hierdoor kunnen allerhande defecten optreden van uitvallende bits tot harde sluiting.

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

De inhoud van bin2 deugt niet, is 0x2000 verschoven t.o.v. bin1.
(bin1 begint op adres 0x0000, bin2 begint op adres 0x2000)

Die moet verkeerd geprogrammeerd zijn, dat kan niet spontaan gebeuren.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
bprosman

Golden Member

Op 23 augustus 2020 13:20:36 schreef Arco:
De inhoud van bin2 deugt niet, is 0x2000 verschoven t.o.v. bin1.
(bin1 begint op adres 0x0000, bin2 begint op adres 0x2000)

Die moet verkeerd geprogrammeerd zijn, dat kan niet spontaan gebeuren.

Of een "voordegekhoudvoetje" er tussen met A13 aan "1" (Nogmaals heb niet naar de tabellen gekeken)

De jongere generatie loopt veel te vaak zijn PIC achterna.

Misschien heeft die ECU jumpers om verschillende geheugenblokken binnen de eprom te kunnen kiezen?

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Allen,

Hartelijk dank voor jullie reakties.

1)
De "codering"van de EPROM's bij de Weber Marelli P7 ECU, die geen intern EEPROM heeft bestond alleen (voor bepaalde tuning EPROMS) door verwisseling van Data en adreslijnen van de EPROM en speciale bijbehorende voetjes. De EPROM moest in dit speciale (gepaarde) voetje gebruikt worden.
Zo waren toch heel wat sleutels mogelijk van customized EPROM 's en bijbehorend voetjes.
Je kunt dit wel "geen Rocketscience" noemen, maar dit was anno 1985 een voldoende kopieerbeveiliging.
(mensen hadden nauwelijks een PC, laat staan een EPROM brander).

NB De originele P7 Marelli EPROM was helemaal niet beveiligd.

De beveiligingsmethode van de Weber Marelli P8 ECU (hier niet ter discussie) die ook INTERN EEPROM had, maar nog steeds een EPROM in een voetje gebruikte is besproken in het WORD document, dat ik eerder stuurde.
Hier vindt een paring plaats tussen een code in de EPROM en een bijbehorende Code die in het interne EEPROM van de ECU wordt geschreven, dmv speciale Tuning Software.
(dit EEPROM wordt door de fabrikant alleen gebruikt voor de opslag van foutcodes, maar de tuningbedrijven gebruiken dit voor extra data en en versleutelingscode)..
Zo werkt de een custom EPROM enkel in de bijbehorende ECU met de zijn interne ECU EEPROM plus custom sleutel.

Er zijn nu natuurlijk heel wat meer sleutelcodes mogelijk.

2)
Het is duidelijk dat in BIN2 minstens 1 blok 000000 - 0000200 verwisseld is, in de EPROM
Het geheel lege FF datablok, staat nu VOOR ipv achter het eerste Datablok.
Daar kan de ECU dan niet mee omgaan (tenzij je het bijbehorende voetje hebt gebruikt)..

3)
Ik was enkel nieuwsgierig hoe/of 1) en 2) gedaan werd en jullie hebben dit inmiddels bevestigd! Dank!

4)
De CMOS 27C128 EPROM copie van de oorspronkelijke NMOS EPROM 27128 (BIN 1) loopt prima in de motor.
Uitlezen, copieren, branden is allemaal Goed gegaan en ook geen snelheids issue bij kopiëren / uitlezen.
Niks mee met de lezer/brander(s): 2 verschillende kopieën gemaakt op 2 systemen, werken beide in de P7 ECU.

5)
Ik ga de tweede ("defekte") ECU met een bewezen werkende kopie van BIN 1 proberen op de motor.
Als ECU #2 elektronisch niet defekt is, zou de motor dan ook moeten lopen.

6)
In Amerikaanse Auto ECU's werd idd soms een groot EEPROM AMD 29F040 (4 Mb) toegepast in combinatie met een adaptervoet voor de oorspronkelijke 32 Pin EPROM en een selektiekastje (zo kon je bv 8 stuks 512K MAPS kwijt op deze 4MB EEPROM.

Maar, ik dacht dat P7 ECU de volledige 128K nodig heeft (dus de 128 K EPROM (16K x 8) wordt volledig benut).

6)
Ik hoor idd dat nu (na 30-40 jaar EPROM's spontaan beginnen om te vallen bv in STUDER recorders.
Het is IMO dus zaak nu je oude EPROM's uit te lezen, zodat je een back up hebt.

Nog bedankt Allen!

/off topic mode

Ik denk dat ik inderdaad verkeerd ben. Ik had hier een oud boekje van Intel dat ging over crystal growth in eproms onder invloed van UV licht. Vind het boekje niet meer terug, jammer, er stonden mooie microfoto's in van die groei. Ik heb het waarschijnlijk na al die jaren verkeerd geinterpreteerd als programeren/wissen, maar het ging waarschijnlijk over de fouten die kunnen onstaan na herhaaldelijk wissen van de eprom. Sorry, mijn fout, oud geheugen met gaten :-)

Groetjes,
eSe

Het jammerlijkste aspect van het leven nu is dat de wetenschap sneller kennis vergaart dan de maatschappij wijsheid. Asimov, Isaac

@ Fatbeard,

Bedankt voor je uitvoerige, systematische analyse. Ik denk dat je helemaal gelijk hebt!

Ik denk idd dat ("de vorige eigenaar heeft zitten klooien met de tuning EPROMS) en met een mooi verhaal naar de motorhandelaar gegaan is, toen de ECU niet werkte (de garantie was wel afgelopen en de nieuwe ECU kostte toen > Dfl 1000.-, een enorm bedrag!

Ook denk ik dat het bekende ECU reparatiebedrijf destijds (1995) de "defekte ECU" niet volledig heeft (kunnen) testen, maar in ieder geval gemeten heeft dat de Transil beschermings diode, de Fuel injector drives, de ignition drivers en de Fuel pump activatie allen nog OK waren.
Ik weet niet of ze toen de Motorola processor etc ook konden testen (waarschijnlijk niet).

Ik heb inmiddels een bewezen goede kopie van BIN 1 (niet beveiligde, bewezen goede Tuning EPROM) al in de "defekte" ECU gezet.

Als de motor nu loopt met deze ECU (enkel grote stekker ompluggen) was het verhaal van de klant onjuist en heeft hij een "beveiligde" EPROM zonder het bijbehorende voetje gebruikt.

Als de "defekte ECU"ook niet met de goede EPROM BIN1 loopt, is de ECU hardwarematig kapot.

Ik laat het resultaat nog wel weten, eind volgende week.

PS.

De "defekte P7 IAW042 ECU is helemaal identiek met de werkende P7 IAW042 ECU.

PS Fatbeard

Wat ik nog had vergeten te melden.

De ECU's zijn niet alleen identiek maar ook voor hetzelfde type motor.

Echter BIN 1 (werkend) is een Tuning EPROM (voormalige tuner in Schagen)
BIN 2 (in de "defekte ECU") zou de niet beveiligde fabrieks EPROM moeten zijn,

Maar dit kan niet volgens het uitlezen omdat die EPROM BIN 2 een offset van de data heeft, waarmee de ECU niet overweg kan.
Vandaar de conclusie dat er gerommeld is met de EPROM, dit itt wat de klant beweerde.

Zoals gezegd , ga ik idd (een bewezen goede kopie van BIN 1) in de "defekte" ECU testen.

Maar ik had had deze hele discussie ook aangezwengeld om te zien of BIN 2 makkelijk terug aan te passen was door het verschuiven van blokken.
(wetend dat je met het Data blok moet beginnen op adres 00000000.
Hoewel gezegd wordt dat dit "geen Rocketscience" is, is dat helemaal niet zo gemakkelijk.

Het is me (zelfs na uitgebreide navraag tot aan F-Autronica in Italie) niet gelukt om de originele fabrieks BIN2 op de kop te tikken.

Dus we kunnen niet BIN2 met de oorspronkelijke fabrieks BIN2 vergelijken enkel met de gewijzigde tuning EPROM BIN1, die wel functioneert .

Wat bedoel je met 'niet beveiligde eprom'???
(een eprom is nooit beveiligd, je kunt er alleen data in opslaan...)

Verschil tussen beide files is trouwens 0x2000, niet 0x200...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
bprosman

Golden Member

Maar ik had had deze hele discussie ook aangezwengeld om te zien of BIN 2 makkelijk terug aan te passen was door het verschuiven van blokken.
(wetend dat je met het Data blok moet beginnen op adres 00000000.
Hoewel gezegd wordt dat dit "geen Rocketscience" is, is dat helemaal niet zo gemakkelijk.

Makkelijk wil ik niet zeggen maar het moet wel te doen zijn.
Weet je waar de tabellen staan en wat ze doen ?
Want dan zal het verschil in motortuning alleen daar in staan.
Als je A13 "Hoog" maakt zit je al $2000 hoger (en verschuift het blok al), eerste deel is toch leeg maar ik heb niet vergeleken of de tabellen dan ook goed uitkomen.

Dus we kunnen niet BIN2 met de oorspronkelijke fabrieks BIN2 vergelijken

Je hebt toch maar 1 BIN2?

De jongere generatie loopt veel te vaak zijn PIC achterna.

Bin1 is toch al wat je nodig hebt? Waarom dan bin2 aanpassen???

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Hi Arco,

Bedankt voor je correctie!!

Mij is het volgende verteld (let wel voor het latere Weber Marelli P8 systeem, niet voor het P7 systeem, waar deze discussie over ging).

1) In de Weber Marelli P8 zit extra ingebouwd EEPROM, waar, van fabriekswege, foutcodes (defecte sensors enz.) permanent worden opgeslagen.
Dit interne EEPROM wordt nauwelijks benut (er zat nog tamelijk veel reserve geheugen in).
Dit extra geheugen wordt door Tuning Bedrijven gebruikt om data op te slaan (en dit gebied wordt ook nog eens middels een code afgesloten voor verdere toegang door derden)..

NB
De P7 ECU kan alleen foutcodes doorgeven, (wanneer de ECU aanstaat) middels een LED je en een morse signaal (9 meldingen mogelijk).
Als de P7 ECU (motor) wordt uitgezet, vergeet hij spontaan al zijn foutmeldingen.

2) Wanneer een FIM tuning systeem gebruikt werd, werd er (differentiële) maps, met speciale FIM software op het lege deel van de interne ECU EEPROM geschreven.

Ook "locked te"hij de rest van het overtollige EEPROM geheugen, dat je dan enkel met een beveiligingscode kon benaderen of weer wissen in zijn maagdelijke toestand.
(hiervoor werd een HHT (FIM hand Held Tester) of FIM tuning software gebruikt, die met de EEPROM kon communiceren.

3)
Op de FIM EPROM die in de ECU werd geplugd in zijn voetje, stond de oorspronkelijke fabrieksmap plus dezelfde beveiligingscode als op de EEPROM (gepaard).

4) Als je een fabrieks EPROM in je ECU zette, werkte deze normaal (want de software zag de differentiele maps in het EEPROM geheugen niet).

5) Als je de gepaarde FIM EPROM gebruikte (die dezelfde zelfde code als die in de in EEPROM) gebruikte de ECU de originele Fuel, ignition Maps etc . plus daarop gesuperponeerd de "Zone Maps" die in het EEPROM waren opgeslagen.

6) het is me niet duidelijk hoe de ECU de code in de EPROM, vergelijkt met die, die in de EEPROM is opgeslagen, maw ik snap zelf niet hoe die "handshake" werkt.

Wat ik wel weet is dat iemand op het Ducati-MS forum, het hele zaakje ooit gedecompileerd heeft (ook gebruik makend van port sniffers).

Hij kon dan het EEPROM geheugen weer wissen (weer maagdelijk maken) en nieuwe (differentiële maps plus een nieuwe code) op dit EEPROM schrijven.

Maar dan begin je je al aardig in een grijs gebied te begeven.

Als aanhangsel een de beschrijving die ik heb gevonden van het UltiMap systeem en een verwijzing naar een Website:

http://www.sigmaperformance.com/weber-ultimap.html

http://www.sigmaperformance.com/weber.html

++++++++++++

BTW

Ik snapte niet hoe die EPROM, die in de "defekte" P7 ECU zat, ooit zou hebben kunnen werken, zonder dat de eigenaar eraan heeft gezeten

Nu is het wel zonneklaar dat dit wel het geval moet zijn geweest, want in die EPROM staat het startblok wel nog (in ongeschonden staat), maar het is wel verschoven, zoals jij ook al aangaf.

BTW Ik krijg nog een EPROM voor dezelfde ECU voor het zelfde merk (maar ander model) motor: dan kan ik duidelijk zien of deze fabrieks- EPROM ook bij 00000000 begint, zoals het hoort!

Bedankt voor je antwoorden & Hulp!

EricP

mét CE

door verwisseling van Data en adreslijnen van de EPROM en speciale bijbehorende voetjes. De EPROM moest in dit speciale (gepaarde) voetje gebruikt worden.
Zo waren toch heel wat sleutels mogelijk van customized EPROM 's en bijbehorend voetjes.
Je kunt dit wel "geen Rocketscience" noemen, maar dit was anno 1985 een voldoende kopieerbeveiliging.

Wat is de beveiliging dan? Lees 'm uit met voet, programmeer de nieuwe zonder. Klaar. Waar zit de beveiliging?

(mensen hadden nauwelijks een PC, laat staan een EPROM brander).

Dan is een copietje maken natuurlijk hoe dan ook niet mogelijk....

NB De originele P7 Marelli EPROM was helemaal niet beveiligd.

De anderen ook niet hoor. Botweg omdat EPROM zich by design niet leent voor beveiliging.

Hier vindt een paring plaats tussen een code in de EPROM en een bijbehorende Code die in het interne EEPROM van de ECU wordt geschreven, dmv speciale Tuning Software.

Heeft dus niks met voetjes te maken. Maar je zou in de EEPROM een serienummer ofzo kunnen zetten, zodat een bepaalde EPROM alleen in een bepaalde ECU werkt. Neem er 2, compare ze... dan weet je waar die info staat. Ook niet echt een beveiliging, wel?

en en versleutelingscode)..

Je blijft het maar hebben over versleuteling. Heb je nou al eens gekeken hoe EPROM werkt? Er is helemaal niks aan te versleutelen! Dit is gewoon onzin.

Zo werkt de een custom EPROM enkel in de bijbehorende ECU met de zijn interne ECU EEPROM plus custom sleutel.[/i]

Wederom onzin, er is geen versleuteling. Nogmaals, wat zou kunnen is dat ze iets met serienummers doen. Dat heeft echter niks met coderen of versleutelen te maken.

2)
Het is duidelijk dat in BIN2 minstens 1 blok 000000 - 0000200 verwisseld is, in de EPROM
Het geheel lege FF datablok, staat nu VOOR ipv achter het eerste Datablok.
Daar kan de ECU dan niet mee omgaan (tenzij je het bijbehorende voetje hebt gebruikt)..

Ja, of je draait die blokken gewoon ff om. Als in dat voetje een paar address lijnen gewisseld of van mijn part 'hard' hoog of laag gemaakt worden, dan doet dat iets met de address map. Nogmaals: lees het ding met voer ertussen uit, programmeer 'm zonder voet. Klaar.

Ik was enkel nieuwsgierig hoe/of 1) en 2) gedaan werd en jullie hebben dit inmiddels bevestigd! Dank!

Nou ja, je hebt het nog steeds over versleuteling enzo...

Als ECU #2 elektronisch niet defekt is, zou de motor dan ook moeten lopen.

Tenzij die dus een serienummer wat moet matchen verwacht. Als dat zo is, dan zou-ie wel eens niks kunnen doen. De vraag is even waar vandaan de firmware draait. Zit die ook in EPROM (naast de map), dan gaat je verhaal op. Zit die ergens anders, dan wordt het een ander paar mouwen.

Maar, ik dacht dat P7 ECU de volledige 128K nodig heeft (dus de 128 K EPROM (16K x 8) wordt volledig benut).

Dat zou kunnen, maar de stukken met 0xff die er schijnbaar in zitten doen wat anders vermoeden.

Ik hoor idd dat nu (na 30-40 jaar EPROM's spontaan beginnen om te vallen bv in STUDER recorders.
Het is IMO dus zaak nu je oude EPROM's uit te lezen, zodat je een back up hebt.

Een backup hebben kan nooit kwaad natuurlijk. Maar dat omvallen... Valt ook wel mee. Al zullen er best series van bepaalde merken voor zijn die er gevoeliger voor zijn dan anderen. Ik heb echter nog zat van die zooi in het veld zitten die het nog probleemloos doet. En ook lang niet altijd bij 20°C.

Makkelijk wil ik niet zeggen maar het moet wel te doen zijn.

Veel hangt er af van je programmer software. De mijne las destijds een blok data in en als ik wilde programmeren, dan kon ik een offset in de hexdump opgeven, een start address en een size. Als je weet wat waar moet komen, dan is het kinderspel op deze manier.
Daarnaast kon die software ook prima in een image blokken copieren / erasen. Dat zou ook kunnen werken als je genoeg vrije ruimte hebt. En als je programmer het ook kan. Maar ook daar: als je weet wat waarheen moet en de software kan het, is het niet spannend (uitvogelen wat waarheen moet wellicht wel).

Nogmaals: een EPROM kent geen beveiliging. Je zet wat op de address bus en het ding zet wat op de databus (mits enabled). Meer was het niet. Meer is het niet. En het gaat nog steeds niet meer worden.