mein Name ist Jens und bin was Mikroprozessoren angeht ein absoluter Neuling. Ich hoffe in diesem Forum Hilfe zu finden.
Thema:
Ich möchte einen SRAM auslesen, während er von einer anderen CPU in Nutzung ist. Verschiedene einzelne Adressen z.B. zw. 0x00 und 0xFF in einem kontinuierlichem Abstand auslesen. Diese dann mit einer Funktion in interpretierbare Werte umwandeln und auf einem Display wiedergeben.
was die Hardware und die Software angeht bin ich absolut blank. Ich weiß nur was ich will.
Gibt es für meinen gewünschten Einsatzzweck fertige Hardware zu kaufen und kann mir jemand hierzu etwas empfehlen? Am liebsten wäre mir hierzu dann eine fertige Schnittstelle via USB für den Laboraufbau oder später als durchprogrammierte Stand-Alone-Variante.
Wenn es hierfür geeignete Hardware gibt, welche Software bzw. welche Codezeilen sind unabdingbar hierfür? Kann mir hierfür jemand etwas empfehlen?
Speicherinterfaces sind nicht darauf ausgelegt, das ein zweites Gerät schreibend auf den Bus zugreift. Das wird im Fall einer Kollision (beide Geräte greifen überlappend auf den Bus zu) zu einem Fehlverhalten führen.
Was aber funktioniert ist, den Speicherbus zu überwachen. D.h. mitzuschnüffeln, was gerade gelesen oder geschrieben wird. Auch das ist aber Aufgrund der recht hohen Frequenzen nicht trivial.
Du kannst dann die Adressen, die Dich interessieren bei jedem Schreibzugriff hinterlegen, damit Du sie immer parat hast.
Eine fertige Lösung dafür ist mir nicht bekannt, und ich glaube nicht, das Du für so eine Aufgabe ohne FPGA auskommt.
Wäre insgesammt ein sehr ambitioniertes Projekt, auch für erfahrene Entwickler.
Gibt es für meinen gewünschten Einsatzzweck fertige Hardware zu kaufen
Informiere dich über "dual port ram". Ist aber sehr exotisch und sicher auch teuer. Natürlich muss der vorhandene RAM ausgetauscht werden und das vorhandene System tiefgreifend modifiziert.
Thema:
Ich möchte einen SRAM auslesen, während er von einer anderen CPU in
Nutzung ist. Verschiedene einzelne Adressen z.B. zw. 0x00 und 0xFF in
einem kontinuierlichem Abstand auslesen. Diese dann mit einer Funktion
in interpretierbare Werte umwandeln und auf einem Display wiedergeben.
Wahrscheinlich möchtest Du dann auch, dass die CPU davon nichts mitbekommt, nicht zwischendurch angehalten wird und nicht langsamer wird.
Das musst Du anstelle Deines Bausteins einbauen. Dieser Baustein hat nämlich eine Eigenschaft, die Du brauchst. Er hat nämlich zwei Sätze von Adress/Datenleitungen, d.h. er kann von zwei CPUs gleichzeitig und unabhängig gelesen und beschrieben werden. Damit kann Deine vorhandene CPU den Speicher über den ersten Port einfach so benutzen wie bisher, und Du kannst am zweiten Port mit einer weiteren CPU den Inhalt auslesen, ohne die vorhandene erste CPU zu stören.
Es gibt noch zwei weitere Möglichkeiten.
Die eine besteht darin, die originale CPU kurz anzuhalten und dann mit einer anderen CPU auf den Speicher zuzugreifen. Das wird beispielsweise bei Grafikkarten gemacht, wo sowohl der Prozessor als auch die GPU auf den Speicher zugreifen muss. Das stört natürlich die originale CPU, und ob das überhaupt ein gangbarer Weg ist, hängt stark vom System ab. Da gibts keine allgemeinen Aussagen, und ganz einfach ist das möglicherweise auch nicht.
Die andere Möglichkeit besteht darin, einen Logicanalyzer zu nehmen. Der kann digitale Signale lesen und den zeitlichen Ablauf abspeichern. Damit kannst Du dann einfach an den Leitungen mithören und aufzeichnen, welcher Wert wo hinein geschrieben wird. Du brauchst dafür allerdings ein Gerät, was mindestens 24 digitale Eingänge hat. Davon gibts nicht besonders viele, und ganz billig sind die auch nicht.
wie funktioniert dies dann bei z.B. Fehlerspeichern oder Sensordaten von Motorsteuergeräten wenn ein gleichzeitiger Betrieb nach deinen Worte nicht möglich ist? Wie wird dies hier gelöst?
In meinem Fall wird ein sram kontinuierlich von einer CPU mit Werten versorgt und schreibt diesen Wert in den sram an z.B. 0x36 (z.B. Batteriespannung). Über eine externe Schnittstelle wird diese Adresse dann kontinuierlich ausgelesen und über eine Tester ausgegeben.
Die Logic-Analyser-Version könntest du mit einem 8-Bit LA (für <20€) mal probieren, nur um ein Gefühl für Aufwand/Handling/Zugang zum SRAM /... zu bekommen.
Ich möchte einen SRAM auslesen, während er von einer
anderen CPU in Nutzung ist.
"Beschreibe Dein eigentliches Problem, und nicht
Deine vermeintliche Lösung."
Soll heißen: Gehst Du davon aus, dass der RAM korrekt
funktioniert, aber Du möchtest wissen, welche Werte
die CPU wann liest und schreibt -- oder möchtest
Du prüfen, dass der RAM korrekt arbeitet -- oder
vielleicht noch etwas ganz anderes?
das mit dem pausieren und abwechselnd schreiben und lesen beantwortet dann denke ich meine zweite Frage, die an Nils gerichtet war. Besten Dank.
Die Variante mit einem Dualport-Ram ist aus meiner Sicht die schönere Lösung.
Kommt die CPU mit deinem verlinktem Dualport-Ram klar oder kann diese den Dienst quitieren? Oder kann ich diesen 1zu1 austauschen (richtig verkabelt natürlich vorausgesetzt)?
Nochmal um klarzustellen, ich will nur lesen. Nicht schreiben :-)
ich weiß das der ram einwandfrei funktioniert.
Ich weiß das an mehren Hexadressen konkrete interpretierbare Werte liegen.
Diese möchte ich auslesen mit einer Funktion versehen und über ein Display wiedergeben.
HM6264 mag sein das dieser so heißt. Da auf meinem Baustein nur B58115 steht und ich mich nicht auskenne habe diesen so genannt.
@ Harry einen ROM Emulator nutze ich bereits. Jetzt möchte ich dies analog für den SRAM realisieren. Wenn es sowas fertiges gibt wäre das natürlich auch eine schöne Lösung. Wie immer ist das Problem das man manchmal nicht weiß nach was man konkret suchen muss oder verwenden muss.
deswegen wende ich mich an die Spezies in diesem Forum :-)
War's nicht so, daß man genau das ehemals beim Atari ST gemacht hat?
Speicherinterfaces sind nicht darauf ausgelegt, das ein zweites Gerät
schreibend auf den Bus zugreift. Das wird im Fall einer Kollision (beide
Geräte greifen überlappend auf den Bus zu) zu einem Fehlverhalten
führen.
Man hat's damals abwechselnd gemacht, wenn ich recht erinnere.
Die Variante mit einem Dualport-Ram ist aus meiner Sicht die schönere
Lösung.
Tja, aber wohl nur aus deiner Sicht. Das was du da machen willst, ist ja nix neumodisches, das ging schon vor >40 Jahren mit fast jedem Homecomputer, an den man einen TV oder Monitor anschliessen konnte. Aber so gut wie keiner hat Dualport-RAMs dafuer eingesetzt.
Kann mich da auch nur der Empfehlung anschliessen:
Beschreibe dein eigentliches Problem...
ich weiß das der ram einwandfrei funktioniert.
Ich weiß das an mehren Hexadressen konkrete
interpretierbare Werte liegen.
Okay. Verstanden.
Diese möchte ich auslesen
Warum?
Warum möchtest Du die Werte erst dann auslesen, wenn
sie schon im Speicher stehen?
Warum genügt es nicht, sie dann zu protokollieren,
wenn sie gerade in den Speicher geschrieben werden?
Ich will Dich nur auf eine mögliche Scheuklappen
aufmerksam machen: In einem korrekt funktionierenden
System ändern sich die Werte im Speicher NUR dann,
wenn zuvor ein entsprechendes Kommando auf dem Systembus
aufgetaucht ist.
Es ist technisch wesentlich einfacher, den Systembus
mitzulauschen, als aus einem aktiv benutzten Speicher
Daten auszulesen, ohne das System zu stören.
HM6264 mag sein das dieser so heißt. Da auf meinem
Baustein nur B58115 steht und ich mich nicht auskenne
habe diesen so genannt.
Tja, aber wohl nur aus deiner Sicht. Das was du da machen willst, ist ja
nix neumodisches, das ging schon vor >40 Jahren mit fast jedem
Homecomputer, an den man einen TV oder Monitor anschliessen konnte. Aber
so gut wie keiner hat Dualport-RAMs dafuer eingesetzt.
Da haben die Videochips auch nur stumpf die CPU angehalten, wenn die selber was auf dem Bus wollten.
Auweia. Naja, was solls: Also wenn ich auf einer einsamen Insel gestrandet waere, und meine einzige Moeglichkeit da wieder wegzukommen waere sowas, dann wuerde ich ein kleines FPGA hernehmen, und mit dessen BlockRAM (Was ueblicherweise eh Dualport) ist, "nach aussen" in die eine Richtung so tun, als waere ich ein B58115, in die andere Richtung halt meinen eigenen Shice anflanschen.
Wird nur beim Start des Ganzen etwas holprig, denn das FPGA muss nach poweron erstmal sich konfigurieren / konfiguriert werden, bis es das tut, was man gerne haette. Solange sollte das Steuergeraet im Reset bleiben.
Aber das Vorhaben ist - solange man nicht auf der einsamen Insel gestrandet ist - wirklich ein ziemlicher Hirnfurz.
wie funktioniert dies dann bei z.B. Fehlerspeichern oder Sensordaten von
Motorsteuergeräten wenn ein gleichzeitiger Betrieb nach deinen Worte
nicht möglich ist? Wie wird dies hier gelöst?
Der Tester greift nicht direkt auf den Speicher zu, sondern schickt über CAN/K-Line/ISOwasweisich eine Anfrage an das/die Steuergeräte. Die CPU liest dann den Wert aus und schickt ihn dann zum Tester.
So wie s aus schaut, hast du folgende Möglichkeiten:
Mit einem Dual Port RAM. Sollte funktionieren, wenn der Baustein vom Timing etc. passt. Aber du hast dann immer noch die Hürde, auf der anderen Seite einen Mikroprozessor dran zu schließen.
Bus belauschen. Könnte je nach Bus-Geschwindigkeit sogar mit einem AVR gehen, ansonsten FPGA
Ram emulieren. Deutlich komplexer.
Das Steuergerät einfach fragen. Dürfte wohl der einfachste Punkt sein, WENN das Protokoll bekannt ist.
ein anderes Steuergerät verwenden
Oder auf Vergaser und Unterbrecherzündung umrüsten ;-)
Kommt die CPU mit deinem verlinktem Dualport-Ram klar
Vielleicht habe ich etwas überlesen, oder du hast vergessen anzugeben, um welche CPU es sich handelt. Um die Frage zu beantworten brauchen wir vermutlich auch den Schaltplan des Gerätes. Man kann ja nicht einfach so Kartoffelkisten durch Säcke voll Reis ersetzen. Das muss ja auch irgendwie zusammen passen.
Weißt du denn überhaupt wo genau welche Daten in welchem Format abgelegt werden?
im Speicher sind die End-Werte, die das MGS tatsächlich umsetzt. Im Laboraufbau kann ich im ROM rumspielen um Rückschlüsse auf den Einfluss von verschiedenen Codesegmenten und Kennfeldern auf diese Werte zu ziehen. Zusätzlich könnte ich diese loggen und wie beschrieben mir im Cockpit alternativ direkt anzeigen lassen.
"Warum genügt es nicht, sie dann zu protokollieren,
wenn sie gerade in den Speicher geschrieben werden?" Wenn ich wüsste wie ich dies umsetzen kann oder hier vorgehen muss wäre das auch eine Alternative.
Im sram weiß ich wo diese konkret stehen. Wie diese dahin kommen oder mit welchen Funktionen errechnet werden nicht.
"Warum genügt es nicht, sie dann zu protokollieren,
wenn sie gerade in den Speicher geschrieben werden?" Wenn ich wüsste wie
ich dies umsetzen kann oder hier vorgehen muss wäre das auch eine
Alternative.
Wie schon gesagt wurde: Das ist deutlich einfacher, als nebenher noch selbst auf den RAM zuzugreifen, weil es nicht aktiv in die Kommunikation eingreift.
Im sram weiß ich wo diese konkret stehen. Wie diese dahin kommen oder
mit welchen Funktionen errechnet werden nicht.
Brauchst du ja auch nicht. Es geht nur darum, den Schreibzugriff der CPU mitzulesen. Wenn da als Ziel die Adresse auftaucht, die dich interessiert, merkst du dir die dazugehörigen Daten und hast deinen Wert.
Ich habe die Möglichkeit über einen Tester auf diese Werte zuzugreifen. Allerdings steigt die Diagnose über 2600 1/min aus und ist insgesamt sehr langsam. Es handelt sich noch um eine ADS Schnittstelle ohne OBDII Funktion.
Soweit ich es im Kopf habe wurde es seitens Hersteller als D-Bus betitelt. Eine saubere Doku zu den Protokollen habe ich aber noch nicht finden können.
Einen frei erhältlichen Schaltplan zum Steuergerät sowie eine vollständige Funktionsbeschreibung gibt es nicht.
Brauchst du ja auch nicht. Es geht nur darum, den Schreibzugriff der CPU
mitzulesen. Wenn da als Ziel die Adresse auftaucht, die dich
interessiert, merkst du dir die dazugehörigen Daten und hast deinen
Wert.
und wie setze ich sowas um? Wie lese ich den Schreibzugriff der CPU? Mit welcher Hardware und Software kann ich sowas umsetzen?
Mit deutlich weniger Aufwand liese sich was bauen,
das den aktuellen (= den letzten) SCHREIB-Zugriffswert auf EIN BYTE (=eine Adresse) deines Speichers erfasst und als hexadezimaler Wert anzeigt.
Mit Hex-Codierschalter ausgestattet wäre dies auch "schnell" umschaltbar.
Diese für mehrere Bytewerte gleichzeitig zu machen wäre aufwendiger.
Gruss
Schau dir mal auf Seite 10 das Timing-Diagramm zum schreiben an.
Dann kannst versuchen, zu allen Daten + Adress Leitungen einen AVR zu hängen.
Da das Ram mit 1MHz angegebenen ist, könnte(!) ein 24MHz AVR reichen
Angenommen A0..A7 hängen an PORTA, A8..12 an PORTB und I/O an PortC, dann könnte das so funktionieren
1
2
while(PINA!=0x47&&PINB!=0x11){}
3
PORTD=PINC
Das Programm wartet, bis die Adresse 0x4711 anliegt und liest dann den Wert ein und gibt ihn an PORTD wieder aus
Das ist natürlich noch nicht fertig (man muss noch CS /WR etc auswerten, die kannst noch an PORTB anschließen) aber ich hoffe vom Prinzip her sollte es klar sein.
Man muss sich da aber die Takte auszählen, die der AVR braucht, ob er mit dem Timing mit kommt. Rect viel andere Sachen wirdver aber nicht machen können.
Es geht aber wahrscheinlich auch mit einem Gattergrab oder einem EPROM und einem Latch.
das wäre zumindest schonmal ein Anfang mit dem ich weiterarbeiten könnte.
Manche Werte sind leider 2 Byte lang z.B. die Drehzahl. Es gibt aber auch genug Werte die mich interessieren, die nur ein Byte groß sind.
D.h. ich könnte aber mit einem konkreten sram Hexwert arbeiten und mir dann den nächsten einzeln separat anschauen.
Stehe ich wieder vor der Frage wie ich dies Hardware- und Softwaretechnisch umsetze :-)
Zunächst einmal besten Dank an alle konstruktiven Beiträge.
So einfach wie ich es mir vorgestellt habe, ist es nach den bisherigen Beiträgen schonmal nicht. Meine größte Hoffnung hatte ich in einen RAM-Emulator gesetzt analog den eines ROM-Emualtors (ich verwenden Moates Ostrich). Ich habe schon mit analoger Messtechnik experimentiert. Hatte aber gehofft auf digitalem Wege ebenfalls weiterzukommen.
doch die Aufgabe die stellst - ist nur im Speicher mitlauschen,
Ganz so einfach wirds wohl nicht. Es gibt einige zeitkritische und Lastfaktor-Fragen, die der TO ohne ausreichende HW-Kenntnisse wohl nicht in diesem Jahr beherrschen wird. Anfangen kann er schon. (Das verrät jetzt einer, der im letzten Jahrtausend CPU-Platinen repariert hat) :-)
Was aber funktioniert ist, den Speicherbus zu überwachen. D.h.
mitzuschnüffeln, was gerade gelesen oder geschrieben wird. Auch das ist
aber Aufgrund der recht hohen Frequenzen nicht trivial.
Ist doch nur ein 1MHz Bus eines MCS-51, und man kann ja hinter dem Adresslatch abgreifen. Die allermeisten Signale sind sogar am EPROM vorhanden, das macht es auch mechanisch unkompliziert.
Du kannst dann die Adressen, die Dich interessieren bei jedem
Schreibzugriff hinterlegen, damit Du sie immer parat hast.
Eine fertige Lösung dafür ist mir nicht bekannt, und ich glaube nicht,
das Du für so eine Aufgabe ohne FPGA auskommt.
Naja, ein FPGA ist da ziemlich übertrieben. Wenn es wirklich nur um einzelene Speicherstellen geht, dann reicht doch ein Komparator und ein 8-Bit Latch, pro Speicherstelle natürlich.
Wäre insgesammt ein sehr ambitioniertes Projekt, auch für erfahrene
Entwickler.
Dumme Frage an den TO: Woher weisst du, welche Daten an welcher Stelle stehen? Die Adressen sind nicht fix für die Motronic sondern ändern sich mit der Software Version.
Und noch ein Hinweis: Es gibt für die Steuergeräte spezielle Deckel, die die von dir gewünschte Funktion enthalten.
beim Tester gibt es digitale steuergerätespezifische Tabellen die diese Infos enthalten. Ein Abgleich beim Auslesen des Rams über den Tester bestätigt einzelne Tabellenwerte. Wie gesagt steigt diese aber über 2600 1/min aus.
Dem entgegen hatte ich es auf analogem messtechnischem Weg versucht dem MGS zu entlocken ob meine veränderten Werte des ROMS auch umgesetzt werden. Hierfür habe ich den Kabelbaum angezapft und geloggt. Prinzipiell funktioniert dies auch.. ich hatte nur gehofft es digital lösen zu können.
Beispiele analoger Messsignale für die Drehzahl KW,NW,Digital,Einspitzung und der Abgriff über eine ZZP-Pistole anbei.
32kb MCS51 dissambler ist zwar nicht gerade das worauf man ernsthaft
Bock haben sollte, aber immerhin machbar wenn einem das Problem
wichtig genug ist.
Da es ja offensichtlich über das Reverse-Engineering von Autoelektrik geht, sollte man das ganze nach https://www.mikrocontroller.net/forum/fahrzeugelektronik verschieben und einen passenden Namen, bspw. "Chiptuning -Tool: ROM-Emulator für SRAM" o.ä. ins topic setzen.
@ Myclass:
Eigentlich wollte ich auf dich und deine durchgehende unverschämte Art nicht weiter eingehen. Es gibts hier Nutzungsbedigungen im Umgang miteinandern die du mehr als einmal nicht einhälst. Allerdings scheinst du persönliche soziale Probleme zu haben oder aber die Intention haben mir und andere davon abzuhalten bei meiner Problematik zu helfen. Vermeintlich weißt du genau was man machen müsste oder wie ich besser ans Ziel komme, möchtest aber keine Infos teilen bzw. am liebsten diesen Post löschen. Keine Ahnungs was dein Problem genau ist. Das tut mir sehr leid für dich. Wenn´s dich stört beschäfftige dich doch anderweitig :-)
Ich bin hier zum ersten mal eingeloggt mit USER meinem echten Namen und mache auf kein Geheimnis daraus was ich vorhabe und möchte. Ich habe eine technische Frage. Nämlich wie man einen SRAM auslesen kann der in Benutzung ist... ich habe KEINEN PLAN wie man das macht deswegen frag ich danach.
Nämlich wie man einen SRAM auslesen kann der in
Benutzung ist... ich habe KEINEN PLAN wie man das macht deswegen frag
ich danach.
Mal zurück zur Technik: ich würde Datenbus, Adressbus, WR# und CE# abgreifen, puffern und parallel zum SRAM ein Dual Ported RAM anschließen, welches ich mit einem zweiten Microcontroller bei Bedarf auslesen kann.
Das einzige was geht, wäre eine Aufzeichnung des Verkehrs am RAMBusses
und daraus Rekonstruktion des Speicherinhaltes.
Oder eben die Spiegelung in ein geeignetes RAM, wie ich es oben
beschrieben habe. Also geht es doch.
Nein den kann man nicht während des Betriebes auslesen. Und die typischen DualPort SRAM Probleme wie bei simaltonous Read and write werden auch nicht adequat behandelt. Abgesehen davon das keine diskreten DualPort Rams aka "geeignetes RAM" hersgestellt werden.
ich würde Datenbus, Adressbus, WR# und CE#
abgreifen
Ich auch, da es aber wohl ein Testaufbau ist, würde ich das der Einfachheit halber (wie bereits mehrfach vorgeschlagen) mit einem Logic Analyzer machen.
wie funktioniert dies dann bei z.B. Fehlerspeichern oder Sensordaten von
Motorsteuergeräten wenn ein gleichzeitiger Betrieb nach deinen Worte
nicht möglich ist? Wie wird dies hier gelöst?
Fehlerspeichereinträge und Sensordaten werden nicht von einer zweiten CPU aus dem RAM der ersten gelesen, sondern von der CPU, wo sie entstehen als Botschaft auf einem Bus und/oder per Diagnose zur Verfügung gestellt.
Während der Steuergeräteentwicklung gibt es darüberhinaus noch andere Möglichkeiten - z.B. kann man per XCP (früher CCP) u.a. auf beliebige Speicheradressen zugreifen. Diese Funktionalität ist aber in einem Seriensteuergerät (verständlicherweise) deaktiviert.
Wenn die CPU ROMlos betrieben wird, könnte man auch einen eigenen Debugger im EPROM passend unterbringen. Vermutlich wird die serielle Schnittstelle noch gar nicht benutzt. Ist natürlich nicht ganz einfach.
Multibyte-Variablen haben halt ohne Kenntnis der Datenstrukturen manchmal unsinnige Werte, da die Bytes nicht gleichzeitig geschrieben werden können.
Scheint auch eher die NMOS-Variante zu sein. Hab das DB nicht im Kopf.
ein schönes altes bosch steuergerät.
das hat eine k/L-schnittstelle.
https://de.wikipedia.org/wiki/K-Leitung
und ein gesondertes testprotokoll mit dem im betrieb die betriebesdaten ausgelesen/gesetzt werden können. ist aber leider betriebsgeheimniss. die daten liegen in redudanter form in den tabellen vor. bei einigen als triplet damit bitfehler korigiert werden können. in solch einer tabelle änederungen vor zu nehmen ist recht aussichtslos. zudem sollte bei dem sg auch schon ein tunerschutz integriert sein. jedes bosch Steuergerät hat eine 10 stellige nummer diese beschreibt die hardware, die beiden nummern auf dem eeprom sind hardware = 0261203590 und software = 1267358597. also für einen BMW E36 .schau mal ob du auf dem sg noch ein eingekreiste dreistellige zahl findest. das wäre die werkskennzahl.
den 80c515 könntest du mit einem datalogger/logicanalayser beobachten. wird dir aber nicht wirklich helfen. die motor-tabellen sind auf mehrere bereiche im RAM und EEPROM aufgeteilt. bei inkonsisten daten geht das sg dann schon mal gern in den notlauf. dabei werden alle dynamischen daten (also ram) durch defaults aus dem eeprom ersaetzt.
es gibt eine kleine englische firma die steuergeräte für tunig und rennmotoren herstellt. darunter sind auch "leere" sg die du selber konfigurieren kannst. die haben eigentlich für alle gängigen motoren software vorliegen. such mal nach DTA steuergeräte.
Ich weiß jetzt nicht, welche Große der TO braucht,
Naja er hat ein Datenblatt eines 8k RAM's verlinkt, das sollte doch ein Hinweise sein.
aber was ist an
einem
IDT 7132 auszusetzen?
Das er nur 2k hat.
Und natürlich das Grundproblem, das man über Port B den Inhalt einer Addresse liest, die gleichzeitig oder kurz darauf per Port A überschrieben wird. Da musste man schon das gesamte System anhelten während des auslesens, um ein konsistentes Abbild zu erhalten.
Dann schon lieber einen kleinen FPGA nehmen (Lattice) , den internen RAM als shadow ram nutzen und eine funktionierende Cohernce steuerung implementieren.
--
dann schon liebe Bus protokollieren ... und hoffen das der Prozessor keinenen Cache ohne Write-through hat, denn hilft der Bus-analyzer auch nichts. Oder es ist ein prozessor mit vielen internen Register, da sieht man auch keine Tabellen übern Bus gehen.
Aber ueberlegt mal die Gelegenheit, ihr koenntet ein DualCore System bauen wo ein 6502 und ein Z80 auf ewig gemeinsam vereint vor sich hin tueddeln. Der eine fuellt den Speicher ueberlegen mit DJNZ und der andere genauso ueberlegen ueber die Zeropage. :-D
es gibt eine kleine englische firma die steuergeräte für tunig und
rennmotoren herstellt.
Aber vielleicht will er ja selber "eine kleine deutsche Firma" werden.
Allerdings setzt man sich dann hin und schmeisst den Disassembler an
und macht nicht Mimimi im Internet....
Bild anbei mit ein paar Infos die ich auslesen konnte.
Ich nehme an, du meinst den Produktionscode "078".
Das SG verfügt über eine EWS. Für den Standalone-Betrieb bzw. Testaufbau musste ich die Codierung ändern um es mit einem Drehzahlsignal und diverser anderer Inputgrößen zum laufen zu bringen.
Der Tunerschutz der mir bekannt ist, wird über die Checksumme geregelt. Solange die Checksumme auf dem Eprom zu den geänderten Werten des Eprom passt funktioniert das ohne Probleme.
Danke für den Tipp mit DTA. Da mach ich mich mal schlau. Ein "freies" Steuergerät wäre natürlich möglich. Ist zum aktuellen Stand aber nicht mein Anspruch.
Wenn ich "nur" unter Volllast Zündung und Einspritzung anpassen möchte, muss ich nicht sofort ein komplettes "freies" Steuergerät herholen. Da ich das Steuergerät aber noch mehr verstehen möchte brauch ich halt ein paar Hilfswerte. In dem Fall die Endwerte von Zündung und Einspritzung nachdem diverse Kennfelder durchlaufen worden sind und ein "Endergebnis" liefern...
und dies war zumindest meine Idee es aus dem RAM (oder wie auch immer Digital) zu holen. Mit analoger Messtechnik gehts natürlich auch.
mal nen Einwurf...
Und wenn man am Anfang versucht den Anfang des EPROM zu disassemblieren,
ich meinen die Tabellen werden ja bei der Initialisierung in den
RAM übertragen, dann weiß man wenigstens deren Adressen im Ram.
So müßte man sich hardwaremäßig nur auf kleine RAM - Bereiche
konzentrieren was vielleicht einfacher ist.
( wenn Tabelle Adreßmäßig angesprochen wird, bring die Tabelle
in Sicherheit )
das ist mein Hobby. Gründen will ich garnix. Ich hab den Karren selber und möchte halt soweit ich es kann alles selber machen.
Und mit dem Disassembler meinst du sicher sowas wie in meinem Bild.. Mimimi?
Ich versteh immer noch nicht ganz die Einstellung mancher hier :-(
Bzgl. Disassembler habe ich schon diverse Sachen gefunden die ganz nützlich sind. Ich steig aber trotzdem noch nicht ganz durch. Zumal ich nicht 100 % sicher bin ob ich den richtigen Disassembler genutzt habe oder die Stützstelle bzw. Einstiegstelle die korrekte ist. Außerdem habe ich auch nicht verstanden wann der Disassembler kapiert was Codebereich und Tabellenbereich ist.. naja anderes Thema.
Von der Lieferbarkei, nicht von der Funktion. Dann schon lieber gleich lieferbare FPGA, den man sich zum Dual-Port RAM mit Konsistenzcheck umfrimmeln kann. Beispielsweise Lattice iCE40UP5K: sofort ab Mouser-Lager, 10€ hätte dann 15kByte. Und Oscillator on board, ...
Und mit dem Disassembler meinst du sicher sowas wie in meinem Bild..
Mimimi?
Ich versteh immer noch nicht ganz die Einstellung mancher hier :-(
Warum nicht?
Als erstes muß man sich mit dem Prozzi beschäftigen.
Datenblatt einsehen, feststellen von welcher Addy der Proz startet.
Wo ist die Interrupttabelle?
Dann den Disassembler (zb IDA) auf die Startaddy ansetzen.
Meist ist dort ein Sprung, der die Interrupttabelle, die aus
lauter Sprüngen besteht, überspringt.
Darauf folgt die Initialisierung, einstellung des Stackpointers,
der Ports, der Zeitgeber, u.s.w. und der RAM Tabellen.
Dann werden die Interrupts enabelt und die Hauptschleife ausgeführt.
Ich versteh immer noch nicht ganz die Einstellung mancher hier :-(
Die ist ganz einfach, keiner will Dich oder Dein Projekt "an der Backe kleben haben", insbesonders wenn sich die vorgeschlagene Wunschlösung als unmöglich darstellt.
ich habe eine Vermutung das er vom EPROM bei 0x2000 einsteigt. Zumindest finde ich diese Adresshinweise im CPU internal RAM ganz am Anfang.
Ich habe mal in IDA was getestet. Da sind auch ein paar Schaltblöcke rausgekommen, konnte es aber nicht mehr reproduzieren. Da bin ich leider nicht so fit wie ich es gerne möchte. Ich weiß nicht was eine Interrupt-Tabelle ist.
Auch habe ich bei den Version von IDA die Frei sind keinen passenden Diassembler zum Chip gefunden.
Dann wirst Du das Projekt alleine nicht schaffen.
Du müßtest die dich interessierenden Variablen auslesen,
über USB mit nem Zeitstempel an nen Pc schicken und dort
auswerten. Das kann nur ein Programm.
Das wird ohne Programmierkenntnisse nicht klappen. :-((
Sag mal bitte, was auf der 1. Speicherzelle des EPROM steht.
0X00 oder was Anderes?
Was willst Du denn wirklich vom Steuergerät wissen / verändern?
Bis jetzt hältst Du dich ja ganz schön bedeckt...
War's nicht so, daß man genau das ehemals beim Atari ST gemacht hat?
Da hat man das so gemacht.
Das ging aber nur, weil das Busprotokoll des m68k eine zeitliche Lücke liess, in die (ausreichend schnelles RAM vorausgesetzt) das Videosystem "eingrätschen" und dieses auslesen konnte, ohne dass die CPU etwas davon merkte.
Ob so was bei modernen Prozessoren nocht geht? Unwahrscheinlich.
Dann den Disassembler (zb IDA) auf die Startaddy ansetzen.
Es soll ganz gemeine Steuergeräte Entwickler geben. Die nutzen das Maskenrom im Prozessor, um die Peripherie auf Änderungen zu prüfen. Auch liegen alle sicherheitsrelevanten Funktionen im Maskenrom. Und dieses Maskenrom ist heftig gegen Auslesen oder andere Manipulationsversuche geschützt.
Der TO ist nicht der Erste (und auch bestimmt nicht der Letzte), der den Tuningschutz umgehen will. In Osteuropa gibt es Firmen, die das im Lohndrusch machen - gegen größere Mengen Bargeld. Das sind aber richtige Experten. Selbst für einen Top Hobbyelektroniker ist es eine Quelle für Frust ohne Ende. Ein gangbarerer Weg ist die Manipulation von Sensor Signalen. Aber auch da ist Vorsicht geboten. Das Steuergerät akzeptiert nicht alles ohne Murren.
War's nicht so, daß man genau das ehemals beim Atari ST gemacht hat?
Da hat man das so gemacht.
Das ging aber nur, weil das Busprotokoll des m68k eine zeitliche Lücke
liess, in die (ausreichend schnelles RAM vorausgesetzt) das Videosystem
"eingrätschen" und dieses auslesen konnte, ohne dass die CPU etwas davon
merkte.
Manchmal wurde auch der CPU der Bus regelrecht 'geklaut' damit der DMA (direct memory access) ackern konnte. Siehe commodore Amiga, der aber gleich einen ganzen Chipsatz (Agnus, Garry) für das bisserl DMA brauchte. Und nur die Denise bespielte das video (aus dem chipram).
mein Epromfile anbei (Serie). 1. Speicherzelle ist 0x85.
Anpassen kann ich bisher Volllast Einspritzung und Zündung sowie den Drehzahllimiter. Teillast analog auch, habe ich bisher aber noch nicht für nötig gehalten.
Für die Zukunft noch weitere Themen wie Leerlaufdrehzahl anpassen. DISA Schaltschwellen (Drehzahlen anpassen oder ggf. auscodieren). Schubschaltung deaktivieren. Welche Tabellen mit welchen zusammenarbeiten, die Konstanten entschlüssen zw. 0x4000 und 0x4400 etc.
Größeres Thema noch wie die Klopfsensoren bzw. deren Schaltschwellen funktionieren und ggf. anpassen.
Der Wissensdurst ist auf jeden Fall nicht begrenzt..
Geil, Jens!
Bist Du ein Rennfahrer, Ralley oder ähnlich?
Georg G. ist nicht schlecht!
Die 8050iger Serie hat ein Pin, mit dem man wählen kann,
ob der Prozzi vom internen Prom oder vom externen PROM
ließt / bootet.
Schau bitte ins Datenblatt, welcher Pin das bei Dir ist
und schau bitte ins gerät, was da bei Dir dran hängt!
Der TO ist nicht der Erste (und auch bestimmt nicht der Letzte), der den
Tuningschutz umgehen will.
Aber wahrscheinlich der Unfähigste. Reengineering durch einen Angeber, für den ein Disassembler nur Mimimi ist und der nicht einmal weiss was eine Interupttabelle ist? Da braucht man darüber was davon legal ist garnicht erst nachdenken. Leider sind nicht alle Ganoven so unbedarft.
ich weiß immer noch nicht genau was du mit Tuningschutz meinst?
Das alte Steuergerät ist da relativ stumpf.
Passen EWS Code und Checksumme zum Auto funktionieren meine Änderungen.
Unter Volllast gabs damals auch keine Lambdaregelung... da wurde stumpf nach Kennfeld gefahren. Serienmässig läuft der Bock übrigends in diversen Drehzahlbereichen viel zu mager.
Beispielbild vorher nachher Lambda unter Volllast.
@Lotta:
Der interne CPU Ram teilt sich Bereiche von 0x0000 bis 0x1FFF. Den Eprom hängt er dann als Erweiterung bei 0x2000 (ab 0x2000) ran. Der erste Bereich vom Eprom 0x0000 bis 0x1FFF wird aber ans Ende geschoben 0x8000 bis 0x9FFF. Zumindest wenn ich den "ROM" auslese. Ist nur die Zündung an und in Diagnose wird der Bereich anders bespielt als wenn ich Drehzahl dazu gebe und das MGS in Betrieb geht. Ich vermutete das meintest du mit den PINs oder?
Nö. ich mein den 805... Prozessor.
Der hat nen maskenprogrammierten ROM drauf, es gibt aber welche
ohne ROM.
Den maskenprogrammierten ROM programmiert der Hersteller
bei Massengeräten wie Waschmaschinen u.s.w.
Um den Prozzi aber auch ohne den Maskenrom für kleinere Stückzahlen
mit externem ROM nutzen zu können, hat der Prozzi nen Pin, wo ich den Internen ROM ausschalten kann und den externen anschalten.
Nun hat mich Georg auf ne idee gebracht:
Warum soll der Prozzi nicht vom Masken ROM booten, und dann mittels
Portbefehl auf den extenen schalten, so das quasi nur die Hälfte des Programmes im externen Rom sind, die besonders geilen Funktion
aber im inneren, da wo nen Normaler nicht ran kommt?
ich mach nen Vorschlag:
Mach unter "Projekte und Code" nen Thread auf.
Ich werd am Wochenende mal ins Datenbuch schauen
ob dieser Prozzy so nen PIN hat,
und dann meine Freundin, Ida von Pleuselsplink auf das
EPROM loslassen, dann reden wir weiter, OK?
Einführung in das Mikrocontroller-System 80(C)515/80(C)535
Seite 11 von 228
enable) dient zum Demultiplexen des Adreß- und Datenbusses. Der externe Programmspeicher
wird durch das Signal PSEN (programm store enable) zweimal pro Maschinenzyklus
angesprochen. Der Anschluß EA (external access) informiert den Microcontroller darüber, ob er
außerhalb des internen ROM’s arbeiten soll oder innerhalb. Die Anschlüsse RD (read) oder WR
(write) dienen zum Ansprechen des externen Datenspeichers
ob der auch DMA fähig ist weiss ich nicht. könnte aber sein.
Der EA Anschluss dient dazu das interne ROM auszuschalten. Sprich man macht damit aus einem C515 einen C535(RomLess). Adressen > ROM liegen weiterhin am Adressbus an (alles ab 0x2000). Die Geschwindigkeit ist intern und extern gleich. Es ist in meinen Augen auch nicht klar wie das Eprom und SRAM in den Adressraum gemappt ist.
Wenn man das Binary anschaut, ist dort sowohl Code als auch Tabellen zu finden. Ein Disassembler hilft erst wenn man den Adressraum kennt.
Es ist in meinen Augen auch nicht klar wie das
Eprom und SRAM in den Adressraum gemappt ist.
Die haben ja bei MCS-51 getrennte Adressräume, also das EPROM (32KiB) von 0000h/2000h...7fffh und 8000h...ffffh, und das RAM (8KiB) von 0000h...1fffh, 2000h...3fffh, usw.
Außerdem habe
ich auch nicht verstanden wann der Disassembler kapiert was Codebereich
und Tabellenbereich ist.. naja anderes Thema.
Das kapiert er auch nicht, (außer er ist so intelligent, dass er checkt, dass da nie ein JMP erfolgt)
Man muss beim Disassembler doch noch einiges von Hand machen (Codebereich und Datenbereiche erkennen und vor allem relativ genau wissen, wie der Prozessor funktioniert: Einsprungadresse, Interrupt-Tabellen, internes PROM,...)
Nein den kann man nicht während des Betriebes auslesen.
Weil das Steuerinterface des RAMs bekannt und unkompliziert ist, würde ich einfach die interessanten Adressen oder auch den gesamten 8k Speicherbereich mit einem FPGA mitloggen, davon in Registern oder im (DP)RAM eine Kopie anlegen und bereitstellen. Diese Speicherzellen können dann per SIO abgefragt und rausgeschrieben werden.
Das geht bei hinreichender Erfahrung mit weniger als 100 Zeilen VHDL-Code.
Wenn die Werte laufend neu (oder nur einmalig) geschrieben werden, könnte ich mir sogar vorstellen, ein gleiches SRAM zum Mitloggen über MUX parallel an den Bus zu schalten. Und dann, wenn mich der Speicherinhalt interessiert, einfach das RAM vom Steuergerät auf einen Auslese-µC umschalten.
Dabei muss natürlich beachtet werden, dass Daten korrumpiert sein können, weil gerade ein 16-Bit-Zugriff erst halb durch ist.
ob der auch DMA fähig ist weiss ich nicht. könnte aber sein.
Der 8051 ist nicht DMA-fähig. Der Bus hängt direkt am Takt. Man kann ihn also nur anhalten, wenn man den Takt gated. Dank statischem Design geht das, allerdings werden dabei dann auch die Timer abgehalten.
Man muss beim Disassembler doch noch einiges von Hand machen
Disassemblieren braucht überaus gute Prozessorkenntnisse und vor allem: viel Erfahrung. Da muss man erst mal mit einem einfachen selbstgeschriebenen(!) oder vom Compiler erzeugten Programm anfangen, damit man lernt, die "verdächtigen" Codesequenzen zu entschlüsseln und bestimmten Funktionen zuzuordnen.
Sind hier immer viele Trolle unterwegs? Ich finde den Umgang und
Kommunikation teilweise schon ein bisschen unverschämt.
Hier begegnet dir der Querschnitt der dich umgebenden Menschen. Und da sind (ob angemeldet oder nicht!) auch ein paar dabei, die dir nur die Zeit stehlen. Mach das, was du im normalen Leben mit solchen Menschen auch tust: Ignoriere sie!
Beachtet bitte dabei, das die 805... Prozzis
auch internes RAM, was zum Teil bitadessierung zuläßt
hat.
Ohne Disass der Initialisierung bekommt man dann
davon nix mit! :-O
Es wurde von (richtigen) Logicanalyzern gesprochen,
der Buspirate scheint a bisserl lahm und hat zuwenig Anschlüße. Titat von der Website: "10Hz-1MHz low-speed logic analyzer"
@Jens:
Das Du nen Eprom-Simulator hast weiß ich ja.
Hast Du auch ein TTL-Prüfstift und nen Durchgangsprüfer,
der zwischen purer Leiterverbindung und pn-Übergang
unterscheiden kann?
@ Horst: Danke für den Tipp, bisher kannte ich nur die englische Version zu dieser CPU. Ich habe die auch schon etwas länger liegen. Allerdings mich noch nicht so intensiv damit befasst. Aber es notwendig - das ist mir bewusst.
@ Roland: Danke für den Tipp, ich hatte das glaube ich auch schonmal gefunden. Für einen ersten Start gut. Der Eprom kann in grobe 4 Blöcke unterteilt werden:
0x0000 bis 0x1FFF
0x2000 bis 0x3FFF
0x4000 bis 0x5AFF
0x5B00 bis 0x7FFF
@ Lotta: Einen TTL-Prüfstift und nen Durchgangsprüfer,
der zwischen purer Leiterverbindung und pn-Übergang
habe ich nicht.
Was ich zur Messung genutzt habe ist das:
https://www.dataq.com/products/di-1110/
Als Signalgenerator einen JDS6600.
Danke an alle für all eure konstruktiven Beiträge! Eine Menge neuer Inputs für mich.
Ist er kurz auf "H" wechselt dann zu "L"
Wechselt er in unregelmäßigen Abständen zw. "H" und "L"?
RTFM... EA ist dauerhaft auf High oder Low. Alles andere ist vom Timing her potentieller Selbstmord. Das interne ROM ist in der Motronic immer aktiv. Es enthält die Startroutinen und alles, was geheim bleiben soll. Schau dir im Datenblatt das Kapitel über Code Protection an.
Es wäre hilfreich, wenn auch der Unterschied zwischen RAM und (E)PROM beachtet würde. Das geht hier munter durcheinander. Und zum ..ten mal: Der 80C5xx hat getrennte Adressräume für RAM (Daten) und ROM (Code). Die dürfen durchaus an der gleichen Adresse liegen. Die CPU greift mit unterschiedlichen Signalen (PSEN und RD/WR) darauf zu.
Wechselt er in unregelmäßigen Abständen zw. "H" und "L"?
EA wird aus Sicherheitsgründen nur einmal beim Reset gesampled. Im laufenden Betrieb kann man das ROM nicht ein und ausblenden. Der Pin wird also sehr wahrscheinlich auf 1 liegen. (EA = 0 wäre romless)
ich schau mal ich am Wochenende dazu komme. Wie ich die Antwort von Georg interpretiere, ist es aber wahrscheinlich nicht notwendig.
Vom Verständnis her möchte ich nichts durcheinander bringen wenn es so rüber gekommen ist @Georg.. ich habe verschiedene Dinge angesprochen.
EPROM - Externer ROM -> mein BIN File 0x0000 bis 0x7FFF (32 kB)
HM6264 - Externer SRAM -> was ich mit meiner ursprünglichen Fragestellung auslesen wollte - meine Einzelwerte von Interesse (8 kB)
CPU ROM: Gesamt 0x0000 bis 0x9FFF
0x0000 bis 0x1FFF lesbar.. CPU (8 kB)
erweitert angehängt von meiner BIN File
0x2000 bis 0x7FFF EPROM
0x0000 bis 0x1FFF EPROM
CPU internal RAM (256 Byte)
habe ich noch einen Speicher vergessen oder was verpeilt?
das ist so nicht richtig!
ext Rom Adressen werden erst ab 0x8000 auf den Bus gelegt, laut DB (*) sind die ersten 32K ROM (0x000 - 0x7FFF) intern auch wenn das Ding vermutlich nur 8K oder 16k Rom hat.
Das ist auch konsistent zu einem IDA Disassembler Lauf.
Eprom : 0x8000 .. 0xFFFF (PSEN)
SRAM : 0x0000 .. 0x1FFF (RD/WR)
CALLs nach 0x2xxx im Disassembly deuten auf 16K Rom hin.
danke für die Rückmeldung. So stehts im Datenblatt ja..
Zumindest gibt mir die o.g. Reihenfolge mein Tester so weiter wenn ich diese ROM-Adressen auslese.. 0x8000 bis 0xFFFF ist dann halt doppelt beim auslesen (EDIT: bzw. wäre dann korrekterweise der Bereich 0x2000 bis 0x7FFF teilweise doppelt) - da gehts dann beim EPROM wieder von vorne los.
Deshalb wollte ich ja wissen, ob der EA auf "H" oder "L"
liegt, wenn er auf dauernd "L" liegt liegen dann alle Routinen
im externen EPROM, auch die, die eventuell die "K" -Leitung
bedienen könnten. Wäre das nicht was, diese Routinen fürs
Projekt ausnutzen zu können?
Jens, was hast Du da ausgelesen?
Kannst du mal die Schnittstelle (n) beschreben?
Auch ich möchte lernen, wie ein Steuergerät aufgebaut ist.
moin,
wie ist den nun der hardware status?
/EA auf low oder high?
hatte diese motronic ( sie ist übrigens in deutschland/reutlingen gebaut worden) eigentlich schon den integrierten klopfregel-chip? müsste es eigentlich.
drehzahl nur das 60-2 signal oder auch noch das phasensignal?
k-line mit oder ohne l-line?
ein oder zwei lambda-sonden?
sonst hatten die kleinen dreier bmws ja nix besonderes.
wenn ich mich recht entsinne wurden die amd-rechner des 80515 nicht lange bei bosch verbaut. hauptlieferant wurde da recht schnell siemens (infinion).
Unser Jens hält sich mit seinen Erkenntnissen ganz schön zurück. :-((
Der weiß schon mehr und läßt uns hier hängen.
Deshalb hatte ich ja die Idee ein Projekt zu eröffnen
wo jeder seine Erkenntnisse vergleichen und darauf aufbauen kann.
Sowas wie "Suche Heinz Schnidt in der Welt" funzt nicht!
Ich würde als Erstes feststellen, an welche Ports des Prozzis
die Schnittstellen gehen.
Gibts I2C?
Wo sind die Sensoren angebunden?
Dann im Disassebling nach diesen Adressen suchen um
diese dann zu benennen. Das ist wichtig!
Standardschnittstellen wie serial sind dann im Disassembling sichtbar.
So wird das Disassembling langsam immer durchsichtiger, und die
"geheimen / versteckten" Routinen bleiben übrig.
So wie beim Decrypten die herausgefundenen Buchstaben langsam
Wörter ergeben, und man diese bereits erraten kann.
@Jens, hast Du mehere gleiche Steuerungen, um eine zu opfern?
ich habe nicht alles sofort parat und wissen tue ich auch nicht sofort alles. Ich habe auch gesagt das ich am WE mal sehe ob ich dazu kommen. Außerdem hab ich dir noch meinen Kontakt direkt weitergeleitet sodass du mich mal anfunken kannst und ggf. einige Dinge schneller zu besprechen wären als hier zu schreiben. Die Option hast du immer noch..
Ich musste mich erstmal schlauch machen wo der EA PIN ist und sicherstellen das ich mir nichts beim messen zerschieße wenn ich direkt an der CPU rumfummele - das hatte ich mich bisher nämlich nicht getraut.
EA ist durchgehend auf High (1) und zwar mit 5V sobald die Zündung an ist oder ich Drehzahl hinzu gebe (das MGS in Betrieb setze). Weiter hatte aber Thomas bereits die korrekte Vermutung das dieser dauerhaft auf 1 ist. Weiter hatte ich auch schon geschrieben, dass ich in der Lage bin den internen CPU ROM auszulesen was EA 1 voraussetzt nach euren Infos.
@ Horst: Danke für die Info mit Reutlingen :-)
Die M1.7.2 hat eine Klopfregelung mit 2 Klopfsensoren (EDIT: mit je einem) zwischen Z1 und Z2 und Z3 und Z4 und nutzt diese auch aktiv.
Schau mal oben die rpm.PNG an. Da ist in folgender Reihenfolge das 60-2 Drehzahlsignal, das Nockenwellensignal und der digitale Output des MGS für den Tacho zu sehen.
Für die Kommunikation werden TxD und RxD verwendet. Am Anfang zum Kommunikationsstart wird über RxD das MGS angefunkt um TxD freizugeben. Der Rest der Kommunikation erfolgt dann über TxD (K-Line wenn ich richtig Liege) in beide Richtungen und RxD wird nicht weiter verwendet.
Die Lambdaregelung erfolgt über nur einer Sprungsonde vor Kat.
Meine CPU ist von Siemens mit aufgedruckter Bezeichnung:
BD 267648
B 58024
A 9514EPB
(M) (C) Siemens 1984
es lebt :-)
MGS = MSG ( MotorSteuerGerät) in boschspreche
dann hast du ja schon so einiges an infos.
ist das extene ram eigentlich an der kl30 (dauerplus)?
bei einigen geräten wurden so die angelernten daten gepuffert.
die serie von steuergeräten hat fehlermeldungen als bilnkcode über die zündungsanzeigelampe im tacho ausgegeben. war recht langsam so im 1 bis 5 herz takt. bei einigen wenigen geräten waren damal auch schon eeproms für die festen daten und den fehlerspeicher drinn. meist kleine achtbeiner mit 256byte. weisst du wie die klopfsensoren funktionieren? zum testen der funktionen hatten die chip-entwickler damals recht abenteuerliche vorstellungen.
achja, wäre das nett ein schaltbild der büchse in der hand zu haben......
ich habe so beim durchlesen das gefühl das hier einige altgediente boschler sind. also einen gruss an alle.
ich vermute stark, dass das externe RAM an Dauerplus ist und hier Fehlerspeichercodes abgelegt werden getestet habe ich es noch nicht. Weiter werden hier vermeintlich Adaptionswerte zur Leerlaufregelung und Lambdaregelung liegen und weitere Sachen von denen ich keinen Plan habe. Meine gewünschten HEX-Werte wie aktueller End-Zündwinkel die mir auch die Diagnose raushaut vermute ich auch hier. Was wieder zur ursprünglichen Fragestellung diese Threads führt :-)
Tatsächlich bin ich mir aber gerade nicht mehr 100 % sicher wenn ich den RAM auslese ob analog wie bei dem ROM-Auslesen ein Teil der Adressen in internen und externen RAM aufgeteilt werden... Hmpf..
Das es sich nur um den interen CPU RAM handelt (256 Byte) spricht dagegen das ich auch Werte nach den Adressen FF bekomme (und zwar andere).
Ich würde unheimlich gerne wissen wie die Klopfregelung funktionert und welche Kennfelder hierfür herangezogen werden. Von der Theorie her müssten hier das Signal z.B. 50 mV/g, die Frequenz (eine APS oder FFT Transformation intern) und der Kurbelwinkel zusammenspielen. Ich weiß es nicht. Wer mich aufschlauen kann sehr gerne.
Gruß JB
Ich wollte die Signaleingänge bei meinem Laboraufbau auch mal simulieren habe aber noch keine passende Modulation hierfür gefunden. Welche Spannung, Welcher Offset und mit welcher Frequenz muss ich das MSG füttern damit er Laborsignale akzeptiert.. Soweit bin ich leider nicht. Ich habs mal im Leerlauf mit einem Sinus von 6500 Hz +-1 V und einem Offset von +1V probiert - schluckt er aber nicht.
ist zwar nicht das selbe MSG aber wahrscheinlich sehr ähnlich.
Vielleicht war die intern programmierte Diagnosefunktion des MSG auch garnicht dafür ausgelegt überhalb von 2600 1/min zu arbeiten. Ich weiß es leider nicht.
dass ich in der Lage bin den internen CPU ROM auszulesen
Um was wollen wir wetten, dass du das nicht kannst?
Du siehst Daten und vermutest, dass sie aus der CPU kommen.
Selbst in den 90ern war der Ausleseschutz der 80C5xx schon richtig gut. Und Bosch wusste, wie man ihn aktiviert.
Zum Thema Klopfregelung gibt es Tausende Seiten Papier. Ganz grob: Der Klopfsensor (ein Piezo Kristall) misst relativ breitbandig das Verbrennungsgeräusch. Der Rechner filtert die für den Motor spezifischen Frequenzen raus und misst die Amplitude bei den Kurbelwellenwinkeln, bei denen Klopfen auftreten kann. Der Mittelwert dieses Signals wird mit der aktuellen Messung verglichen. Ist der aktuelle Wert um den Faktor X höher als der Mittelwert, dann hat es geklopft und die Zündung muss nach spät verstellt werden. Hat es nicht geklopft, kann gaaaaanz langsam und vorsichtig nach früh verstellt werden.
der klopfsensorchip besteht aus einen gesteuertem vorverstärken (in zehnerstuffung) und einer nachgeschalteten filterbank ( mittenfrewuenz und bandbreite per 515 einstellbar). dieses wird je nach motortype und aktuellem betriebszustend vom 515 eingestellt und auf einen integrtor geleitet. dieser ist als analogausgang an den 515 gekoppelt. aus dem 60-2 wird dann ein messfenster generiert über dessen zeitraum das klopfen erfasst wird und an dessem ende der 515 den wert einliest. ohne klopfen hat der nahe 5Volt und nimmt mit zunehmenden geräusch immer weiter ab. gibt ein schönes bild auf dem ozzi.
die signale des körperschallsensor liegen im 10..200mV bereich.
die filterbank von 1..20khz res. /300h..1khz band.
da diese regelung recht langsam sein kann sind nur die einstellungen für verst./filter und messfenster mit 60-2 syncron. die einrechnung in den zündzeitpunkt und die mengenanhebung erfolgt recht moderat.
welche verstärkung und filterbank da gerage aktiv ist hängt stark vom zustand des motors ab. je älter desto klapprieger halt.......
moin lotta (du bist w?)
projekt wäre eine gute idee und sicherlich mit der zeit auch für andere
hilfreich. wenn aber keiner möchte................
Ja, weiblich 18 Jahre alt, kann seit 3 Jahren hören,
und interessiere mich brennend fürs Hacken von devices,
vor Allem in der Kommunikationstechnik, sowie Proggen in C++
/C++-Builder).
Ich hab nen Threadripper 32 Kerner mit 256 GB RAM,
unter Anderem läuft darauf ne Vollversion von IDA pro.
in der ich mich einigermaßen auskenne. (vollständig begreifen
kann das Proggy wohl niemand ohne ausreichende Engishkenntnisse.)
Wir haben übrigens auch eine er Ersten IDA's im Softwareregal
noch im weißen Plastikschuber mit 5,25 Zoll Diks. :-D
@Jens:
Nix für Ungut!!
Ich möchte bloß nicht, das hier mit kostenloser Arbeit unserer
OM's Geld verdient wird!
Leider ist meine e-Mail - Addy noch zur Zeit gesperrt,
weil mein Dad meinte ich bin unserem EDI vom Board hier zu
Nahe gekommen, (ma, der edi sit genauso geil wie mein verstorbener Opa);-)
Nun liegt unsere Admina in Corona, ich werd nochmal mit Vater reden müssen.
@ Georg: Ich sehe Daten und vermute das diese aus der CPU kommen. Das kann man schon so sagen. Auf dem Eprom sind diese definitiv nicht zu finden. Ich halte es auch für möglich das manche bereiche von 0x0000 bis 0x1FFF des internen ROM nicht lesbar sind und nur FF Werte rausgeben werden. Das es aber in Gänze nur irgendwelche vorgegaukelten Werte sind wäre jetzt aber auch sehr weit hergeholt ;-)
Der "vermeintliche" interne ROM spuckt mir Daten am Anfang aus. z.B. beginnend bei 0x0000 mit:
02 00 73 02 20 00 FF FF FF FF FF 02 20 10 FF FF
usw.
die Adressen "2000" und "2010" passt wiederum sehr gut zum Eprom Code..(bei 16er Breite betrachtungsweise. Das BIN File ist ja anbei und das ist sicher kein Zufall..
@ Georg: Wenn diese nicht aus der CPU kommen dann woher? Weißt du mehr dann schlau mich bitte auf.
@Jens:
Machst Du bitte im Projektordner nen Thread auf!
Achja,
Kannst Du im externen Eprom mal einen Speicherplatz auf "L"
setzen, und schauen, ob Du irgend ne Fehlermeldung bekommst?
das gleiche dann bitte auch in irgendeinem "FF" Block?
Der "vermeintliche" interne ROM spuckt mir Daten am Anfang aus.
Verrätst du uns bitte, wie du die Daten ausliest? Bei der CPU reicht es nicht hin, sie im Reset zu halten und die Adressen anzulegen. Die möchte einige Signale passend haben, um mit dir zu reden. Das Datenblatt hilft dir weiter.
Der "vermeintliche" interne ROM spuckt mir Daten am Anfang aus.
Verrätst du uns bitte, wie du die Daten ausliest? Bei der CPU reicht es
nicht hin, sie im Reset zu halten und die Adressen anzulegen. Die möchte
einige Signale passend haben, um mit dir zu reden. Das Datenblatt hilft
dir weiter.
Das Psen Signal.
Respekt, Georg, Du bist der Beste hier!!
Ein letzter Hinweis: Das ROM lässt sich im geschützten Zustand nicht auslesen und der Schutz ist fest in der Maske definiert.
Man kann nur verifizieren, dass der richtige Code drin ist: Die CPU wird in den Zustand "verify" gebracht (simpel) und dann betet man ihr alle Daten vor, wie sie drin sein sollen. Am Ende gibt es dann ein Signal "jawoll, hast Recht" oder "das war nix, probier es noch einmal". Wenn man das für alle möglichen Bitkombinationen probieren will, muss man schon sehr alt werden.
Die Hardware ist im Datenblatt genau beschrieben, wenig Aufwand. Im eingebauten Zustand wird es vermutlich nicht funktionieren.
Ein letzter Hinweis: Das ROM lässt sich im geschützten Zustand nicht
auslesen und der Schutz ist fest in der Maske definiert.
Man kann nur verifizieren, dass der richtige Code drin ist: Die CPU wird
in den Zustand "verify" gebracht (simpel) und dann betet man ihr alle
Daten vor, wie sie drin sein sollen. Am Ende gibt es dann ein Signal
"jawoll, hast Recht" oder "das war nix, probier es noch einmal". Wenn
man das für alle möglichen Bitkombinationen probieren will, muss man
schon sehr alt werden.
Die Hardware ist im Datenblatt genau beschrieben, wenig Aufwand. Im
eingebauten Zustand wird es vermutlich nicht funktionieren.
Georg,
Kann das Teil von innen augelesen werden etwa durch ne Routine
aus dem externen Eprom?
Hm. was da ausgelesen wurde, sieht wirklich wie ne Interrupttabelle aus..
die Adressen "2000" und "2010" passt wiederum sehr gut zum Eprom
Code
schwierig:
1
EPROM:2000 mov RAM_35, SBUF ; Serial Channel Buffer Register
2
EPROM:2003 setb C
3
EPROM:2004 ret
mir fehlt da RETI anstatt RET.
Nun kann man auch im Interrupt per RET aussteigen, allerdings ist der Interrupt danach immer noch aktiv und man muss da manuell selbst irgendwann ein RETI bauen.
Kannst du die kompletten 8k des ROMs hier einstellen?
du stellst mir die Frage obwohl du die Antwort weißt. Ich würde mich freuen wenn du mich aufschlaust. Ich fühl mich hier mittlerweile ganz schön aus der Reserve geholt und getestet :-(
Wenn ich in der Reihenfolge "Raten" soll bitte:
Über die korrekte Codereihenfolge über TxD
Über eine korrekte Anlage von einer fein definierten Spannung an einem oder mehrere PINs
Über das Verbinden einer oder mehrere PINs
@ Lotta: mal schauen ob ich die Tage dazu komme.
@ Thomas: Danke für deine Hinweise! :-)
du stellst mir die Frage obwohl du die Antwort weißt. Ich würde mich
freuen wenn du mich aufschlaust. Ich fühl mich hier mittlerweile ganz
schön aus der Reserve geholt und getestet :-(
Georg machts genau richtig. Nur durch absolutes Brainstorming
in diesem Thread kann er uns aus der Reserve locken.
Wir müssen selbst erkennen, wenn wir in ner Sackgasse stecken.
nur durch Probieren, also durch Hacken werden wir die Grenzen testen
können
Red auch Du wie dir der Schnabel gewachsen ist.
Brainstorming ist nicht beleidigen, sondern "aus der Reserve locken"
Achja:
Hier gehts nicht darum, wer den "Längsten" hat,
(da würd ich ja sowso versagen... :-P) sondern ein ungewöhnliches
Problem mit ungewöhnlichen Mitteln zu lösen!!
moin,
lotta hat wieder ideen.....
"Kann das Teil von innen augelesen werden etwa durch ne Routine
aus dem externen Eprom?"
wer würde den schon das eprom raus nehmen und gegen ein eigenes ersetzen in dem erstmal nur jede menge NOPs sind und schlieslich einfach alle intr. sperrt, die uart von hand initialisiert, dann mit MOVC..... den programmspeicher ausliest und das über die uart sendet.
völlig bescheuerte idee...........
würde doch kein mensch machen.
Lotta hat wieder ideen.....
"Kann das Teil von innen augelesen werden etwa durch ne Routine
aus dem externen Eprom?"
Das funktioniert im allgemeinen nicht. MOVC kann üblicherweise nicht den Inhalt vom internen ROM liefern, da kommt dann in ACC Unsinn oder 0xFF zurück. -> vgl Datenblatt Protection modes.
Lotta hat wieder ideen.....
"Kann das Teil von innen augelesen werden etwa durch ne Routine
aus dem externen Eprom?"
Das funktioniert im allgemeinen nicht. MOVC kann üblicherweise nicht den
Inhalt vom internen ROM liefern, da kommt dann in ACC Unsinn oder 0xFF
zurück. -> vgl Datenblatt Protection modes.
Das geht nur dann wenn nichts geschützt ist
Naja, Lotta hat wiedermal Ideen...
Hach, nun bin ich nach nem langen Tag zu Hause...
ich hatte folgendes gedacht:
IAR hat in seinem C-Compiler ein Zeiger, der Zeichenketen im ROM
aufnehmen kann und die dann im Programm benutzt werden können,
etwa sie in nen Puffer zu kopieren.
Nehmen wir an wir könnten im externen ROM in den freien "FF" Blöcken ein kleines throjanisches Pferd installieren, das durch ne andere original
aufgerufene Routine angesteuert wird, die interrupts aussschaltet
den Zeiger auf Null setzt und Byte für Byte doe Bytes des internen ROM
zu ner Schnittstelle, transferiert.
Die entsprechende Originalroutine würde dann statt des RET ein Sprung auf das Horseprogramm erhalten.
Dazu dürfte der EPROM aber nicht überwacht werden oder die Überwachung müßte umgangen werden.
Das funktioniert im allgemeinen nicht. MOVC kann üblicherweise nicht den
Inhalt vom internen ROM liefern, da kommt dann in ACC Unsinn oder 0xFF
zurück. -> vgl Datenblatt Protection modes.
Das geht nur dann wenn nichts geschützt ist
hmm..... wie lese ich dann daten aus dem internen rom wenn der movc nicht geht?
page 14:
"Effect: The access to internal ROM done by an externally fetched MOVC instruction is disabled. Nevertheless, an access from internal ROM to external ROM is possible."
Sowas ist auf fast allen MCS51 Controllern mit internem Code Speicher als Schutz eingebaut. Egal ob Mask Rom Eprom oder Flash
wenn das wirklich so ist: Das ist die Interrupt Vector Tabelle
0x0000: LJMP 0x0073 ;Reset
0x0003: LJMP 0x2000 ;ext IRQ
....
0x000B: LJMP 0x2010 ;Timer 0 IRQ
ist , wenn der externe Eprom von Null an gestartet wird.
Es ist also der Anfang des Inhaltes des externen Eproms!!
Hilfst du mir bitte?
Liegt der externe Eprom direkt hinter dem Masken -Eprom?
Wo beginnt er dann Adeßmässig? Nach 8 Kb intern?
den "vermeintlichen" internen ROM habe ich vollständig versucht auszulesen. Allerdings funkt das MSG teilweise dazwischen. Einzelne Werte können falsch sein. Im großen und ganzen aber sollte es passen. Ich habe es mal durch einen Disassembler gejagt. Datei anbei.
Ich habe es mal durch einen Disassembler gejagt. Datei anbei.
bitte poste das als bin. Das passt soweit der Anfang ist die Vectortabelle.
Wenn meine Vermutung stimmt ist das interne ROM allerdings 32k.
Ganz genau kann man das nicht sagen, da unklar ist welche Version des 80c515 zum Einsatz kommt.
Wenn meine Vermutung stimmt ist das interne ROM allerdings 32k.
Ganz genau kann man das nicht sagen, da unklar ist welche Version des
80c515 zum Einsatz kommt.
der externe EPROOM ist 32Kb lang.
Ich vermute, das Jens immer den externen ausließt.
Nur fängt der externe ja nicht bei Null an , sondern nach 8KB!
Deshalb sieht der inkalt so miess aus
Jens:
Du hat doch das Datenblatt des Prozzis, Kannst Du das mal ranhängen?
Jens, es bleibt dabei, es ist wieder der Extene Eprom,
auf NULL gemappt.
Wir müssen uns eingehend mit dem Prozzi beschäftigen,
wo endet der interne ROM, wo beginnt er externe,
damit wir wenigsten den externen disassemblieren können. :-((
Jens, es bleibt dabei, es ist wieder der Extene Eprom,
auf NULL gemappt.
dann bedienst du IDA falsch. Für mich sieht das schon nach gültigem Code aus. Allerdings handgeklöppelter Assembler Code. Meine Flirt Tabellen können jedenfalls keinen C Compiler erkennen. Es ist definitiv kein Keil und wahrscheinlich auch kein IAR C Compiler im Spiel.
sry dir das sagen zu müssen. Aber das 1. und 2. BIN sind zwei unterschiedliche Sachen. Den EPROM (externen Speicher) kann ich ja auch extern auslesen. Die zwei gehören auf jeden Fall zusammen mit unterschiedlicher Adressierung. Aus den beiden Dateien kann man eine machen wenn man diese richtig trennt und wieder zusammenfügt. Weiter oben mit meinem Post hatte ich das schonmal versucht zu erläutern. LDR hatte es auch angesprochen.
Ich habe nicht verstanden warum plötzlich von 32 kB internem ROM gesprochen wird.. Die Datenblätter die ich bisher gesehen habe sprechen dagegen.
danke für die Rückmeldung. Ein paar Flussdiagramme hatte ich selbst mal nur dem EPROM hinbekommen. Das da nun plötzlich nix brauchbares bei rum kommt bezweifel ich.
Ein Einwurf. Welche Programmiersprachen gabs denn zu dieser Zeit überhaupt die auch industriell verwendet wurden und hierfür in Frage kommen? Was gabs denn noch als Alternative zu C großartig und wurde in der Industrie verwendet?
Ich habe nicht verstanden warum plötzlich von 32 kB internem ROM
gesprochen wird.
Schau in das Datenblatt was ich verlinkt habe.
Da steht eindeutig dass diese Variante 32k interner Code hat (83C515A-5).
Siemens hat einen ganzen Sack voll unterschiedler 80c515 Varianten gebaut.
Welcher bei dir genau drin ist wissen wir nicht.
Deshalb habe ich auch vermutet dass das ext Eprom erst ab 0x8000 anfängt.
die antwort zum compiler kann ich geben.
handgeklöpelter assembler code ist richtig. hier war noch optimierung wichtig da die kleinen cpu's zu schwach waren alles in einer kurbeldrehung zu berechnen.
offen für den kunden waren nur die tabellen und filtervectoren/koefizenten um das motorlaufgefühl fest zulegen. diese liegen im externen eprom und konten sich schon mal alle 3 monate ändern.
in der software müsste ein testmodus stecken der für die serienproduktion zum testen verwendet wird, dieser erlaubt die steuerung aller msgfunktionen ohne motor simulation. kann sein das dieser durch die beschaltung mit unplausiebelen sensorwerten eingeleitet wird.
zur klopfregelung: das ist wohl noch die teil integrierte lösung ( extra pigipack). bei diesen war die filterbank am anfang noch fest bestückt und nur die verstärkung prog. bar.
irgendwie ist mir der pegel von /EA noch nicht klar oder habe ich das überlesen?
der EA PIN ist dauerhaft auf 1 (High) mit 5 V sobald Zündung an oder Motor/Simulator in Betrieb.
Um Code grob von den Tabellen zu trennen hier die Hinweise zum EPROM:
Ende von 0x0000 bis 0x1FFF enthält diverse direkt lesbare Info´s zum Steuergerät und der Software und weitere grundlegende Einstellungen.
Bereich zw. 0x4000 bis 0x5AFF ist mit Tabellen und
Filtervektoren/Koeffizenten befüllt. Hier gibts auch eine "Kennfeld-Index-Tabelle", die auf weitere Tabellen hinweist.
Die Messrohdaten der Klopfsensoren sehen so wie auf dem angehängten Bild aus.
Bzgl. des 80c515 und des 80c515a.. Auf meinem 80c515 ist 1984 aufgedruckt. Mein MSG wurde bis ca. 1995 verbaut.Ab wann wurde der 80c515a hergestellt bzw. verbaut - kann man den nicht eher über das Baujahr/Einführung ausschließen?
Es gibt soweit ich es gelesen habe auch Unterschiede bei der PIN Belegung (3?) Kann ich die Unterscheidung der CPUs messtechnisch ermitteln?
Das ist das Jahr der Einführung der Serie nicht das Produktionsjahr. Das Teil wurde anfangs noch in NMOS später dann in CMOS gebaut. Die ersten MCSUs waren 80535 (Romless NMOS) und 80515 (8kRom NMOS). Vieleicht kann sich noch jemand daran erinnern dass die CMOS Versionen abgeraucht sind wenn man diese in Board gesteckt hat was für NMOS konstruiert war.
Siemens hatte schon immer ein besonders Händchen was die MCU Bezeichnungen angeht. Viele wurden auch exklusiv im Automotive Umfeld eingesetzt so dass gar keine genauen Daten verfügbar sind.
Das ROM Binary verlängert alle Interrupts nach 0x20xx was ja auch sinnvoll ist damit man noch Einfluss auf die Interrupts hat. Das deutet erst mal auf eine 8K Version hin. Allerdings gibt der Epromcode dort keinen Sinn wenn man annimmt dass Eprom:0 -> ext:0x2000 gemapped ist. Nun ist es natürlich möglich dass das Eprom anders in den Adressraum eingeblendet wird.
Vielleicht hast du ja Infos wie Eprom Adressen im Adressraum der CPU liegen.
Das RAM ist ziemlich sicher ab 0x000 eingeblentet. An vielen Stellen wird mit MOVX @R1 / MOVX@R0 darauf zugegriffen (P2=0) ->PDATA Adressierung
Das Mapping des (gesamten) ROM vermute ich wie folgt:
ROM Gesamt 0x0000 bis 0xFFFF:
0x0000 bis 0x1FFF = interner CPU ROM
0x2000 bis 0x7FFF = 0x2000 bis 0x7FFF EPROM
0x8000 bis 0x9FFF = 0x0000 bis 0x1FFF EPROM
0xA000 bis 0xFFFF = 0x0000 bis 0x7FFF EPROM
ja ab EPROM:0x2000 stehen entsprechende Interrupt Handler das sieht richtig aus.
0xA000 bis 0xFFFF = 0x0000 bis 0x7FFF EPROM
das dürfte dann irgend was gespiegeltes sein
man müsste also das Eprom Binary umsortieren damit man gültigen Disasm Code bekommt.
Ich habe 2 kurze Kopierfunktionen im internen Rom gefunden die Daten umkopieren. Davon gibt es sicher noch mehr.
Einen Aufruf hab ich mal manuell kommentiert
1
code:0B21 code_B21: ; CODE XREF: code:06D3j
2
code:0B21 ; code:code_6F0j ...
3
code:0B21 mov R1, #0x2E ; '.' ; src = x:0x2E
4
code:0B23 mov R0, #0x95 ; 'ò' ; dest = x:0x95
5
code:0B25 mov R5, #8 ; 8 bytes
6
code:0B27 lcall _pcopy_To_R0
7
code:0B2A jnb F0, code_B42 ; done?
8
code:0B2D mov A, #60 ; 60 loops
9
code:0B2F
10
code:0B2F code_B2F: ; CODE XREF: code_920+210j
11
code:0B2F dec A
12
code:0B30 jnz code_B2F
13
code:0B32 jb RAM_29.2, code_B3A
14
code:0B35 mov SCON, #10010000b ; Serial Channel Control Register
das bild hast du am laufenden motor aufgenommen?
schön wäre es wenn da auch noch das drehzahlsignal (60-2) oder die bezugmarke (nockelwelle) mit drauf wäre.
/AE ist nur zum zeitpunkt des cpu-reset wichtig. der wird aber eigentlich nicht mit der kl15 generiert. sonst würden die nachlauf-funktionen (z.b. benzinpumpe) nicht sauber gehen und es kein definiertes wiederstart verhalten ( zündung aus, einige sekunden warten, zündung an) geben.
hier ist die KL30 (12v Dauerplus) wichtig. mit aufschalten des hauptrelais geht es dann eigentlich los.
du bist schon ordentlich weit gekommen. schön.
kleiner tip: im debug listing würde ich mich von den interupts aus durch hangeln. also uart, timer und externe int. das gibt dann schon mal ein funktionsgerüst.
@ Lotta: da passt was nicht bei dem was du da zusammengesetzt hast. (Motorsteuerung.bin)
@ Thomas: ich habe es Neu zusammengefügt, so wie ich es für korrekt halte. Den Bereich 0xA000 bis 0xFFFF habe ich weggelassen.
@ Horst: ja das Bild ist bei einem Hochlauf aufgezeichnet worden. Keine SIM. Weiter oben habe ich die Drehzahlen "rpm.PNG" mal als Beispiel dargestellt. Ich komme aber mit der Abtastrate mit meiner Messhardware bei hohen Drehzahlen und der Anzahl der Messkanäle schnell an die Grenzen um dies noch sauber aufzeichnen zu können. Analog zum Klopfsensor. Für eine saubere Frequenzanalyse bis 10 kHz müsste ich schon mit ca. 26 kHz abtasten. Aua :-)
Was soll die bringen? Die BMW Ingenieure haben viele Stunden investiert, um die optimale Position der Klopfsensoren zu finden und den Eingangsfilter zu wählen. Da kannst du nichts verbessern.
Du kannst allenfalls die Leistung steigern indem du die Klopfregelung aggressiver machst über K-Faktoren und Timing. Aus eigener Erfahrung kann ich dir sagen, dass kurz vor dem Optimum sich das Motorgeräusch abrupt ändert. Im günstigsten Fall bist du dann mit einem neuen Satz Kolben dabei.
ich bin mir ziemlich sicher du weißt deutlich mehr, irgendwie pisst was ich hier poste. Warum weiß ich nicht.
Ich würde mich sehr freuen wenn du uns mit deinem Fachwissen aufschlaust. Es wäre schöner wenn man sich gegenseitig hilft anstatt mit seiner Fragestellung Unfähigkeit zu implizieren.
Nach wie vor möchte es verstehen wie das MSG werkelt. Ich hätte sehr gern am Anfang wo ich bloss mit einem Chipinhalt dagestanden habe jemanden gehabt, der mir gewisse Sachen genauer erklärt. Aber das macht kaum jemand leider.. Wie soll man was lernen wenn´s einem keiner erklärt? Dann muss man sich eben viele Dinge selbst erarbeiten. Und ich werd mich auch sicher nicht von meinen Zielen abbringen lassen wenn mir jemand sagt das ist quatsch oder das funktioniert nicht. Das möchte ich dann schon gerne selber entscheiden bzw. zu diesem Schluss kommen und eine eigene Aussage treffen zu können ohne irgendwas undetailiertes halbgarres nachzuplappern. Meine persönliche Meinung ist es, bestehendes erprobtes aus der Großserie an sein Bedürfnisse anzupassen (MSG). Und bei dem was ich bisher getestet habe, sollte man es immer Individuell an seine Bedürfnisse anpassen.
Welche "spezielle Deckel" meintest du denn?
Welchen "Tunerschutz" meinst du denn?
Hab ich eigentlich die "Wette" gewonnen?
Verrätst du uns bitte, wie DU die Daten ausliest?
ich habe es Neu zusammengefügt, so wie ich es für korrekt
halte. Den Bereich 0xA000 bis 0xFFFF habe ich weggelassen.
das passt sehr gut. IDA zeigt schon im ersten Lauf fast alles in blau was bedeutet dass fast alles als Funktionen erkannt wird. Ein weiteres Zeichen für handgeschriebenen Assembler Code.
mehr als 32k handoptimierter ASM Code das ist ein ganz schöner Brocken...
Das lst File ist der fast unveränderte 1. Disassembler lauf.
@ Lotta: da passt was nicht bei dem was du da zusammengesetzt hast.
(Motorsteuerung.bin)
Ich hab die beiden Files mit dem Total Commander zusammengeführt
da ich meinte, die liegen hintereinander, der 2. EPROM fängt
ja mit 0X2000 an
Was hab ich falsch gemacht / gedacht?
hilf mir, ich möchte auch lernen, dazu bin ich hier.
vielen lieben Dank. Es ist ja jetzt schon einiges zusammengetragen worden. Ich bedanke mich nochmals für alle konstruktiven Beiträge und auch Einwürfe.
Würde mich freuen wenn das auch mal jemand anderem hilft und bei mir noch weitere Früchte trägt. Jetzt habe ich auf jeden Fall sehr viel wo ich weiter ansetzen kann.
OM's, wenn das handgemachter Code ist, warum ist der immer noch so
zerrissen? Da ist doch nix optimiert, oder?
Überlappen sich da beide EPROMS? Warum, wenn da einfach Bereiche weggelassen werden können?
Achja, bedenkt bitte, das ich schlappe 2 Jahre Erfahrung
hab ( die letzten 2 Jahre hab ich ja im Internat verbracht )
und das ich brennend lernen möchte.
nun die Controller sind mindestens doppelt so alt wie du...
Ich versuch es mal.
MCS51 Controller können extern 64k Code + 64k RAM ansprechen. Code wird mit PSEN aktiviert, RAM mit RD/WR. Georg hat dazu ja schon was geschrieben
Controller mit internem ROM aktivieren PSEN nur wenn die Adresse nicht mehr im internen ROM liegt. Im einfachsten Fall schliest man einfach OE vom Eprom an PSEN, CE auf GND, A0..14 und D0-D7 an die MCU.
Die Konsequenz ist das 0x000..0x1FFF des Eproms erst mal nicht für die CPU sichtbar ist. Ab 0x2000 wird das externe Eprom dann "sichtbar". 0x2000..0x7FFF des Eproms liegen für die CPU auch bei 0x2000..0x7FFF.
Bei der CPU Adresse 0x8000 gibts einen Überlauf da das Eprom kein A15 hat.
Im Ergebnis bedeutet das die CPU sieht das Eprom nochmal von 0x8000..0xFFFF.
Da wir aber nur 8K + 32K insgesammt haben reicht es eben nur 0x0000..0x9FFF zu betrachten. Der Rest wird ignoriert da es sich nur um eine Spiegelung durch die unvollständige Dekodierung handelt.
für die Motronic Steuergeräte gibt es spezielle Gehäusedeckel (ETK), die Elektronik beinhalten und mit deren Hilfe das Steuergerät an einen PC angeschlossen werden kann. Das wird ergänzt durch eine Meßgeräte für diverse Größen (u.a. Lambda). Über dem ganzen thront eine Bosch Software, die alles verwaltet und auch eine GUI zum verstellen/messen bietet.
Welchen "Tunerschutz" meinst du denn?
In der Steuersoftware sind einige Funktionen eingebaut, die Verhindern sollen, das die Daten manipuliert werden. Die Checksumme ist nur eine davon. Bei erkannten Manipulationen wird unterschiedlich eingegriffen. Aus Sicherheitsgründen ist es z.B. nicht zulässig, während der Fahrt den Motor abzustellen oder die Maximaldrehzahl ruckartig zu reduzieren.
Verrätst du uns bitte, wie DU die Daten ausliest?
Die muss ich nicht auslesen. Die kann ich auf dem kleinen Dienstweg bekommen. Aber der Bootlader im CPU-ROM und die dort liegenden Funktionen sind für den Applikateur uninteressant. Und für die Daten im EPROM habe ich das DAMOS File, das mir alle Kennlinien, Kennfelder, Funktionen usw genau beschreibt.
Ich werde hier mit Sicherheit nicht aus dem Nähkästchen plaudern. Das würde maximalen Ärger mit meinem früheren Brötchengeber bedeuten. Ich kann nur mit kritischen Fragen versuchen, dich von den schlimmsten Einbahnstraßen fern zu halten. Was du vorhast, ist machbar. Das haben einige Leute in Osteuropa schon gezeigt. Die geben ihr Wissen aber nur gegen reichlich Bargeld weiter. Ansonsten wird in dieser Branche viel mit Schlangenöl gehandelt.
nun die Controller sind mindestens doppelt so alt wie du...
Ich versuch es mal.
MCS51 Controller können extern 64k Code + 64k RAM ansprechen. Code wird
mit PSEN aktiviert, RAM mit RD/WR. Georg hat dazu ja schon was
geschrieben
Controller mit internem ROM aktivieren PSEN nur wenn die Adresse nicht
mehr im internen ROM liegt. Im einfachsten Fall schliest man einfach OE
vom Eprom an PSEN, CE auf GND, A0..14 und D0-D7 an die MCU.
Die Konsequenz ist das 0x000..0x1FFF des Eproms erst mal nicht für die
CPU sichtbar ist. Ab 0x2000 wird das externe Eprom dann "sichtbar".
0x2000..0x7FFF des Eproms liegen für die CPU auch bei 0x2000..0x7FFF.
Bei der CPU Adresse 0x8000 gibts einen Überlauf da das Eprom kein A15
hat.
Im Ergebnis bedeutet das die CPU sieht das Eprom nochmal von
0x8000..0xFFFF.
Da wir aber nur 8K + 32K insgesammt haben reicht es eben nur
0x0000..0x9FFF zu betrachten. Der Rest wird ignoriert da es sich nur um
eine Spiegelung durch die unvollständige Dekodierung handelt.
Hat der Controller nun nen Ausleseschutz oder nicht?
Wie seid ihr an den Internen ROM herangekommen?
Na klar Du hast Recht, der ganze Kram ist ja modulo, also wie das
analoge Uhrblatt aufgebaut.
Wenn ne unsigned Variable überläuft, fängt ja die Zählerei auch wieder von Vorn an--- :-O
Respekt, daran hab ich nicht gedacht...
Mir ist aber unverstädlich, warum beide Disassembler bei
der Interrupttabelle crashen. Ist das für sie so kompliziert?
Hat der Controller nun nen Ausleseschutz oder nicht?
Wie seid ihr an den Internen ROM herangekommen?
Das musst du Jens fragen der hat das ja ausgelesen. Mir ist kein Weg bekannt einen gesetzten Lock zu umgehen. Ich gehe deshalb davon aus das kein Schutz gesetzt ist.
IDA kann das letzte Binärfile einwandfrei disassemblieren. Probiers aus du hast ja die Vollversion. Hast du mal in mein Listfile reingeschaut? da sind alle IRQs der Reihe nach aufgeführt
IDA kann das letzte Binärfile einwandfrei disassemblieren. Probiers aus
du hast ja die Vollversion. Hast du mal in mein Listfile reingeschaut?
da sind alle IRQs der Reihe nach aufgeführt.
Werde ich machen, ich war gestern verdammt müde und ich komm jetzt
aus dem Schulnetz. :-P
Sag mal, wenn ich die beiden EPROMS zusammengeführt hätte
und den Gesamteprom dann beo 0X8000 abgeschnitten hätte,
wär das dann richtig?
für die Motronic Steuergeräte gibt es spezielle Gehäusedeckel (ETK), die
Elektronik beinhalten und mit deren Hilfe das Steuergerät an einen PC
angeschlossen werden kann.
Hast Du solchen Deckel mal gesehen?
Hat die Elektronik nen eigenen Prozzi oder ist da
"nur" Logic, Hühnerfutter und ne serielle Schnittstelle drauf?
Sowas kann man gut mit Eprom Programmiersoftware machen indem man die Buffer manipuliert. Nicht ohne Grund hatte ich vor Tagen mal geschrieben, dass der Disassembler erst dann sinnvoll eingesetzt werden kann wenn das komplette Codemapping bekannt ist.
Da ich meine Brötchen u.A. mit der Applikation der Motronic verdient habe, lies sich das nicht vermeiden :-) .
Hat die Elektronik nen eigenen Prozzi oder ist da
"nur" Logic, Hühnerfutter und ne serielle Schnittstelle drauf?
Da ist einiges an Intelligenz drauf. Schliesslich willst du ja im Betrieb ohne groß zu stören auch das Innenleben (RAM) der CPU inspizieren können.
Die Schnittstelle zum Laptop war der Druckerport, möglichst in bidirektionaler Ausführung. Falls dir beim Anblick einer RJ45 Steckverbindung Zweifel kommen: Hier wurde nur ein Stecker zweckentfremdet.
Die Schnittstelle zum Laptop war der Druckerport, möglichst in
bidirektionaler Ausführung. Falls dir beim Anblick einer RJ45
Steckverbindung Zweifel kommen: Hier wurde nur ein Stecker
zweckentfremdet.
Absolut geil!
Dann weißt Du bestimmt auch, wieviel Pole der Header
im Steuergerät hat, wo die geile Elektronik dann innen
angeschlossen ist?
@Thomas!!
Das Mapping...
Mann, das nenne ich dann mal "Augenhöhe"!! :-O
Dein Listing hab ich mir inzwischen angesehen. :-O
BOAHHH--- :-O Machst du / ihr weiter?
@Jens:
Ich hab mal ne PDF rangehängt, was die Wekstätten alles so haben.
Für mich ist ja alles neu und interessant.
In welchen Autotyp war die Steuerung eigendlich eingebaut?
Gibts da ne Seriennummer oder so die Du her mal posten könntest?
Ich bin mit Vater überein gekomen, sowie unsere Admina aufstehen
kann funzt die Email dann wieder, Ich send dir dann ne Mail.
hatten die Autos damals schon nen elektronischen
Tacho?
Dann müßte im Steuergerät ja auch EEPROM oder
gepufferter RAM für den Tachostand drinne sein,
nicht wahr?
ein Tester z.B. wäre der TEXA AXONE der reizt über L-Leitung und kommuniziert dann weiter über die K-Leitung. Es gibt auch ein Programm das heißt Testo Standalone.
Ich bin auch teilweise weitergekommen was den RAM-auslesen angeht. z.B. ist die RAM-Adresse für die Diagnosedrehzahl nur 1 Byte lang. Wenn also der Wert FF (255) erreicht ist und mit Faktor 10 multipliziert wird, ist klar das hier auch kein höherer Wert als 2550 1/min angezeigt werden kann.
Jetzt die Frage ob es noch eine RAM Adresse gibt, die höhere Werte ausspuckt.
@ Lotta: Ich hab nix von dir bekommen. Keine Email oder Anruf. Probiers doch nochmal wenn weiterhin interesse besteht.
@ Georg: Meinst du mit ETK = ETAS?
bzgl. der Klopferkennung. Ziel wäre auf digitalem Wege ein Klopfereignis zu erkennen. Die Funktion weiter verstehen. Es gibt ja Faktoren und Schwellen die ggf. an geänderte Präferie des Motors angepasst werden könnten. Deaktivieren möchte ich diese nicht. Das würde u.a. damit realisiert werden können sodass die Kühlwassertemperatur manipuliere. Das sollten hier kleiner = 37°C sein. Aber die Klopfregelung möchte ich beibehalten. Für wen es interessant ist, habe ich mal eine WAV vom Klopfsensor beigefügt.
@ Thomas: Bist du beim disassemblen weiter gekommen?
@ Lotta: Ich hab nix von dir bekommen. Keine Email oder Anruf. Probiers
doch nochmal wenn weiterhin interesse besteht.
Es ist zum Kotzen... :-O
Meine mail ist durch nen Spamassin abgelehnt worden..
Bitte schick mir noch mal ne Mail übers Forun
und schreib bitte deine Mailaddy mit rein!
Ey, natürlich bin ich am KWP2000-Protokoll intressiert,
und wenn sich Dein Display mit dem Steuergerät verbinden soll,
muß es dieses sprechen, wenn wir ne universielle Lösung
proggen wollen... :-O Alle anderen Lösungen würden ja nur mir
deinem persönlichen Teil funktionieren.
Lotta hats dann nach ein paar Anläufen doch geschafft sich bei mir per Mail zu melden. Sie ist soweit ich es aus dem kurzen Schriftwechsel beurteilen kann schon sehr speziell. Ohne die Person mal gesehen zu haben oder mit ihr zu sprechen ist das schwierig zu beurteilen^^
Ich kenne nicht alle Steuergeräte. Aber die, die ich kenne (Digijet, Digifant, diverse Motronic) lassen die Diagnose mit niedriger Priorität im Hintergrund laufen. Da blockiert nichts.
Es gibt Software - speziell die etwas älteren Versionen - die rechnet mit Logarithmen. Da die alten Prozessoren nicht multiplizieren konnten, hat das Vorteile. Aus einer Multiplikation wird eine Addition, aus einer Division eine Subtraktion. Erst ganz am Ende geht man dann per Tabelle wieder in den linearen Betrieb über.
Es ist nicht unüblich, Messwerte oder Drehzahl auf 8 Bit zu komprimieren. Man bekommt dadurch eine gleichmässigere Verteilung der Stützstellen. Bitte immer im Kopf behalten: Rechengeschwindigkeit und Speicherplatz waren Ende der 70er als die ersten digitalen Steuerungen entstanden sehr begrenzt. Die erste Einspritzung im VW T3 lief mit 4.2MHz Takt in einem 8049 mit 2kBytes Eprom.
ich habe leider kein Schaltbild zu meinem MSG. Ich habe eins gefunden, was meinem aber sehr nahe kommt auch wenn wahrscheinlich nicht 100 % baugleich. Denke bei dem verlinkten handelt es sich um ein 0261200175 MSG.
Würde dir ein Foto von meiner Platine weiterhelfen?
Bringt es dir was, wenn ich die Eingänge von den Klopfsensoren durchmesse und den entsprechende Chip hierzu ausfindig machen kann?
moin,
das schaltbild zeigt nur die hauptplatine des msg.
fotos der kleinen klopfsensor-platine von ober und unterseite wären nicht schlecht.
zur drehzahlauflösung hat georg dir ja schon tipps gegeben. die mengentabellen kann man ruhig in sechigerschritten machen oder nach drehzahlbereich scallieren. das timing der zündung, einspritzung und klopfsensoren werden nach drehwinkel aus dem 60-2 gewonnen.
wie weit seid ihr den beim reassamblieren? hast du dir mal bei DTA die neutralen msg's und ihre konfigurierung angeschaut? da wird dann auch einiges klarrer.
viel spass Horst
Mann, @Jens, so langsam wird mir klar was Du für ein geiles
Hobby hast! :-O
Schade, das die ganze Verbrennerei "den Bach runtergehen" wird,
und in Zukunft "Internetfirmen" unsere Autos bauen werden. :-(((
Thomas hat Recht, wir brauchen ne "Initialzündung" .
@ Thomas:
Wie würdest Du als Extremassembler den Parser der K1- Leitung
implementieren?
Mit ner Befehlstabelle, die die Befehlsbytes enthält,
und ner 2. Tabelle, die per index an die Befehlstabelle
gebunden ist, und wo dann die call-Aufrufe der Funktionen
drinnestehen, die dann die entsprechennde RAM-Zellen beschreiben
oder lesen?
Hast Du nen Vorschlag?
@jens:
Als unser Georg über den Spezial-Deckel und dessen Elektronik
sinniert hat ist mir folgendes aufgefallen:
Der Deckel enthält einen aktiven Prozessor, der vielleicht
nen erweiterten Befehlsparser und Ringpuffer verwaltet.
Die parallele Schnittstelle zum PC deutet darauf hin, das das
Verwaltungsproggy auf dem angeschlossenen PC ein DOS-Proggy
mit Dongle-Sicherung war, so es in den 90'er Jahren auch für
die Module in der Vermittlungstechnik üblich war.
Nun muß ja die Deckeleltronik irgendwie mit der PLatine
des Steuergerätes verbunden gewesen sein, es muß also nen
freien Konnector dafür geben.
Oder wwr die Steuerelektonik direkt ans OBD angeunden, was
ich nicht glaube, da OBD ja mit 12 Volt Signalpegel arbeitet.
Kannst Du bitte mal schauen, ob es diesen ominösen freien
Konnector auf der Platine gibt?
Wie würdest Du als Extremassembler den Parser der K1- Leitung
implementieren?
keine Ahnung von was du da redest.
Da muß ich mich länger auslassen, ich werd das genauer ausarbeiten.
Mal kurz angedeutet:
Das Wartungsprogramm unterhält sich bei der wartung mit dem Steuergerät.
Dies macht es über die K-Leitung in serieller Frorm über das KWP2000
Protokoll.
Dazu sendet es in seinem Übertragungsrahmen unter Anderem Befehlsbytes,
die dann im Steuergerät die entsprechende Bearbeitung auslösen.
Dazu sind alle Befehlsbytes in einem Array hintereinander aufgeführt.
Der Parser, also die Protokollauswertung entnimmt dem bereits auf
"in Ordnung" getesteten Rahmen diese Byte und sucht es dann im Array.
gleichzeitig könnte es ein 2. Array geben, in dem auf den
entsprechenden Plätzen die Einsprünge in die Verarbeitung stehen.
Wenn jetzt der befehl im 1. Array auf Platz 42 steht, sucht der Parser
die verarbeitungsroutine im 2. Array auch auf Platz 42 und führt sie aus.
Kannst Du bitte mal schauen, ob es diesen ominösen freien
Konnector auf der Platine gibt?
Natürlich gibt es den "ST1 - Main 88-Pin Connector" im Schaltbild von
Jens.
Was willst du mit dem Deckel? Das ist properitäre Bosch Technologie und
ganz sicher nicht verfügbar. Das führt ganz sicher nicht weiter.
Schade, es hätte ja sein können das da ne besondere Buchse
vorhänden wäre...
Es soll wohl nicht sen.
Klaus, willkommen im Club!
ist ja nur ne Theorie von mir, die aus ner Beschäftigung
mit HDLC herrührt und die natürlich praktische Arbeit
nach der Vorschrift des "Wasserfalls" am Objekt erfordert.
Hey!
Du weißt es besser? Zeige es mir! :-O
Wir brauchen Leute wie dich. Spart Mannjahre! :-P
