Announcement: there is an English version of this forum on Hallo zusammen, 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. der SRAM wäre folgender: "B58115" https://shop.tvsat.com.pl/en_GB/p/3pcs-B58115-HM6264-SMD-SO28L-FUJITSU-BULK/26820 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? Danke und viele Grüße, JB
:
Verschoben durch Moderator
Kannst Du vergessen, Jens. 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 > und kann mir jemand hierzu etwas empfehlen? Du kannst mal schauen ob es noch Dualport-Ram gibt. Waren aber schon immer etwas exotisch, also selten und teuer. Olaf
Jens schrieb: > 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. Georg
Jens schrieb: > 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. > der SRAM wäre folgender: "B58115" > https://shop.tvsat.com.pl/en_GB/p/3pcs-B58115-HM6264-SMD-SO28L-FUJITSU-BULK/26820 > Gibt es für meinen gewünschten Einsatzzweck fertige Hardware zu kaufen Nein. Wirst Du selber machen müssen. Und zwar nicht mit dem obigen SRAM, sondern mit dem hier: https://www.renesas.com/eu/en/products/memory-logic/multi-port-memory/asynchronous-dual-port-rams/7005-8k-x-8-dual-port-ram 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. Beispiel: http://www.hantek.com/products/detail/14 Und: Du hörst nur passiv mit, kannst also nicht selber eingreifen. Dabei entstehen recht große Datenmengen, das Auswerten wird also etwas Arbeit. Das sind im Wesentlichen Deine Optionen. fchk
Hallo Nils, 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. Gruß Jens
Es gab mal einen RAM-Simulator, siehe https://www-user.tu-chemnitz.de/~heha/basteln/PC/Programmierger%C3%A4te/PEPS-III/ Ob/wo es sowas (in modern, USB statt LPT) fertig zu kaufen gibt... ? 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.
Jens schrieb: > 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? > der SRAM wäre folgender: "B58115" > https://shop.tvsat.com.pl/en_GB/p/3pcs-B58115-HM6264-SMD-SO28L-FUJITSU-BULK/26820 Entgegen den Angaben auf der Webseite glaube ich, dass der RAM-Typ ganz simpel "HM6264" lautet.
Hallo Frank, 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 :-) Speichergröße, Schreibgeschwindigkeiten, Timing? Danke und Gruß, JB
Hallo Grummler, 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 :-) Danke und Gruß, Jens
Jens schrieb: > Diese möchte ich auslesen mit einer Funktion versehen und über ein > Display wiedergeben. Nein, das möchtest Du nicht. Das ist genau Deine vermeintliche Lösung für das eigentliche Problem, nicht das Problem selber. Wenn Du dazu sagst, für welche Anwendung man so eine Lösung überhaupt brauchen sollte, dann könnten Leute womöglich eine bessere Lösung vorschlagen.
Nils schrieb: > Kannst Du vergessen, Jens. 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.
Moin, Jens schrieb: > 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... Gruss WK
Ich kann Gedanken lesen. "Ich will Werte aus meinem Steuergerät für mein 1.8T auslesen und auf fancy Anzeigen im Cockpit anzeigen lassen".
Ich bin am Interpretieren meines Motorsteuergerätes und komme ohne diese Werte nicht weiter.
Jens schrieb: > Hallo Grummler, > > 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. Sehr dubios.
Glaub mir, den Aufwand das Auszulesen lohnt nicht. Kauf dir ein freiprogrammierbares Steuergerät und gut ist.
Dergute W. schrieb: > 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.
Moin, 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. Gruss WK
Jens schrieb: > 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 ;-)
Jens schrieb: > 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?
:
Bearbeitet durch User
@ Grummel 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. MfG JB
Jens schrieb: > "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.
@ Roland: es handelt sich um eine Bosch Motronic M1.7.2. 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. Gruß Jens
Hallo Rolf, > 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? MfG JB
Beitrag #7319759 wurde von einem Moderator gelöscht.
Sind hier immer viele Trolle unterwegs? Ich finde den Umgang und Kommunikation teilweise schon ein bisschen unverschämt.
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
Jens schrieb: > und wie setze ich sowas um? 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.
Hallo Erich, 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 :-) MfG JB
Mit einem E(E)PROM und 8 Latches könntest du 8 Werte auslesen. Das EPROM muss an der einen Stelle die dich interessiert, das Latch triggern
Beitrag #7319865 wurde von einem Moderator gelöscht.
Jens schrieb: > Nochmal um klarzustellen, ich will nur lesen. Nicht schreiben :-) Auch da kann es aufgrund von Race Conditions zu Fehlern beim Zugriff auf Daten > Busbreite kommen.
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. Einen sehr ähnlichen Schaltplan zu meinem Steuergerät habe ich hier gefunden sind nicht genau Baugleich aber ähnlich: http://www.e30tuner.com/assist/m17re/Sch_Rev8Jan2018.pdf Gruß JB
Jens schrieb: > es handelt sich um eine Bosch Motronic M1.7.2. Da werkelt ein 80C515, AFAIR. Auch der ist natürlich kundenspezifisch bedruckt, so wie das bei Bosch völlig üblich ist.
Angehängte Dateien:
-
20210421_182305_HDR.jpg
240 KB
Hallo LDR, ja, da hast du recht analog der spezifischen B58115 für den SRAM. Bild anbei.
Beitrag #7319951 wurde von einem Moderator gelöscht.
Myclass schrieb im Beitrag #7319865:
> 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) :-)
Beitrag #7320014 wurde von einem Moderator gelöscht.
Nils schrieb: > 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. Ehr eine Bastelei aus den '80ern.
Angehängte Dateien:
-
Bosch.jpg
92 KB
Jens schrieb: > Hallo LDR, > > ja, da hast du recht analog der spezifischen B58115 für den SRAM. > > Bild anbei. Mit Kennzeichnung zurück.
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.
Angehängte Dateien:
-
rpm.PNG
190 KB -
IGN_INJ.PNG
18 KB
Hallo Georg, 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. Gruß JB
TempusAnus schrieb: > Über OBD geht nicht? Wohl eher nicht: Jens schrieb: > 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.
32kb MCS51 dissambler ist zwar nicht gerade das worauf man ernsthaft Bock haben sollte, aber immerhin machbar wenn einem das Problem wichtig genug ist. Olaf
Beitrag #7320185 wurde von einem Moderator gelöscht.
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. Gruß JB
Jens schrieb: > 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.
:
Bearbeitet durch User
Jens schrieb: > Ich habe > eine technische Frage. Nämlich wie man einen SRAM auslesen kann der in > Benutzung ist... Und die einzi richtige Antwort: "geht nicht" akzeptierst du nicht?! -- Das einzige was geht, wäre eine Aufzeichnung des Verkehrs am RAMBusses und daraus Rekonstruktion des Speicherinhaltes.
Thorn in your side schrieb: > 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.
Wolfgang R. schrieb: > Thorn in your side schrieb: >> 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.
Beitrag #7320227 wurde vom Autor gelöscht.
Ich weiß jetzt nicht, welche Große der TO braucht, aber was ist an einem IDT 7132 auszusetzen? Das RAM läuft völlig asynchron...
Wolfgang R. schrieb: > aber was ist an einem > IDT 7132 auszusetzen? Wenn, dann doch gleich der große Bruder 7005, der passt mit 8kx8 besser zum 6264. Mit einfachen Registern könnte man allerdings sogar per LEDs den Speicher im Auge behalten...
Wolfgang R. schrieb: > 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. Jens schrieb: > 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. Machbar, aber Riesenaufwand für was??
Abdul K. schrieb: > Vermutlich wird die serielle > Schnittstelle noch gar nicht benutzt. Doch, mindestens seit der Motronic 1.3, und eben für die Diagnose.
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. viel spass
:
Bearbeitet durch User
Wolfgang R. schrieb: > 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. Ähnlich wie bei Cache: https://en.wikipedia.org/wiki/Cache_coherence -- 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.
LDR schrieb: > Wenn, dann doch gleich der große Bruder 7005, der passt mit 8kx8 besser > zum 6264. Stückpreis 45€, Lieferzeit 36 Wochen ...
> Stückpreis 45€, Lieferzeit 36 Wochen ... Ich sag doch, die Teile sind etwas exotisch. 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.... Olaf
Angehängte Dateien:
-
Info.PNG
4,2 KB
Hallo Horst, 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. Gruß JB
Interessant :-P 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 ) mfg
Angehängte Dateien:
-
DIS.PNG
15 KB
Hallo Olaf, 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. Gruß JB
olaf schrieb: >> Stückpreis 45€, Lieferzeit 36 Wochen ... > > Ich sag doch, die Teile sind etwas exotisch. 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, ...
Jens meinte: > 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. mfg
Thorn in your side schrieb: > Beispielsweise Lattice iCE40UP5K: sofort ab > Mouser-Lager, 10€ hätte dann 15kByte. Und Oscillator on board, ... Dann mach das doch dem TE, ist ja bestimmt übermorgen fertig.
Jens schrieb: > 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. https://de.euronews.com/video/2016/10/10/nordamerikanische-meisterschaft-im-ehefrauen-huckepack
Beitrag #7320472 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
DIS2.PNG
18 KB
Hallo Lotta, 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. Gruß JB
Beitrag #7320490 wurde von einem Moderator gelöscht.
Jens meinte: > Ich weiß nicht was eine > Interrupt-Tabelle ist. 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... mfg
M.M.M schrieb: > 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.
Lotta . schrieb: > 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.
Markus F. schrieb: > M.M.M schrieb: >> 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. cycle stealing: https://en.wikipedia.org/wiki/Cycle_stealing 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). Jahre später nannte man sowas UMA (Unified Memory architecture): https://en.wikipedia.org/wiki/Shared_memory
Hallo Lotta, 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.. Gruß JB
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! mfg
Georg G. schrieb: > 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. Georg
Angehängte Dateien:
-
Lambda.PNG
130 KB
Hallo Georg, 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? Ich betreibe Motorsport als Hobby ja. Gruß JB
Jens meinte:
> Ich betreibe Motorsport als Hobby ja.
Ts... :-P
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?
mfg
:
Bearbeitet durch User
Hallo Lotta, kannst mich gerne separat kontaktieren. Von meiner ursprünglichen Thema im Titel sind wir ja mittlerweile weit weg :-D Gruß JB
schon mal da reingeschaut? https://www.mikrocontroller.net/attachment/3024/super.pdf 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.
:
Bearbeitet durch User
Horst S. schrieb: > angesprochen. Der Anschluß EA (external access) informiert den > Microcontroller darüber, ob er Falls er das kann, wäre noch zu klären, ob das zeitlich zum Programm passt, da externe Aufrufe oft etwas mehr Zeit brauchen.
oszi40 schrieb: > Horst S. schrieb: >> angesprochen. Der Anschluß EA (external access) informiert den >> Microcontroller darüber, ob er > > Falls er das kann, wäre noch zu klären, ob das zeitlich zum Programm > passt, da externe Aufrufe oft etwas mehr Zeit brauchen. Der 80C515 kann es eh nicht.
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.
Thomas Z. schrieb: > 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.
Angehängte Dateien:
-
BIN_L.png
25 KB
Jens schrieb: > 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,...) Die Code/Tabellen-Bereiche "sieht" man übrigens, wenn man die Firmware in ein Bild konvertiert (https://github.com/ncarkaci/binary-to-image) Siehe Anhang. Gruß Roland
Thorn in your side schrieb: >> Oder eben die Spiegelung in ein geeignetes RAM > 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. Horst S. schrieb: > 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. Roland P. schrieb: > 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. Jens schrieb: > 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!
:
Bearbeitet durch Moderator
Drago S. schrieb: > Wurde schon Buspirate erwähnt? 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 mfg
Drago S. schrieb: > Wurde schon Buspirate erwähnt? 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"
Ein absolut geiler Thread!!! @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? mfg
@ 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. Gruß JB
:
Bearbeitet durch User
Jens meinte: > Was ich zur Messung genutzt habe ist das: > https://www.dataq.com/products/di-1110/ > Als Signalgenerator einen JDS6600. Du kannst mich ja ignorieren :-P oder-- Du kannst Dir mal den EA-Pin des Prozessors ansehen, beim Booten des Steuergerätes: Ist er dauern auf "H" Ist er dauernd auf "L" Ist er kurz auf "H" wechselt dann zu "L" Wechselt er in unregelmäßigen Abständen zw. "H" und "L"? mfg
Lotta . schrieb: > 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.
Lotta . schrieb: > 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)
Hallo Lotta, 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? Gruß JB
Jens schrieb: > 0x2000 bis 0x7FFF EPROM > 0x0000 bis 0x1FFF EPROM 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. (*) https://www.infineon.com/dgdl/Infineon-D80515A-DS-v08_95-en.pdf?fileId=db3a304412b407950112b41a498e2a21
Hallo Thomas, 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. Gruß Jens
:
Bearbeitet durch User
Beitrag #7321379 wurde vom Autor gelöscht.
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. mfg
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).
:
Bearbeitet durch User
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? mfg
Hallo Lotta, 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 Viele Grüße, JB
:
Bearbeitet durch User
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................
Horst S. schrieb: > wenn ich mich recht entsinne wurden die amd-rechner des 80515 nicht > lange bei bosch verbaut. hauptlieferant wurde da recht schnell siemens > (infinion). AMD war 2nd Source, mit den Masken von Siemens.
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.
:
Bearbeitet durch User
Hallo Horst, natürlich MSG^^ Da war ein Dreher drin. 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.
@ Horst: http://www.e30tuner.com/assist/m17re/Sch_Rev8Jan2018.pdf 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.
Jens schrieb: > 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.
bezieht sich den anhang auf die klopfsignale? 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.......
Horst S. schrieb: > 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. mfg
Hallo Georg, hallo Horst, danke für eure Infos. @ 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. Gruß JB
:
Bearbeitet durch User
Hurraaaa! Es geht hoffentlich anständig weiter! @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? mfg
Jens schrieb: > 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.
Georg G. schrieb: > Jens schrieb: >> 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!! mfg
Jens schrieb: > 02 00 73 02 20 00 FF FF FF FF FF 02 20 10 FF FF wenn das wirklich so ist: Das ist die Interrupt Vector Tabelle
1 | 0x0000: LJMP 0x0073 ;Reset |
2 | 0x0003: LJMP 0x2000 ;ext IRQ |
3 | .... |
4 | 0x000B: LJMP 0x2010 ;Timer 0 IRQ |
Lotta . schrieb: > Das Psen Signal. 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 G. schrieb: > Lotta . schrieb: >> Das Psen Signal. > > 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.. mfg
:
Bearbeitet durch User
Jens schrieb: > 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?
Thomas Z. schrieb: > Kannst du die kompletten 8k des ROMs hier einstellen? Das wäre geil, wenn beim Proggen der Ausleseschutz "vergessen" worden wäre... :-P mfg
Hallo Georg, 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! :-) Gruß JB
:
Bearbeitet durch User
Jens meinte: > Hallo Georg, > 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!! Meine Hochachtung gilt allen Beteiligten! Mercy.
:
Bearbeitet durch User
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.
Horst S. schrieb: > 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
Beim 80C515 kommt es bzgl Ausleseschutz auf die Version an.
Thomas Z. schrieb: > Horst S. schrieb: >> 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. Naja, war ja nur ne idee von mir... mfg
> 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?
Horst S. schrieb: > hmm..... wie lese ich dann daten aus dem internen rom wenn der movc > nicht geht? https://www.infineon.com/dgdl/Infineon-D80515A-DS-v08_95-en.pdf?fileId=db3a304412b407950112b41a498e2a21 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
Thomas Z. schrieb: > Sowas ist auf fast allen MCS51 Controllern mit internem Code Speicher > als Schutz eingebaut. Egal ob Mask Rom Eprom oder Flash Außer der ersten Generation.
Hmm. Dann meint Ihr wirklich, das wir keine Chance haben? :-O :-((( mfg
:
Bearbeitet durch User
Georg und alle Anderen: Ich hab nun mal IDA angeworfen. Jens "Auslesung" > Jens schrieb: > 02 00 73 02 20 00 FF FF FF FF FF 02 20 10 FF FF > 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? mfg
Hallo zusammen, 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. Viele Grüße, JB
Jens schrieb: > 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.
genau, Jens, häng bitte das Bin ran, damit ich IDA einsetzen kann. Mercy
Bitteschön. Ich bitte euch dann um Info :-)
Thomas meinte: > 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? mfg
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. :-(( mfg
Lotta . schrieb: > 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.
Hallo Lotta, 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 deine Unterstützung und Interesse. Gruß JB
Hallo Thomas, 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? Danke und Gruß, JB
Jens schrieb: > 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.
Das weiss ich inzwischen... :-O Pff.. ich hatte nich das alte Projekt drinne :-((( ich mache ein neues! es braucht sich keiner zu entschuldigen,da war ich schluderig. bitte Jens machst Du bitte ein Protokoll, ie du das Ganze ausgelesen hast? Damit wir Anderen auch lernen können? mfg
Keil und auch IAR C51 war ab ca. 1985 verfügbar. Ich selbst habe um 1988 mit einer gecrackten Keil V3.?? erste Gehversuche unternommen. Hier mal eine Beispiel Funktion. Da stören mich lediglich die ACALLs / AJMPs
1 | code:0400 code_400: ; CODE XREF: code_E6A+2p |
2 | code:0400 ; code_E6A:code_E8Ep ... |
3 | code:0400 push PSW ; Program Status Word Register |
4 | code:0402 push B ; B-Register |
5 | code:0404 push DPH ; Data Pointer, High Byte |
6 | code:0406 push DPL ; Data Pointer, Low Byte |
7 | code:0408 mov DPH, RAM_75 ; Data Pointer, High Byte |
8 | code:040B mov DPL, RAM_76 ; Data Pointer, Low Byte |
9 | code:040E mov A, R2 |
10 | code:040F inc R2 |
11 | code:0410 setb RS0 ; Program Status Word Register |
12 | code:0412 movc A, @A+DPTR |
13 | code:0413 cjne A, #0xFF, code_41A |
14 | code:0416 setb RAM_29.3 |
15 | code:0418 ajmp code_45F |
16 | code:041A ; --------------------------------------------------------------------------- |
17 | code:041A |
18 | code:041A code_41A: ; CODE XREF: code_400+13j |
19 | code:041A clr RAM_29.3 |
20 | code:041C mov C, ACC0 ; Accumulator |
21 | code:041E clr ACC0 ; Accumulator |
22 | code:0420 mov DPH, RAM_73 ; Data Pointer, High Byte |
23 | code:0423 mov DPL, RAM_74 ; Data Pointer, Low Byte |
24 | code:0426 mov R7, A |
25 | code:0427 inc R7 |
26 | code:0428 movc A, @A+DPTR |
27 | code:0429 xch A, R7 |
28 | code:042A movc A, @A+DPTR |
29 | code:042B mov DPL, A ; Data Pointer, Low Byte |
30 | code:042D mov DPH, R7 ; Data Pointer, High Byte |
31 | code:042F jc code_437 |
32 | code:0431 acall code_46A |
33 | code:0433 acall code_493 |
34 | code:0435 ajmp code_45F |
35 | code:0437 ; --------------------------------------------------------------------------- |
36 | code:0437 |
37 | code:0437 code_437: ; CODE XREF: code_400+2Fj |
38 | code:0437 acall code_46A |
39 | code:0439 mov B, R1 ; B-Register |
40 | code:043B mov A, R0 |
41 | code:043C mov R6, A |
42 | code:043D mov A, R3 |
43 | code:043E mov R7, A |
44 | code:043F acall code_46A |
45 | code:0441 mov A, R2 |
46 | code:0442 mul AB |
47 | code:0443 add A, R1 |
48 | code:0444 mov R1, A |
49 | code:0445 mov A, R7 |
50 | code:0446 jz code_44A |
51 | code:0448 acall code_493 |
52 | code:044A |
53 | code:044A code_44A: ; CODE XREF: code_400+46j |
54 | code:044A xch A, R2 |
55 | code:044B cpl A |
56 | code:044C inc A |
57 | code:044D add A, R1 |
58 | code:044E mov R1, A |
59 | code:044F acall code_493 |
60 | code:0451 xch A, R7 |
61 | code:0452 jnz code_457 |
62 | code:0454 xch A, R7 |
63 | code:0455 ajmp code_45F |
64 | code:0457 ; --------------------------------------------------------------------------- |
65 | code:0457 |
66 | code:0457 code_457: ; CODE XREF: code_400+52j |
67 | code:0457 mov R3, A |
68 | code:0458 mov B, R6 ; B-Register |
69 | code:045A xch A, R7 |
70 | code:045B mov R5, A |
71 | code:045C mov A, R2 |
72 | code:045D acall code_4A2 |
73 | code:045F |
74 | code:045F code_45F: ; CODE XREF: code_400+18j |
75 | code:045F ; code_400+35j ... |
76 | code:045F clr RS0 ; Program Status Word Register |
77 | code:0461 pop DPL ; Data Pointer, Low Byte |
78 | code:0463 pop DPH ; Data Pointer, High Byte |
79 | code:0465 pop B ; B-Register |
80 | code:0467 pop PSW ; Program Status Word Register |
81 | code:0469 ret |
82 | code:0469 ; End of function code_400 |
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?
:
Bearbeitet durch User
Angehängte Dateien:
Hallo Horst, danke für die Tipps und Hinweise. 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? Viele Grüße, JB
:
Bearbeitet durch User
Ich hab heut Vormittag mal mit Jens' seinem Disassembler rumgespielt, geil, und gar nicht so schlecht, siehe Anhang gestartet mit "d52 -dbt Motorsteuerung.bin" ohne die Anführungsstrichelchen, natürlich :-) mfg
:
Bearbeitet durch User
Jens schrieb: > Auf meinem 80c515 ist 1984 aufgedruckt 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
Beitrag #7324567 wurde vom Autor gelöscht.
Hallo Lotta, hallo Thomas, danke für eure Hinweise. 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 Gruß JB
Jens schrieb: > Im sram weiß ich wo diese konkret stehen. Wie diese dahin kommen oder > mit welchen Funktionen errechnet werden nicht. Gewöhnlich gelangen die Werte über einen Schreibzugriff ins SRAM. Da muss man nur bei Adresse und Daten zuhören.
Jens schrieb: > 0x2000 bis 0x7FFF = 0x2000 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 |
15 | code:0B38 sjmp code_B3D |
16 | code:0B3A ; --------------------------------------------------------------------------- |
17 | code:0B3A |
18 | code:0B3A code_B3A: ; CODE XREF: code_920+212j |
19 | code:0B3A mov SCON, #1101000b ; Serial Channel Control Register |
20 | code:0B3D |
21 | code:0B3D code_B3D: ; CODE XREF: code_920+218j |
22 | code:0B3D mov SBUF, RAM_35 ; Serial Channel Buffer Register |
23 | code:0B40 setb ES ; Interrupt Enable Register 0 |
24 | code:0B42 |
25 | code:0B42 code_B42: ; CODE XREF: code_920+20Aj |
26 | code:0B42 pop DPL ; Data Pointer, Low Byte |
27 | code:0B44 pop DPH ; Data Pointer, High Byte |
28 | code:0B46 pop RAM_5 |
29 | code:0B48 pop RAM_0 |
30 | code:0B4A ret |
31 | code:0B4A ; END OF FUNCTION CHUNK FOR code_920 |
hier die zwei Kopierfunktionen
1 | code:067C _pcopy_To_R0: ; CODE XREF: code_920+207p |
2 | code:067C ; code:1904p ... |
3 | code:067C mov P2, #0 ; Port 2 |
4 | code:067F |
5 | code:067F code_67F: ; CODE XREF: _pcopy_To_R0+7j |
6 | code:067F ; code:19E5p ... |
7 | code:067F mov A, @R1 |
8 | code:0680 movx @R0, A |
9 | code:0681 inc R0 |
10 | code:0682 inc R1 |
11 | code:0683 djnz R5, code_67F |
12 | code:0685 ret |
13 | code:0685 ; End of function _pcopy_To_R0 |
14 | code:0685 |
15 | code:0686 |
16 | code:0686 ; =============== S U B R O U T I N E ======================================= |
17 | code:0686 |
18 | code:0686 |
19 | code:0686 _pcopy_To_R1: ; CODE XREF: code_14BF+27p |
20 | code:0686 ; code_14BF+3Dp ... |
21 | code:0686 mov P2, #0 ; Port 2 |
22 | code:0689 |
23 | code:0689 code_689: ; CODE XREF: _pcopy_To_R1+7j |
24 | code:0689 ; code:191Ap ... |
25 | code:0689 movx A, @R0 |
26 | code:068A mov @R1, A |
27 | code:068B inc R0 |
28 | code:068C inc R1 |
29 | code:068D djnz R5, code_689 |
30 | code:068F ret |
31 | code:068F ; End of function _pcopy_To_R1 |
wird doch langsam :-) 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.
Hallo zusammen, @ 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 :-) Danke für die Tipps. Gruß JB
:
Bearbeitet durch User
Jens schrieb: > Für eine saubere Frequenzanalyse 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.
Hallo Georg, 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? Viele Grüße JB
:
Bearbeitet durch User
Jens schrieb: > 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.
Jens meinte: > @ 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. mfg
:
Bearbeitet durch User
Hallo Thomas, 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. Danke und Gruß, JB
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. mfg
:
Bearbeitet durch User
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.
Dann mal der Reihe nach: Jens schrieb: > Welche "spezielle Deckel" meintest du denn? 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.
Thomas Z. schrieb: > 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? mfg
Lotta . schrieb: > 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
Thomas Z. schrieb: > 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? RESPEKT!! mfg
Georg der Große meinte: > 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? mfg
1 | Adr Raum | CPU ROM | Eprom | |
2 | ---------+----------+---------+ |
3 | 0xFFFF | | 0x7FFF | |
4 | | | | |
5 | 0xE000 | | Eprom | |
6 | | | spiegel | |
7 | 0xC000 | invalid | | |
8 | | | | |
9 | 0xA000 | | | |
10 | | | 0x0000 | |
11 | 0x8000 | +---------+ |
12 | | | 0x7FFF | |
13 | 0x6000 | | Eprom | |
14 | | | valid | |
15 | 0x4000 | | | |
16 | | | 0x2000 | |
17 | 0x2000 +----------+---------+ |
18 | | ROM | invalid | |
19 | 0x0000 | | 0x0000 | |
20 | ---------+----------+---------+ |
1. Eprom code verdoppeln 2. die ersten 8k des Eprom codes wegschneiden 3. Rom Code + Epromcode 4. 0x000 - 0x9FFF speichern 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.
Lotta . schrieb: > Hast Du solchen Deckel mal gesehen? 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.
Georg G. schrieb: > 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. Hey! ich zitiere mal Herrn Mielke: :-P Ich liebe euch alle!! :-))))))))))) mfg
@Jens und Georg: 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? mfg
Lotta . schrieb: > EEPROM oder gepufferter RAM für den Tachostand Der Wegstreckenzähler lebt im Kombiinstrument in einem EEPROM. In modernen Fahrzeugen hat er Zweit- und Drittwohnsitze in anderen Steuergeräten.
Georg G. schrieb: > Lotta . schrieb: >> EEPROM oder gepufferter RAM für den Tachostand > > Der Wegstreckenzähler lebt im Kombiinstrument in einem EEPROM. In > modernen Fahrzeugen hat er Zweit- und Drittwohnsitze in anderen > Steuergeräten. @Georg: Nicht schlecht... :-P In diesem also nicht? :-P @Jens: Wie ließt Du die Daten aus? Über OBD? Mit "Delphi" ( was ja "Orakel" bedeutet ) oder über nen "offline looking system?" Mein Respekt gilt allen Beteiligten! mfg
Moin Jens, mein email Account ist "repariert" und Du hast ne Mail. mfg
Georg, bitte kannst du helfen? Ist ein Motorsteuergerät voll funktionstüchtig, auch wenn ein Testprogramm die K-Leitung angereizt hat, oder gibts da Perfomanceprobleme? Hey, Du bist der beste!:-D mfg
Hallo zusammen, 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? Viele Grüße JB
:
Bearbeitet durch User
Jens meinte: > @ 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. mfg
Jens schrieb: > mein Name ist Jens Lotta . schrieb: > Es ist zum Kotzen... :-O > > Meine mail ist durch nen Spamassin abgelehnt worden.. ist das hier ein Troll oder chatGPT Thread? so langsam glaubt das doch keiner mehr!
Hallo Joachim, 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^^ Was soll keiner keiner genau glauben Joachim? Gruß JB
die ganze Art des Threads erinnert mich irgendwie an chatGPT. https://www.youtube.com/watch?v=jLfDYqHMExc
:
Bearbeitet durch User
Joachim B. schrieb: > die ganze Art des Threads erinnert mich irgendwie an chatGPT. Huch, chatGPT !?! Sowas wirklich altmodisches? LOTTA-KI We make future. mfg
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. Die ETKs wurden (auch) von ETAS gebaut.
moin jens hast du von der klopfsensorplatine ein schaltbild? zur grundsätzlichen funktion könnte ich dann noch was beisteuern.
Hallo Horst, 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. Den Link kann ich mit Mozilla öffnen. Chrome macht das nicht. http://www.e30tuner.com/assist/m17re/Sch_Rev8Jan2018.pdf "A250" ? 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? Danke Georg für die Info! Viele Grüße JB
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
Ich hab mit dem Disassembler erst mal nicht weitergemacht und zwar aus folgenden Gründen: 1. ohne validierte Portbelegung ist die Bedeutung nicht nachvollziehbar 2. Im Schaltbild sind die Labels nahezu unlesbar 3. es ist unklar welche MCU Variante im Einsatz ist (A?) 4. Im Code wird das SRAM fast nur im paged Mode angesprochen MOVX A,@R0/R1 Das macht es schwierig die RAM Belegung zu ermitteln 5. ab 0xA000 liegt das ASIC was dort passiert ist unbekannt 6. Ich hab nicht wirklich eine Ahnung von Steuergeräten und den Begriffen
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? mfg
@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? danke! mfg
Lotta . schrieb: > Wie würdest Du als Extremassembler den Parser der K1- Leitung > implementieren? keine Ahnung von was du da redest. > 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. @Jens - welche Quarzfrequenz wird verwendet 12MHz? - kannst du mal den Pegel an Pin37 messen (Vbb). 0V wäre NMOS (80515) - kannst du mal eine Liste mit SRAM Adressen einstellen die du schon kennst
Thomas Z. schrieb: > Lotta . schrieb: >> 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. mfg
Klaus schrieb: > Lotta . schrieb: >> ich werd das genauer ausarbeiten > > Geschwafel ohne jede Ahnung. 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 mfg
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.