EPROM ST 27128A 4F6 : Kapot of gecodeerd?

Als ik verhaal zo eens doorlees zal de eprom die op 2000h begint ergens op een of andere manier defect geraakt zijn,
maar ik heb ook wel eens extra uitbreidings printen gezien in de P7 en P8 waar een Pal of Gal opzit.
De latere P8 en nog latere ECU's voor Ford en Lancia, Alfa, Ferrari turbo's hadden extra ram en een optie om 32x8k eproms te gebruiken. Zo'n print zou hier wel eens "zoek" geraakt kunnen zijn.

Er zijn wel ecu versie's waarbij de eerste 200 regels FF zijn, dit zijn dan de late versie's met Lambda regeling.

Eprom kan inderdaad geen versleuteling hebben, echter de anti-kopieer printjes werken alleen goed als er een geldig ALE signaal wordt aangeboden, de meeste programmers maken ALE alleen hoog en dan werkt de schakeling niet.
Er zitten soms voorwaarden in bijvoorbeeld als adres A2 hoog is wordt D7 geïnverteerd etc..
Ik heb daar een stukje software voor gemaakt om dit terug te zetten.

Automotive engineer - www.easy-tech.nl

Paul, Eric P

Bedankt voor jullie extra opmerkingen, maar ik moet toch een paar statements corrigeren cq aanvullen:

@ Paul

De betreffende ECU's (de werkende en de niet werkende P7) zijn beide een Weber Marelli P7 IAW042 (042 is het unieke typenummer en betekent dat hardware en firmware identiek is. (NB maar niet noodzakelijkerwijs de EPROM), die werd pas in de Motorfietsfabriek ingebouwd.

Custom geheugen uitbreidingskaartjes worden in de P7 IAW042 NIET gebruikt (het is een motorfiets ECU) voor tweecilinders.

Normaliter zet de motorfietsfabrikant de EPROM in de ECU in de fabriek (na uitgebreide testbank runs met serie exemplaren en ook rekening houdend met de exportmarkt).
EPROM2 is een "fabrieks EPROM (en er is geen tussenvoetje oid)..
(Ducati leverde vervangings ECU's zelfd zonder EPROM; die moest de klant/dealer er dan zelf inzetten).

Samenvattend (zie ook mail van FatBeard):

ECU1 met EPROM1 (een Tuning EPROM, niet de fabriekseprom ) werkt prima in de motor
ECU2 was ooit (1995) elektronisch door een collega bedrijf getest en goed bevonden), maar de ECU2 werkte NIET op een soortgelijke motor.
ECU2 plus EPROM2 lag sindsdien in een magazijnkast.
(nu anno 2020 heb ik uitgevonden dat de EPROM2 in ECU2 zijn data met 200 regels verschoven heeft en dat dat waarschijnlijk de oorzaak is dat de ECU niet werkte (i.e optie #3 Fatbeard is van toepassing).

Verdere aktie:

1) Een derde EPROM, EPROM3 van een derde identieke P7 IAW042 ECU3 (die elektronisch WEL defekt is, door een kapotte spanningsregelaar en foutieve hulpstartprocedure) uitlezen en EPROM3 vergelijken met EPROM1.
Meest waarschijnlijk start EPROM3 ook met adres 0000000, net als EPROM1 (dit in tegenstelling tot EPROM2, die 200 regels FF heeft, VOOR het eerste datablok.
Sommige data van EPROM2 staan echter wel op de goede plek o.a. TPS map, wat de diagnose van de versleuteling moeilijker maakt).

2) Vervolgens de goede EPROM1 in de ECU2 plaatsen en het geheel testen op de motor (ipv ECU1 en EPROM1, wat goed werkt).

Eea is al uitgebreid beredeneerd door FatBeard (Zijn Optie 3 is van toepassing) zie zijn mail.

Ik zal tzt rapporteren
- hoe EPROM3 uitleest en
- of de motor ook loopt op ECU2 en EPROM 1.

In dat geval was ECU2 OK en de EPROM2 defekt. (of verkeerd geprogrammeerd of mist een decodeervoetje).

@ Eric P.

Je gooit helaas de discussie mbt de FIM beveiligingsmethode (voor de P8 ECU's door elkaar met die voor de P7 ECU's ).

De P8 heeft intern EEPROM, de P7 Niet; De hele discussie gaat aanvankelijk over een P7 ECU2 met bijbehorende EPROM2.

(NB Wat ik "sleutel" noem in de P8 discussie, noem jij "Serienummer van de EPROM" (what's in a name);
voor de rest verwijs ik naar de info van FIM zelf (websites en PDF file; die ik al gegeven had. Zij zullen toch zeker wel weten hoe hun systeem werkt.

Overigens was er geen codeervoetje in ECU2 EPROM 2; ik kan dus geen codeervoetje benutten om meer info over EPROM2 te krijgen.
Het is wel zeer waarschijnlijk dat EPROM2 in de huidige configuratie NIET kan werken omdat het eerste datablok blijkbaar 200 regels is opgeschoven.

Remedie, zoals Fatbeard ook al heeft voorgesteld (en ikzelf ook al van plan was:

ECU2 testen met (bewezen goede) EPROM1 in de motor.

De tijd zal het leren.

Bedankt en vriendelijke groeten,

bprosman

Golden Member

Geen 200 regels, $2000 bytes ofwel precies een halve Eprom. Vandaar dat ik de optie noemde adreslijn A13 "hoog" te maken , dan zit je in t 2e deel van de Eprom

De jongere generatie loopt veel te vaak zijn PIC achterna.

Hr bprosman,

Bedankt, maar

Daar wringt nu de schoen. Ik ben een volledige leek mbt HEX.

Als ik mbv een Hexeditor (bv HxD, https://mh-nexus.de/en/hxd/ ) de DAY20 BIN (EPROM2) zou editen naar het formaat van de Misano BIN (EPROM1) of Quota1000 BIN (EPROM3), hoe zou ik dat dan moeten doen?

Welke blokken moet ik dan verschuiven?
Kunt u svp wat uitgebreidere instructies geven?

EricP

mét CE

(NB Wat ik "sleutel" noem in de P8 discussie, noem jij "Serienummer van de EPROM" (what's in a name);

Een serienummer is wat de naam al aangeeft: een nummer binnen een serie. Daar is niks geheims aan. En wordt gebruikt om een device te identificeren.
Een sleutel is iets wat je gebruikt om iets... te ontsleutelen. Er ik niks versleuteld, dus is er ook niks te ontsleutelen. Daarnaast is het hele idee achter een 'ontsleutel sleutel' dat je die geheim houdt - anders kan iedereen het.

En redelijk essentieel verschil dus. Of eigenlijk: het zijn 2 geheel verschillende items die alleen gemeen hebben dat ze een aantal tekens achter elkaar hebben. Maar om jouw telefoon nummer dan ook gelijk maar een 'sleutel' te noemen??

Voor wat betreft die files: ik weet niet wat je bedoelt met 'in ben een volledige leek mbt. HEX'. Het is gewoon een blok data. Niks meer. En niks minder. En met de editor die jij aanhaalt schijn je daarmee een hexadecimale presentatie van dat blok data te kunnen krijgen - zoals je dat waarschijnlijk van elk file kunt.
De betreffende editor ken ik niet. Mijn manier zou denk ik zijn het betreffende file openen. Een nieuw 'ding' beginnen (geen idee hoe deze editor dat noemt). En dan blokken data copieren naar waar je ze hebben wilt - het lijkt erop dat je in hex presentatie gewoon blokken kunt copy-pasten.

Daarnaast blijft natuurlijk de vraag wat er precies in die EPROM zit. Is dat de complete firmware inclusief allerlei tables? Of zijn het alleen de tables?
In het eerste geval zal execution gewoon ergens starten (voor een controller doorgaans op 0x0000). In het 2de geval is het afhankelijk van de firmware waar die in de address map z'n tables verwacht (feitelijk niet anders dan in het eerste geval, alleen dan zit de firmware bij de tables en dan zal het wel kloppen).

Let wel: ik ken beide ECUs niet. Maar heb meer dan genoeg ervaring met dergelijke systeempjes en (naar huidige standaards) 'kleine' bussen en hoe de hardware op zo'n bus met elkaar kletst.

echter de anti-kopieer printjes werken alleen goed als er een geldig ALE signaal wordt aangeboden

Hmz... Een 27128... heeft voor zover ik weet helemaal geen ALE pin. Dat is meer iets uit de 8051 architectuur...

Eric P ,

Weer bedankt voor je bijdrage!

HxD https://mh-nexus.de/en/hxd/ en HexWorkshop http://www.hexworkshop.com/ zijn freeware HEX editors die gratis te downloaden zijn en gebruikt kunnen worden voor manipulatie/editing van (EPROM) BIN's..

Ik ben vaag bekend met EPROMS, EEPROMS etc.
https://xtronics.com/wiki/How_EPROMS_Work.html
maar heb helaas wel soms de "klok horen luiden etc.)

Ik meen gelezen te hebben dat in de EPROM in de Weber Marelli P7 IAW042 ECU enkel de MAPS stonden (en geen firmware), maar dat weet ik niet 100% zeker.

Ik bens op zoek geweest naar de originele DAY20 Moto Guzzi fabrieks EPROM, om te zien hoe de "DAY20" (EPROM2) in ECU2 afwijkt van het origineel.

Helaas heb ik de originele DAY20 EPROM of BIN niet kunnen vinden, dus ik kan niet met zekerheid afleiden hoe de "DAY20" EPROM2 in ECU2 is veranderd (of misschien simpelweg beschadigd), vergeleken met het origineel.

Dit was de kern van mijn vraag in dit topic (zie titel).

Vergelijking met EPROM1 (zelfde Motortype maar een Tuning EPROM) en EPROM 3 (ander motor type, originele fabrieksEPROM), beide zelfde ECU (P7 IAW042) en zelfde merk motor, levert meer variabelen, wat diagnose/decompilatie erg lastig maakt maar geeft toch wat clues.
Er zijn nl. hele stukken identiek.

BTW
In de Motor Tuning Software (freeware) TunerPro https://www.tunerpro.net/ wordt een zgn XDF file gebruikt ( naast de EPROM BIN file).
De XDF file verwijst het TunerPro programma waar hij exact in de BIN moet kijken voor de lokatie van Fuel Maps, Ignition Maps etc etc.,) voor een bepaald type ECU en merk motor..
Dus er is veel werk gedaan om uit te dokteren, waar die MAPS staan voor bv. de P7 IAW042 voor Moto Guzzi, Ducati, Laverda etc.

Helaas zijn die locaties niet diect uit de XDF file te herleiden.
(consultatie met degene die deze XDF 's heeft ontwikkeld ("Beard" https://www.von-der-salierburg.de/download/GuzziDiag/ zal ongetwijfeld het goede antwoord geven, maar ik laat het maar hierbij.

Wat mij betreft is de "DAY20" EPROM2 onbruikbaar (en zal het veel moeite kosten, om uit te zoeken hoe deze nu veranderd (cq beschadigd is) vergeleken met de originele DAY20 Fabrieks EPROM.

Ik ga simpelweg EPROM1 in ECU2 testen. Als dit werkt wordt ECU2 plus EPROM1 een back up ECU voor de bestaande ECU1 plus EPROM1, voor het geval dat ECU1 het ooit begeeft.

Helaas kost het oplossen van het "gecodeerde" (of beschadigde EPROM2) te veel tijd. Misschien tzt een puzzle voor de winter.

Nog bedankt aan allen die zo'n uitgebreide bijdragen hebben geleverd !!

EricP

mét CE

HxD https://mh-nexus.de/en/hxd/ en HexWorkshop http://www.hexworkshop.com/ zijn

Ja, zover was ik. Maar ik ken de editor niet en ga niet op zoek naar een windows-ding om 'm te leren kennen. Die klus is voor jou :)

maar heb helaas wel soms de "klok horen luiden etc.)

De melk wel horen klotsen maar niet weten waar de tepel hangt :)

Ik meen gelezen te hebben dat in de EPROM in de Weber Marelli P7 IAW042 ECU enkel de MAPS stonden (en geen firmware), maar dat weet ik niet 100% zeker.

Ach, je hebt het ding daar liggen. 'SOCs' hadden ze toen nog niet. Je zult waarschijnlijk wel een processor kunnen ontdekken (met de opmerking van Paul W. over ALE zou dat zomaar een 8051-derivaat kunnen zijn). Daarnaast zul je het nodige aan memory moeten kunnen vinden. De RAM is denk ik vanzelf sprekend. Als er verder niks 'ROM-achtigs' aanwezig is, dan zal de firmware in de EPROM zitten - het moet tenslotte ergens zitten. Als die er wel is, dan heb je een hele aardige kans dat alleen de parameters in EPROM zitten.

Vergelijking met EPROM1 (zelfde Motortype maar een Tuning EPROM) en EPROM 3 (ander motor type, originele fabrieksEPROM), beide zelfde ECU (P7 IAW042) en zelfde merk motor, levert meer variabelen, wat diagnose/decompilatie erg lastig maakt maar geeft toch wat clues.
Er zijn nl. hele stukken identiek.

Dat zou ook de firmware kunnen zijn he...

De XDF file verwijst het TunerPro programma waar hij exact in de BIN moet kijken voor de lokatie van Fuel Maps, Ignition Maps etc etc.,) voor een bepaald type ECU en merk motor..
Dus er is veel werk gedaan om uit te dokteren, waar die MAPS staan voor bv. de P7 IAW042 voor Moto Guzzi, Ducati, Laverda etc.

Precies. Maar dat staat los van het feit van waar de firmware staat. Ik kan zo'n xdf file gewoon lezen - het lijkt platte ASCII te zijn in iets XLM achtigs. Je kunt redelijk makkelijk vinden wat op welk address zit. Echter... als er een voetje tussen zit wat met address lijnen rommelt, dan is je map uiteraard anders. En als-ie met data lijnen rommelt, dan kloppen je adressen wel, maar slaat de data nergens op.

Als je ermee wilt spelen, dan zou je eens een file met alleen 0xff (of 0x00) kunnen nemen, inlezen in die tool, 1 waarde veranderen en kijken op welk address dat gebeurt. Dan kun je heel snel zien hoe de waarden in die xdg matchen op de adressen.

Helaas zijn die locaties niet diect uit de XDF file te herleiden.

Ik denk dat dat dus wel mee valt. Maar het is wel ff zoeken ja. En vooral tijd in steken. Een beetje kennis van de architectuur van de controller helpt.

Arco

Special Member

Een eprom heeft inderdaad geen ALE, alleen een OE...

Of je het blok data van 0x2000 naar 0x0000 kunt verhuizen hangt af van de opbouw van de firmware. Als er jumps naar andere delen van de firmware inzitten, sowieso niet.
Om dat te weten moet je de file door een disassembler voor de betreffende microcontroller halen.
Op zich is het verplaatsen simpel te doen.

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

Eric P, ARCO,

Hierbij, FYI, nog een lijstje van de spec's van de IC's die in mijn Weber Marelli P7 IAW042 ECU gebruikt worden (muv de spanningsregelaar)..

De U processor is een Motorola 6803U4 met intern RAM

Er is geen functionerend ROM in deze 6803U4, wel 192 bytes! RAM

De firmware moet dus inderdaad op de EPROM M27128 staan (naast de Fuelmaps, Onstekingsmaps etc. etc.)

De rest van jullie aanbevelingen/instructies gaat mij boven mijn pet,

Het is meer een "Nice to Know" om de fabrieks-EPROM DAY20 te restaureren, omdat ik toch de MISANO EPROM ga gebruiken in ECU2.

Maar, ik weet nog steeds niet of het verschuiven van de blokken het resultaat is van een

1) een defekt geraakte EPROM (niet waarschijnlijk),
2) een verkeerde (mislukte) programmering
of
3) toch een bepaalde beveiliging met Hardware (zoals een speciaal voetje).
(NB er zat geen speciaal voetje in ECU2)

Kunnen jullie svp nog jullie mening hierover geven ??

Bedankt nogmaals!

Arco

Special Member

De programmering is moedwillig zo gedaan, kan niet spontaan veranderen. Of het zo een levensvatbare firmware is valt zo niet te voorspellen...

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

De eprom lijkt mij zo geprogrammeerd te zijn. Ik denk dat er een extra printje met adres decoder met wat Ram of zo tussen gezeten heeft.
Overigens is de foto van jouw ECU?
Dit lijkt mij al een latere versie te zijn met 2x LM2904 voor de krukas en nokkenas sensor, de eerste hadden een LM1815.
Heb je een foto van de "foute" eprom sticker?
Ik heb wel e.e.a. van Ducati aan programma's (beginnen allemaal netjes op adres 0000h).

Automotive engineer - www.easy-tech.nl
EricP

mét CE

Ik heb ff naar die controller zitten kijken. In mode 2 zou die EPROM zonder trucen in de bovenste 16k passen. De reset vector zit op 0xffff0xfffe als ik het goed begrepen heb. Het address wat daar staat, bepaalt dus waar de jump na een reset heen gaat. Dat zou op 0xc000 kunnen zijn (address 0x0000 van de EPROM als die op de bovenste 16k gemapped zit). Maar dat hoeft niet.

In mode 3, kom je minder goed weg. Je MOET de interrupt vectors in ROM hebben zitten, echter van 0xd040-0xd0ff zit internal RAM in die mode. Dat mapped niet lekker met 16k ROM.

Ik ben te lui om die files door te spitten (sorry, die tijd heb ik wel een beetje gehad). Maar het lijkt erop dat de reset vector op 0xfffe (MSB) en 0xffff (LSB) zit. Kijk eens wat er op de hoogste 2 bytes van de EPROM staat? Het lijkt een platte address map te zijn, dus als je daaruit een address destilleert en daar 0xc000 vanaf trekt, dan zou het de start van de code in de EPROM kunnen zijn. Dan zie je ook gelijk of het 'fout' is dat er eerst een stuk 'niks' in zit. Of niet.

De reden van eerst een stuk 'niks' zou kunnen zijn dat men ook met een 2764 bezig is geweest. Die zou je dan op de bovenste 8k kunnen adresseren. Mits op het juiste start address in een 27128 geschoten, werkt dat ook (de 2764 werd op een bepaald moment duur en minder verkrijgbaar, nog erger dan de 2732; ik kan me voorstellen dat een 128 goedkoper was, zeker in OTP).

bprosman

Golden Member

Mits op het juiste start address in een 27128 geschoten, werkt dat ook (de 2764 werd op een bepaald moment duur en minder verkrijgbaar, nog erger dan de 2732; ik kan me voorstellen dat een 128 goedkoper was, zeker in OTP).

Vandaar mijn eerder gemaakte A13 opmerking.

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

Special Member

De 6803 CPU kan 32k eprom (27256) adresseren dus dat zal 't probleem niet zijn...

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

Paul W., Eric P., Hr.bprosman,

Bedankt voor de reakties, helaas zal ik de verschillende adviezens nog goed moeten doorspitten; It is allemaal erg cryptisch voor mij.

1) De foto's in mijn vorige mail zijn van de (mijn eigen) goede ECU1 met de goede (maar niet originele) Tuning EPROM (EPROM1), destijd gemaakt door Misano Motors in Schagen, die s ook een testbank had (eea volgens MGCN Members).
De Misano EPROM werkt goed in mijn motor (was daarin ook gemonteerd) en heeft een ST 27128A EPROM (geen PROM!).
Deze ECU1 is waarschijnlijk gefabriceerd eind 1991 (de motor werd in 1992 verkocht).

2) Hierbij een foto van de ECU2 (van de ex Motorhandelaar).
Deze ECU2 was ook van een vroege MG Daytona en is waarschijnlijk ook eind 1991 gefabriceerd.
Deze ECU2 was, volgens het ECU reparatiebedrijf destijds (1995) goed bevonden (althans Electronisch).
In deze ECU2 zat de "originele ?" Fabrieks EPROM (EPROM2), DAY20A die zo merkwaardig uitleest (start met 200 regels FF).
Het is ook een ST M27128A 4F6, maar is eerder gebruikt (zie lijmresten van een eerdere sticker). Er was ook geen tussen voetje zoals jullie kunnen zien.

Ook een zoom in van de EPROM2, FYI en nogmaals de BIN (Day20 BIN).

3) Volledigheidshalve nog een BIN van een derde EPROM (BIN3) van een Moto Guzzi Quota 1000, een andere model motor dus, maar van hetzelfde merk en gebruikmakend van weer dezelfde ECU type P7 IAW042 (ECU3).

4) Als laatste, een andere originele Daytona ECU (zij het de vervanger P7 IAW 441 met een EPROM4, die ook gemerkt is met DAY20.
(De eigenaar wil deze EPROM helaas niet laten uitlezen; het zou de originele Fabrieks Eprom DAY20 kunnen zijn waar ik naar op zoek was.
De EPROM is wederom een ST M27128A en is ook eerder gebruikt, dus het is maar de vraag of dit de originele DAY20 EPROM is, wat op de sticker staat.

EPROM1 en EPROM3 beginnen bij adres 00000000, de EPROM2 pas 200 regels verder, (EPROM 4 niet uitgelezen)..

EPROM2 gedraagt zich merkwaardig en daarom ga ik ECU2 met EPROM1 (Misano) testen.

Hierbij nog de MG Quota1000 BIN (EPROM3) voor een P7 IAW042

EricP

mét CE

DAY20A die zo merkwaardig uitleest (start met 200 regels FF).

Als je mijn verhaal had gelezen, dan had je nu geweten dat dat helemaal niet merkwaardig hoeft te zijn. Verder lijkje die EPROM gewoon goed te kunnen lezen, dus wat er merkwaardig is aan 'uitlezen'???

Verder wordt een EPROM niet opgedeeld in regels maar in bytes. Jouw binairy file editor maakt er regels van. De kreet '200 regels' heeft dus alleen betekenis in de context van de door jou gebruikte editor - geen idee hoe lang een regel bij jou is! Daarnaast is in deze wereld '200' en raar getal - dat past niet in een mooi aantal bitjes.

EPROM2 gedraagt zich merkwaardig

Nogmaals, die EPROM lijkt zich prima te gedragen. Je lees 'm een paar keer en elke keer komt er hetzelfde uit. Niks merkwaardigs aan. Dat er op 0x0000 een blok met 0xff begint is niet raar, maar, nogmaals, kan met de vermoedelijke memory mapping van de controller (mode 2; ook specifiek voor deze serie, dus RTFD) prima 'valide' zijn.
Als je wilt weten in welke mode de controller draait, dan moet je iets meer onderzoek doen. In de datasheet staat naar welke pennetjes de 'reset logic' kijkt om de mode te bepalen. Nogmaals, in deze setting lijkt mode 2 voor de hand te liggen omdat de memory map dan mooi past. Het is echter een ongeverifieerde aanname; de documentatie van de ECU (die je dus hoogst waarschijnlijk niet gaat vinden...) zou uitsluitsel kunnen bieden. Een beetje reverse-engineering ook.

Overigens is het type EPROM niet zo heel spannend. Zo lang het ding snel genoeg is en de hoeveelheid data die erin gefrot wordt kan erin, zal het allemaal wel. Als je een 27256 zou nemen en de hoogste address pin extern schakelbaar zou maken, dan zou je daar 2 images van de 27128 in kwijt kunnen. En met de schakelaar kunnen kiezen welke de controller 'ziet'. Die controller gaat daar helemaal niks van merken (nou ja, het zou zomaar kunnen struikelen als je omschakelt terwijl de boel draait natuurlijk).
Verder is het ook prima mogelijk om 2x een 2764 te nemen, de hoogste address bit te inverteren en aan de ene de geïnverteerde en aan de andere de niet-geïnverteerde aan te bieden. Wederom: de controller merkt daar helemaal niks van. (feitelijk kun je het met elke address pin doen, alleen de juiste data op de juiste plek in de EPROM krijgen wordt iets ingewikkelder...; vroeger deed men het wel met 'odd' en 'even' met A0. De reden was snelheid als ik het me goed herinner)

De 6803 CPU kan 32k eprom (27256) adresseren dus dat zal 't probleem niet zijn...

En nog wel meer ook. Alleen wordt het wat trucen met adressering - je zult wat 'glue logic' nodig hebben :+ .

Hi Eric P,

AA)
Dank voor je antwoord, maar je wilt (kunt) mijn probleem niet zien, dat ik enkel een aantal simpele pragmatische vragen had (zie Titel van het topic) en gedetailleerde/specialistische antwoorden mbt digitale programmering niet kan snappen, gegeven mijn totale onbekendheid met digitale codering, werking van Mprocessors, adressering van geheugens etc. etc.

Ik kan EPROMS, EEPROMS etc. goed uitlezen met een kloon "Willem" Programmer en/of een een iets modernere "TL866II-Plus" Programmer.
Zo kan ik een BIN 's uit/ of in de EPROM krijgen ( ik heb ook een UV wis kastje).

Ook kan ik de BIN 's zichtbaar maken in in BIN of HEX info mbv HxD of HEX Workshop; dus ik kan IDD blokken verschuiven, meerdere Maps op een EPROM zetten ("stacken" (zie 2, hieronder) etc.
Ik gebruik de HEX editor NIET om onstekingsmaps etc binair te wijzigen.

Vervolgens kan ik realistische ("Real World") motor maps (Ignition, Fuel etc. etc. ) zichtbaar maken in het motor tuning programma TunerPro.
(Hiervoor is een XDF file benodigd, die de hardware van de motor , koppelt met de geheugenplaatsen op de BIN; Deze XDF files zijn beschikbaar op specialistische fora)

Hier kan ik nu iets mee;
In TunerPro kan ik de ontsteking verlaten/vervroegen, de Fuel injectie rijker/armer zetten, temperatuur en druk correctie van sensors aanpassen/kalibreren, max toerental instellen etc. etc.
Met TunerPro kan zo een fuel injection motor afgesteld worden met tools die een motortuner begrijpt.

Normaal wordt een motor op de testbank ("rolling road") geoptimaliseerd, maar je zou het ook met simpele "Trial and Error procedure" op een verlaten weg in de avond (of zoals we voeger deden: op een oude (verlaten) landingsbaan van een verlaten WW2 vliegveld kunnen doen.
Of op een race circuit, zoals hier in de buurt.

De bovenstaande "workflow" is helemaal uitvoerbaar voor EPROM1 en EPROM3, maar voor EPROM2 ging dat beslist niet.

De issue was nu alleen (zie nogmaals heading van het Topic):

"Was deze EPROM2 kapot[/i]
of
Was deze EPROM2 op een niet normale (voor deze ECU in de motortoepassing) gemanipuleerd?"

Ik vermoedde nl dat er gerommeld was met het systeem (maar dit werd ontkend door de eigenaar) en dat er wellicht ooit een "tussenvoetje" was gemonteerd, wat niet meer aanwezig was.

Ik vroeg me ook af (als een EPROM gedeeltelijk fysisch kapot gegaan zou zijn) of adreslijnen naar beneden verschoven hadden kunnen zijn.
(Het antwoord op het laatste, weet ik nu, is een categorisch Nee).

Samenvattend:

1) EPROM2 is niet fysisch kapot (dit geeft trouwens meer zekerheid dat die dingen toch nog redelijk stabiel zijn)

2) De EPROM2 kan met een voetje gebruikt zijn om meer mappen in 1 grotere EPROM te zetten (het is iid mogelijk maximaal 4 mappen te zetten ("Stacken") op een 256K EPROM welke nog in de P7 gezet kan worden), zie schema van een MGCN member, die hij ooit voor mij maakte.
Hiervoor wordt een speciaal tussenvoetje gebruikt zie bv.
http://www.moates.net/font-size-12timerfont-p-80.html?cPath=31
voor 2 x 256K maps op een EEPROM 27SF512 en een keuze schakelaar.

Zo'n tussen EPROM selectie voetje (evt. met jumpers) zat niet in de ECU.

3) Er is een apart tussenvoetje met extra RAM gebruikt.

De P7 is nl een "Racecomputer" (werd veel in races gebruikt). Hij had een aantal interessante features, zelfs gegeven het feit dat het een simpel ding was; zie:

https://books.google.nl/books?id=wC2dThrY2BMC&pg=PA109&lpg=PA1…
Pag. 109

Je kon bv in een pitstop binnen 10 seconden een map aanpassen (ECU wel van spanning blijven voorzien, ontsteking aan dus); de differentiële maps werden in het RAM geschreven.
Als die mapping beviel, kon je de wijzigingen (later) alsnog opslaan in een EPROM, zoals gebruikelijk.

Wederom, er was geen extra RAM tussenvoetje / extenderboardje in de ECU aanwezig.

4)
Het meest waarschijnlijk scenario voor de geschiedenis van EPROM2 is:

* Tijdens het optimaliseren van de motor op een testbank ("Rolling Poad), werd een EPROM emulator gebruikt ("Rommulator"), zie bv
http://www.moates.net/ostrich-20-the-new-breed-backordered-til-921-p-1…

(De EPROM wordt dan tijdelijk verwijderd en een 28 Pins stekker, wordt tijdelijk in de EPROM voet gestoken.
Met de "Rommulator" kun jij nu "on the fly", met lopende motor op de testbank, de maps (onsteking, Fuel etc) zodanig veranderen dat je een maximale PK (mooi lineair oplopend, zonder dips, en een vlakke Torque curve voor je motor hebt).

* Vervolgens wordt de binaire info van de "Rommulator" gebrand in een EPROM.

* In deze tussenstap is iets fout gegaan (ipv de tussenvoet te monteren voor een EPROM met meerdere Maps) heeft men dit vergeten.

* In het bovenstaande verhaal is het zonneklaar dat de eigenaar met de ECU "geklooid" heeft (hij beweerde dat dit niet het geval was) en dat hij (nadat de ECU niet meer werkte), bij de motorhandelaar (onder garantie een nieuwe ECU probeerde te krijgen).

Zoals gezegd:

Als mijn motor goed werkt met EPROM1 in ECU2 is het hele verhaal duidelijk en ben ik happy.
(ik kan nl ECU2 goedkoop kopen van de motorhandelaar: Win/Win situation en ik heb dan een Reserve ECU, voor het geval dat de normale ECU1/EPROM1 het ooit zou begeven.

Het restaureren van EPROM2 is voor mij niet zo belangrijk (omdat ik toch niet de fabriek BIN DAY2 ga gebruiken).

Tot slot

Ik heb veel mbt Digitale Logica van jou (en andere forum members) opgestoken, maar het meeste moet nog bezinken en ik moet me er nog verder in verdiepen.

Hartelijk bedankt & groeten,

EricP

mét CE

en gedetailleerde/specialistische antwoorden mbt digitale programmering niet kan snappen,

Ow... Dit IS de simpele versie. Met een simpele controller. Iets als een disassembler ed. of trucen met adressering is helemaal nog niet ter sprake gekomen...

"Was deze EPROM2 kapot

Nee dus. Daar zijn we het wel over eens...

Was deze EPROM2 op een niet normale (voor deze ECU in de motortoepassing) gemanipuleerd?

Ik denk het ook niet. Als je ff op de reset vector had gekeken, dan had je het antwoord gehad.

Zoals gezegd: ik denk dat de firmware ook in die EPROM zit. Het zou zomaar custom firmware kunnen zijn. Dus niet de 'fabrieks firmware' waar de maps op bekende locaties staan. Er lijkt mij zo 1-2-3 niks aan 'gemanipuleerd' (what's in a name...).

gegeven mijn totale onbekendheid met digitale codering, werking van Mprocessors, adressering van geheugens etc. etc.

Dat lijkt me toch voorwaarde voordat je aan dit soort dingen knutselt. Nu is het niet meer dan 'aapje - kunstje'. Aan de andere kant... het is verrassend hoe ver sommige apen daarmee komen :)

Hiervoor is een XDF file benodigd, die de hardware van de motor , koppelt met de geheugenplaatsen op de BIN

Mispoes. Dat heeft niks met hardware te maken. Dat heeft met een bepaalde versie van firmware te maken. Als die de maps op een andere locatie verwacht (en daar staan ze ook), dan merkt de hardware daar helemaal niks van.
Theoretisch zou je nog wat met 'hardware kijkt zelf in de maps' kunnen. Maar dat impliceert dat de hardware iets met DMA zou moeten doen ofzo. Alles kan, maar gezien de controller en setup acht ik de kans daarop heel erg klein.

De EPROM2 kan met een voetje gebruikt zijn om meer mappen in 1 grotere EPROM te zetten

Dat kan met elke EPROM... Daar hoef je niet speciaal 'image 1' of 'image 2' voor te hebben. Puur een hardware dingetje. Als je mazzel hebt, dan zou het zelfs 'running' omgezet kunnen worden - heeft wel wat randvoorwaarden, maar deze simpele controllers doen geen pre-fetching enzo.
[offtopic]Ik heb die hardware ooit voor een 8051-derivaat zo ontworpen: in software 'bankswitching' doen op de ROM waar diezelfde software draait.[/offtopic]

Ik vroeg me ook af (als een EPROM gedeeltelijk fysisch kapot gegaan zou zijn) of adreslijnen naar beneden verschoven hadden kunnen zijn. (Het antwoord op het laatste, weet ik nu, is een categorisch Nee).

Zeg nooit nooit. Ik weet niet hoeveel '200 regels' is. Theoretisch zou een stuk address decoding stuk kunnen zijn waardoor er rare dingen gebeuren. De kans daarop (en dan een EPROM die verder normaal werkt overhouden) is zo klein dat 'nee' een veilige aanname lijkt.
Nogmaals: dat was de reden dat ik je vroeg om ff te kijken hoe eea. met die reset vector en memory mapping in elkaar zit. Dan WEET je het! Voorlopig houd ik het op 'custom' firmware. Whatever 'custom' dan ook moge betekenen...

Je kon bv in een pitstop binnen 10 seconden een map aanpassen (ECU wel van spanning blijven voorzien, ontsteking aan dus); de differentiële maps werden in het RAM geschreven.

Dat was voor firmware ontwikkeling redelijk standaard in die tijd: een EPROM emulator die op de een of andere manier aan een PC hing. Er zat een stuk RAM op (maar ja, dat weet die controller niet... die zet een address en verwacht data!; dat doet RAM prima!) wat je natuurlijk 'ter plekke' kunt aanpassen. Dat foefje kun je met elke ECU waar een EPROM in zit uithalen. Een BEETJE emulator heeft ook een backup batterij (of accu) zodat de RAM niet gelijk 'leeg' is als de spanning eraf gaat.

Overigens is er in de address map van de controller nog ruimte zat voor wat extra memory. Als iemand daar een stuk RAM in frot en de firmware kijkt op de adressen die voor de RAM gemapped zijn voor de tables... Kat in het bakkie. Dat is een 2de mogelijkheid om zoiets te doen (en wellicht in die tijd sneller, omdat er minder overdracht vanaf 'de pc' was, dat dus sneller ging en tijdens een race is snelheid in elk opzicht alles tenslotte).

Tijdens het optimaliseren van de motor op een testbank ("Rolling Poad), werd een EPROM emulator gebruikt ("Rommulator")

Die dus... Die is iets spannender dan de 'EPROM emulator' omdat je 'live' aan de bussen moet kunnen zitten. Ze hebben of foefjes gedaan met 2 RAMs die nagenoeg identiek waren qua inhoud: de controller 'ziet' de ene, de PC 'ziet' de andere en zodra de PC 'klaar' is, wordt eea. gewisseld en de andere RAM 'geupdate'. Dat gaat voor de gebruiker automagisch. Er schijnt ook nog zoiets als 'dual ported' RAM geweest te zijn. Dat heb ik nooit 'live' mogen aanschouwen.

In het bovenstaande verhaal is het zonneklaar dat de eigenaar met de ECU "geklooid" heeft (hij beweerde dat dit niet het geval was) en dat hij (nadat de ECU niet meer werkte), bij de motorhandelaar (onder garantie een nieuwe ECU probeerde te krijgen).

Ik ga niet zeggen dat het niet zo is, maar ik zie ook nergens overtuigend bewijs. Nogmaals: die controller start gewoon met wat er op (zijn) address 0xfffe als vector staat. Dat ligt hard vast in de controller. Als daar die EPROM gemapped is, dan kan die naar vanalles verwijzen... Naar het (EPROM) 0x0000 address of naar wat anders. Hoe het de makers van de firmware uit komt cq. wat ze leuk vinden cq. wat bij die toko gebruikelijk was.

Ik heb veel mbt Digitale Logica van jou (en andere forum members) opgestoken, maar het meeste moet nog bezinken en ik moet me er nog verder in verdiepen.

Succes daarmee. Het lijkt allemaal heel veel spannender dan het is. Dat heeft ook een beetje met de tijd te maken: tegenwoordig pak je een controller op SOC en je hoeft niet meer na te denken over bussen enzo. Vroegah moest je dat allemaal bedenken, en dus waren er meer mensen mee bezig (en was die kennis dus ook meer verspreid). Daar komt bij dat de eerste PC (en XT ook nog) niet heel veel anders in elkaar zaten dan het ding wat jij nu ECU noemt. Goed, de address bus was wat breder. Er zat wat rommel bij die DMA kon doen. Maar conceptueel is het volkomen identiek aan wat jij hebt!

Maar begin met aan te nemen dat die meeste hardware 'simpel' is. RAM, ROM, Flash... het maakt op zich voor die controller geen moer uit, zolang het maar op de bus past (al dan niet met wat 'glue logic'). I/O is ook zo'n dingetje. Mensen zien het als iets magisch, maar 'memory mapped' I/O is feitelijk niks anders dan... en (meestal) 8 bit 'ding' wat op het moment dat het juiste address op de bus voorbij komt met de juiste puls op de control lijnen gewoon de databus naar de output copieert. Meer is het niet.
Het juiste address selecteren? 64k, 16 address lijnen. 16 invertors die je al dan niet tussen schakelt en een 16-input AND (of 16 input OR als je de logica omdraait...). De output hang je aan een Chip Enable (CE of nCE meestal) ofzo. Meer is ook dat niet. Als je dit soort kunstjes snapt, wordt zo'n ECU opeens een heel ander ding...

@ Eric P

Bedankt! Weer een tipje van de sluier opgelicht;
Kun jij svp een handbook (of een site) aanbevelen, als "Primer" voor een goedwillende leek, zoals ik?.

Nog wat verdere terugkoppeling/opmerkingen, na "bezinking"van jouw opmerkingen (en die van ARCO en Paul W).

1)
De EPROM2 is dus niet (hardware matig) kapot.

2)
De CPU firmware staat dus inderdaad op de EPROM, zoals jij opperde.
(dit verklaart (achteraf) ook waarom blijkbaar meerdere typen P7 ECU's gebruikt kunnen worden op een Motor (Hardware), mits maar de EPROM van die Motor wordt meeverhuisd).

3)
Er is "door de vorige eigenaar aan de ECU geklooid" :
Zichtbaar aan lijmresten van een eerdere sticker en (niet standaard) coderingen op de sticker.
(Eigenaar claimde dat er niet gerommeld was; onjuist of misschien toch gedaan door een monteur).

4)
Er zou inderdaad "custom firmware" op EPROM2 in ECU2 kunnen staan.

NB
Het statement "200 regels verder" was onjuist;
Dit had moeten zijn 0x2000 (was al eerder door Arco en Paul W ook opgemerkt).

Kun je svp uitleggen, waar die startvector wordt gelezen?
A) Staat HxD correct ingesteld (8 kolommen) of had dit 16 kolommen moeten zijn? 128K EPROM (8K x 16), resp EPROM2 en EPROM1
B) Indien A) correct is waar staat dan 0xfffe ??

5)
Ik heb een andere (defekte) P7 IAW042 ECU (van een MG California) te leen.
Ik ga hiervan ook de EPROM uitlezen ("EPROM5").
Ben benieuwd of hier ook de data ook starten bij 0x0000, zoals EPROM1 en EPROM3.

6)
Ben het niet eens met je XDF statement.
Er zit zeer zeker een "link" naar de hardware van de betreffende motor.
Sommige motoren (V 2-cylinders) hebben 4 injectoren (bv. Ducati), terwijl Moto Guzzi (V 2-cylinders) maar 2 injectoren hebben.
Bovendien hebben de Ducati's verschillende Maps voor de liggende en de Staande Cylinder (niet strict nodig voor een Moto Guzzi).
Dus een Ducati XDF kan zeker NIET werken met een Moto Guzzi XDF werken (en omgekeerd) in TunerPro.

7 Hierbij, FYI een voorbeeld van een Aprilia ECU EPROM (foto 1,2) , waar dmv hardware (o.a. een PIC) "gerommeld" wordt met data en adreslijnen om een versleuteling of kopieerbeveiliging of whatever je het noemt, te bewerkstelligen voor de betreffende EPROM.
ECU en EPROM worden zo gepaard.
Dit geheel (voet plus EPROM) kun je zeker niet uitlezen in een "WILLEM" Programmer en dan herschrijven naar een andere EPROM.

Als je zo'n voetje weglaat en de EPROM gewoon monteert in de (gepaarde) ECU werkt de ECU niet meer..
Dit zou nog steeds IMO een scenario kunnen zijn voor ECU2 nl een per ongeluk weggelaten codeervoetje.

Ook dan is er trouwens met de ECU2 gerommeld.

Al dit bovenstaande is idd bedoeld om een slimmer aapje te worden.

Praktisch gezien voor mij:
Als EPROM1 in ECU2 werkt op mijn motor, is ECU2 nog goed en koop ik deze;
Als EPROM1 niet in ECU2 werkt, kan ik ECU2 kosteloos teruggeven en ga ik op zoek naar een andere reserve P7 ECU.

Ik laat je het resultaat tzt weten; het projectje staat even op een laag pitje, vanwege andere prioriteiten..

Bedankt voor al je ondersteuning & Vriendelijke Groeten.