Guten Abend liebe Freunde! Vor mir liegend habe ich ein Bediengerät mit einem 8031 Mikroprozessor und einem guten alten Eprom (27C64) mit der entsprechenden Software. Das Programm hat zur damaligen Zeit mein Vater geschrieben und steuert eine kleine Textübertragung und Relaisschaltungen. Am Bedienpanel befinden sich einige Taster und LED's. Rückseitig ein paar Steuereingänge (Zustandsabfrage). So weit zur Hardware. Leider ist es so, dass es den Quelltext nicht mehr gibt und ich meinen Vater nach diesem auch nicht mehr fragen kann. Das Gerät ist nach wie vor bei uns im Haus in Betrieb und ich möchte gerne den Programmcode, wenn auch bruchstückweise, zurückbekommen bzw. generell mal sehen. Ich habe bei Google schon nach "Decompiler" etc. gesucht, aber mir fehlen dafür natürlich die richtigen Begriffe. Und ob die Möglichkeit so einfach überhaupt besteht, weiß ich auch gar nicht genau. Meine Frage an Euch: - Was mache ich da am besten? Schönen Abend!
Du suchst einen 'Disassembler'. Dieser verwandelt ein BIN oder HEX File, das du aus dem EPROM ausgelesen hast, in ein Assembler Listing. Die Chancen stehen recht gut, das dein Vater damals Assembler benutzt hat, ein Hochsprachen Kompilat wäre wesentlich schwerer zu verstehen. DIS51 ist z.B. ein solches Programm für die MCS51 Familie.
> Und ob die Möglichkeit so einfach überhaupt besteht, weiß ich > auch gar nicht genau. Sowas gibt es nicht. Aber immerhin ist die Wahrscheinlichkeit relativ gross das ein Programm fuer einen MCS51 in Assembler geschrieben wurde. Das koenntest du mit einem Dissassembler zurueckuebersetzen. Also so mehr oder weniger und nur falls du Assembler kannst. :) Olaf
Ich habe jetzt den Disassembler "D52" geladen und meine Binärdatei damit geladen und das Ergenmos im Anhang herausbekommen. Bin ich in die richtige Richtung gegangen? Sieht das "gut" aus? Ich spreche leider nicht Assemblish.
Stefan Müller schrieb: > Ich spreche leider nicht Assemblish. Dann kannst du eigentlich bereits aufhören. Ohne Assemblerkenntnisse kommst du mit dem Listing wirklich nicht klar. Einen Tipp kann ich dir aber geben. Eine leere Speicherstelle im EPROM ist normalerweise auf 0xFF (oder FFh in Intel Syntax) das auch den Befehl 'mov r7,a' in MCS51 Assembler bedeutet, deswegen kommt dieser Befehl im Listing so oft vor. Mit einem symbolischen Dissassembler kanst du nun schrittweise damit anfangen, Speicherzellen und Sprungvektoren Namen zu geben. (z.B. ist X0250 der Resetvektor) Es wäre dann auch möglich, Daten und Programm voneinander zu trennen, dein derzeitiges Listing disassembliert eben auch einfach Texte und andere Konstanten als Maschinencode. Ist aber kompliziert und lohnt sich wirklich nur dann, wenn du unbedingt auf einen vernünftigen Quellcode kommen musst.
Matthias Sch. schrieb: > Einen Tipp kann ich dir aber geben. Eine leere Speicherstelle im EPROM > ist normalerweise auf 0xFF (oder FFh in Intel Syntax) das auch den > Befehl 'mov r7,a' in MCS51 Assembler bedeutet, deswegen kommt dieser > Befehl im Listing so oft vor. Tja, das ist auch so ein Aufläufer, um auf die Nase zu fallen. Ich setzte leere Speicherbereiche immer auf 0x00. 0xFF macht aber beim 8031 auch nicht besonders viel, er macht da immer nur MOV R7,A.
Wilhelm F. schrieb: > Ich setzte leere Speicherbereiche immer auf 0x00. 0xFF macht aber beim > 8031 auch nicht besonders viel, er macht da immer nur MOV R7,A. Bei kritischen EPROMs habe ich damals (hach, ja) in die leeren Stellen massenweise 'nop, nop, nop, ljmp 0000, nop, nop' usw. gebrannt, falls der Controller mal einen Glitch auf den Addressleitungen bekam. Ansonsten habe ich die FFs drin gelassen, damit die nicht unnötig gebrannt wurden. Bei unbekannter Hardware würde ich jetzt vermutlich meinen 8031 Monitor in die Platine stecken, einen MAX an die UART machen und damit anfangen, das Board durchzuklingeln. Wie gesagt, das alles lohnt sich nur bei komplexerem Aufbau und wenn man dringend wissen muss, was da vor sich geht. Wenn die Kiste sehr alt ist (sagen wir mal vor 1990) dann einfach mal in ein frisches EPROM brennen und gut is'.
Stefan Müller schrieb: > Ich spreche leider nicht Assemblish. Was hast du denn dann mit dem Code vor? Wie willst du ihn ändern, wenn du ihn nicht verstehst? Für einen Anfänger ist es suboptimal, mit der Analyse eines Disassemblats zu beginnen. Hast du wenigstens ein komplettes Schaltbild und eine komplette Funktionsbeschreibung?
Okay, belassen wir es bei dem. Schaltbild und Funktionsbeschreibu ng ist nämlich vorhanden und dem nach kann man auch neu programmieren. Ich hatte bloß bedenken, da auch ein UART verwendet wird - wegen dem Datentransfer. Aber dort könnte man ja beispielsweise für Sender und Empfänger neue Firmware programmieren. Eine andere Frage: Im Eprom ist weit unter dem Hauptprogramm (mit großem Leerbereich FF) im unteren Speicherbereich ca. ab 01600 oder auch 001A00 ein kleiner Bereich mit irgendwelchen Nebensächlichkeiten/Konstanten abgelegt - der aber gar nicht zwingend notwendig ist. Wenn ich den Part lösche, gibt es keinerlei Funktionseinschränkung. Leider kenne ich den genauen Adressbereich gerade nicht auswendig, da ich auf die Binärdaten gerade nicht zugreifen kann. --> Kann man aus dem Textfile des Disassemblers zufällig erkennen, ob der Inhalt aus diesem unteren Speicherbereich irgendwo aufgerufen wird - und wenn ja, ob und wie er verarbeitet wird?
Vermutlich wird es einfacher, die gesamte Funktion der Schaltung zu dokumentieren und dieses dann in einem Atmel o.ä. nachzubilden.
Matthias Sch. schrieb: > Wilhelm F. schrieb: >> Ich setzte leere Speicherbereiche immer auf 0x00. 0xFF macht aber beim >> 8031 auch nicht besonders viel, er macht da immer nur MOV R7,A. > > Bei kritischen EPROMs habe ich damals (hach, ja) in die leeren Stellen > massenweise 'nop, nop, nop, ljmp 0000, nop, nop' usw. gebrannt, falls > der Controller mal einen Glitch auf den Addressleitungen bekam. Ich machte auch komische Sachen, nach dem ich Literatur über Störungsmanagement las. Z.B. leere 256Byte-Blöcke mit NOP, und an deren Ende jeweils: CLR A MOV SP, #7 PUSH ACC PUSH ACC RETI ;-) Damit sollte er sich bei einem Absturz in leere Speicherblöcke mit einer gewissen Wahrscheinlichkeit schnell fangen. Das mußte man auch nicht für jeden Block manuell machen, dafür gab es ja den tollen Makro-Assembler.
Im Bereich von 1800 bis 18F6 bzw. mit FF bis 18FF sind im Eprom Daten hinterlegt, die nicht zum Hauptprogramm gehören und wo es keine Rolle spielt, ob sie im Eprom hinterlegt sind oder schlichtweg gar nicht vorhanden sind. Es gibt keine Einbußen im Programm oder sonstige Veränderung. Daher ist meine Frage jetzt dringlich: Was hat es mit dem Part auf sich? Wird dieser Bereich oben im Assembler-Teil angefragt? Vielleicht kann das ja jemand für mich ganz grob und schnell nachforschen.
Ich sehe gerade selbst: Ja, der Bereich wird abgefragt
1 | org 1800h |
Kann mir sagen, ob und welche weitere Verarbeitung stattfindet? Es sieht aus wie ein Bitmuster o. ä., wird aber wie gesagt gar nicht zwingend benötigt und ich finde keinerlei Funktionseinfluss oder Einbuße bei nicht-vorhandenseins. Grüße
hildesheimer schrieb: > Vielleicht kann das ja jemand für mich ganz grob und schnell > nachforschen. Das kann niemand. Du musst schon das gesamte Programm soweit sinnvoll zerlegen, dass es sich 1:1 wieder assemblieren lässt. Woher willst du sonst wissen, ob nicht in den 100 von dir als unwichtig eingestuften Bytes doch was wichtiges abgelegt ist. Das ist erst einmal Fleißarbeit. Das Hirnschmalz brauchst du, wenn du den Mnemonic Folgen dann Funktionen zuordnest.
Die 100 unwichtigen Bytes habe ich bereits im Eprom mit FF überschrieben gehabt und testweise gebrannt. Daher kann ich das sagen - das es eben keinen sichtbaren Einfluss unter Test aller Funktionen gibt. Anbei die BIN. Hier meine bekannten Bereiche: Bereich 100 - 2FF = Bitmuster ASCII Zeichensatz Bereich 500 - 6FF = Bitmuster ASCII Zeichensatz (andere Darstellform) Bereich 800 - 1040 = Hauptprogramm Bereich 1800 - 18F6 = Kurioser unwichtiger Teil (?)
Die Bitmuster der Zeichensätze habe ich bereits erfolgreich entschlüsseln können. Dort gibt es keinen Fragebedarf. Das Hauptprogramm selbst könnte ich problemlos neu programmieren. Es geht jetzt nur noch um den letzten Part, was dieser bezwecken soll. Kurios finde ich eben, das dieser nicht zwingend benötigt wird.
ich habe mal etwas in den Code etwas angeschaut. Alles in allem ist der Code etwas seltsam. Es fehlt z.B die Stackpointer Inititialisierung. Das bedeutet der Stack steht auf 0x07. Dahinter kommt der Variablenbereich Zusätzlich finden sich im Code diverse Stackmanipulationen (Parameter für Funktionen). Was ich sagen kann ist, dass dies in keinem Fall in C geschrieben ist dann würde man den Startupcode finden. Assembler würde ich bei der Struktur auch ausschliesen. Der Code sieht etwas nach diesem unseligen Elektor Pascal aus (Nili Pascal) aus. Ein Assembler Programmierer würde den Code besser strukturieren. Niemand würde z.B im Interrupt ohne Grund Funktionen aufrufen. Ein kleines Beispiel was ein Assem Proger nie machen würde: mov a,scon anl a,#1 jz xxxx in Assembler würde man das so machen: JNB RI,xxx mit einem vernüftigen Disassembler würde man vermutlich bessere Ergebnisse erzielen. Thomas
Was ich soweit sagen kann: Die Programmierung stammt aus der Zeit um 1985 - 1990
So, ich habe auch mal einen kurzen Blick ins Disassembly geworfen. Timer 0 und serielle Schnittstelle werden mit Interrupt benutzt. Der Timer läuft anscheinend im 16-bit-Mode, weil er mit 25000 nach geladen wird. Bei 12MHz wäre das ein Interrupt alle 25ms. Daß der Stackpointer auf 7 steht, macht aber nichts, wenn ein Programm die Registerbänke nicht verwendet, und dieser Platz aus reicht. Der Flagbereich ab 20h wird verwendet. Dann hat der Stack immerhin 24 Byte Platz. Beim Programmstart wird ein Wert aus dem Akkumulator geholt, der da irgend wie hinein gekommen sein muß. Daraus wird dann ein Sprung über den DPTR erzeugt. Vielleicht ein Monitorprogramm? Ja, das sieht schon seltsam aus, NiliPascal könnte es durchaus gewesen sein. Dann könnte das Programm etwa um den Zeitraum 1995 herum erstellt worden sein. Erschwingliche C-Compiler gabs fürs Hobby noch nicht, deswegen brasselte ich auch mal eine Weile mit dem NiliPascal herum. Andererseits lese ich gerade 1985-1990. Was gab es denn da für Compiler für 8031? Aber man sieht mal, wie ein Fremder mit unkommentiertem Code umgehen muß. Das ist noch ein schönes Stück Arbeit, die ganze Funktionalität zu entschlüsseln. Man wird wohl irgendwo im Disassembly beginnen müssen, und nach und nach die Funktionsteile entschlüsseln, und mit Kommentaren versehen, Liste mit Register- und Speicherbenutzung machen, usw. usf..
Folgendes kann ich mal erklären: - Prozessor ist mit 6 Mhz Quarz getaktet. - Serielle Schnittstelle ist aktiv, auf 1200 Baud > ein 75138 steuert RX+TX mit Hilfe von Pin 4 des 8031 - AD-0 bis AD-7 sind durchläufig an die Registereingänge und Ausgänge mehrerer Flip-Flops und Latches zusätzlich natürlich auch am Eprom. > Die Ein-/Ausgangsregister steuern 8 Taster und - A8 bis A12 geht ebenfalls an das Eprom - P1-0 bis P1-2 funktionieren über ein 74HC02 als Steuerleitungen für die Schieberegister als Output enable und Clock. Wenn mir jemand verraten kann, ob der untere Block ab 1800 eingebunden ist und was er tut - reicht mir das jetzt.
Der Controller wertet stetig den seriellen Eingang aus auf Funktionskontrolle des Bediengerätes (Statusrückmeldung) und schaltet ggf. das Gerät ab.
Bzgl. des Compilers kann ich sagen: Mein Vater arbeitete zur damaligen Zeit als Programmierer und Entwickler in einer Elektronikfirma, welche Messgeräte hergestellt hat. Ich schätze ganz stark, das von dort aus auch Kleinigkeiten wie das Compilen des privaten Projektes gemacht wurden.
Letzer Versuch/Aufruf: Wer sagt mir, ob und wie das unbekannte Bitmuster im Bereich 1800 - 18F6 verwendet wird? Es besteht einfach nicht mehr die Möglichkeit, meinen Vater zu fragen. Es wäre total toll, wenn sich dort mal jemand reinhängen könnte. Wenn jetzt aber keiner möchte oder kann, ist aber auch in Ordnung. Ich verstehe den Aufwand. Grüße
hildesheimer schrieb: > Es wäre total toll, wenn sich dort mal jemand reinhängen könnte. Warum nicht selbst machen? Die Infos, die du brauchst, um das Programm zu verstehen, sind zu genüge im Netz zu finden. Warum ist dir der Inhalt so wichtig, wenn das Ding scheinbar auch ohne funktioniert? Hängt Leib und Leben (Herzschrittmacher deines Vaters?) daran? Oder ist dir die Info so viel Wert, dass du gar ordentlich dafür bezahlen würdest?
Peter Pan schrieb: > Oder ist dir die Info so viel Wert, > dass du gar ordentlich dafür bezahlen würdest? Die letzten Hilites hier in den Foren waren ein Kasten Bier für Softwareänderung und 15 Euro für ein Layout, oder so ähnlich, das ist der übliche Rahmen. Kein Anreiz sich "reinzuhängen", so ein Reengeneering kann viele Stunden kosten. Gruss Reinhard
hildesheimer schrieb: > Letzer Versuch/Aufruf: > > Wer sagt mir, ob und wie das unbekannte Bitmuster im Bereich 1800 - 18F6 > verwendet wird? Nein, das sind keine Bitmuster, sondern sieht aus wie wichtige Funktionen. Es gilt jetzt nur, mal anderswo im Programm zu suchen, von wo aus dieser Bereich angesprungen wird. Wenn die Adressen für die Sprünge im RAM liegen, oder sonst wo her wie z.B. serielle Schnittstelle, sieht man sie so direkt nicht, als wenn Konstanten geladen würden. Bspw. war das beim EMON51 so, ein Monitorprogramm. Man gab die Startadresse an der PC-Tastatur ein, und drückte ENTER. Schön wäre es gewesen, wenn irgend wo im Programm die folgende Befehlssequenz auftauchte:
1 | MOV DPTR, #1800h |
2 | JMP @DPTR+A |
Im Grunde muß man sich da mal eine Tabelle mit sämtlichen verwendeten Registern machen, und den Programmablauf mit Bleistift und Papier Schritt für Schritt von Hand abzugehen. Das kann wirklich tagelange mühsame Arbeit sein. Parallel dazu beschriftet man den Code nach und nach mit Kommentaren, oder benennt Register und Sprungadressen mit sinnvolleren Namen, alles, was man so heraus findet. Ein Simulator könnte auch noch wertvoll sein, um die Handarbeit zu umgehen, die auch fehlerträchtig sein kann. Aber sei froh, daß es "nur" 8051-Code ist, das ist noch einer der leichtesten, schönsten, übersichtlichsten.
Stefan Müller schrieb: > Okay, belassen wir es bei dem. Schaltbild und Funktionsbeschreibu ng ist > nämlich vorhanden und dem nach kann man auch neu programmieren. Ich > hatte bloß bedenken, da auch ein UART verwendet wird - wegen dem > Datentransfer. Aber dort könnte man ja beispielsweise für Sender und > Empfänger neue Firmware programmieren. Hier liegt das Problem! Ansonsten hätte ich gesagt, Wilhelm mach das. Aber wer und warum sollte da was neues programmieren? "Sender u.Empfänger"? Das ist dann nicht mehr umsonst. Bei kleinen AVR hab ich das auch schon gemacht. Den Re-Assembler Ausdruck dann mit Farbstiften bearbeitet. Sprünge engesetzt, Marken und Datenbereiche definiert usw. Such auch mal nach Reassembler. Aber die Logik in einem Programm mußt du dir schon selbst erarbeiten.
Thomas schrieb: > Ein kleines Beispiel was ein Assem Proger nie machen würde: > > mov a,scon > anl a,#1 > jz xxxx > > in Assembler würde man das so machen: > JNB RI,xxx Es befinden sich in dem Code so einige Merkwürdigkeiten, die ich allerdings ehr einem schlechten Programmierer, als einem Hochsprachencompiler zutrauen würde. Es ist eigentlich schon zum scheitern verurteilt, wenn ein ASM-Noob daher kommt und versucht diesen Code zu verstehen. > mit einem vernüftigen Disassembler würde man vermutlich bessere > Ergebnisse erzielen. Nein, das ist schon das, was geschrieben wurde. Ich kann mir nicht vorstellen, dass irgendjemand einen Disassembler schreibt, der so abgefahrene Dinge einfügt. Gruß Jobst
Ich bin ja schon beeindruckt, wie viele Möglichkeiten es gibt, um das LSB in einem Byte zu testen und danach zu verzweigen. Abgefahren, diese alle in einem Programm unterzubringen. Ich versuche immer bei einer Möglichkeit zu bleiben, da dies den Code einfacher macht. Mein bisheriger Lieblingsteil ist aber dieser:
1 | xch a,r0 ; A <-> R0 austauschen (was ist in R0?) |
2 | mov a,@r0 ; hole Byte aus Speicherstelle in R0 ((42h)+(43h)) in den Akku (und überschreibe das unbekannte R0 .. *facepalm*) |
Sowas macht man doch nur, um einen Codeleser zu verwirren - oder? Gruß Jobst
Jobst M. schrieb: > Sowas macht man doch nur, um einen Codeleser zu verwirren Nö, gängiger Code für indiziert laden. Der Kommentar ist aber Murks. Stammt der von dir oder war das Original so?
Georg G. schrieb: > Nö, gängiger Code für indiziert laden. Es geht um die Zeile darüber. Ein MOV wäre hier klarer gewesen. > Der Kommentar ist aber Murks. Stammt der von dir oder war das Original so? Der Kommentar ist von mir. Hättest Du Dir hier alles durchgelesen, wüsstest Du das. Und warum der Murks ist musst Du mir jetzt mal erklären. Vielleicht solltest Du Dich aber vorher mit dem Programm auseinander setzen. Gruß Jobst
D. V. schrieb: > Vielleicht hilfts? PRESS KEYPAD "+" TO EXPAND und jnb ACC.3, code_845 ; Accumulator sowie code_82A: ; CODE XREF: code_7FA+CEj ; code_7FA+392j sind wirklich keine Hilfe ... Gruß Jobst
Jobst M. schrieb: > um das LSB in einem Byte... Ein Byte hat kein LSB oder MSB. Ein Byte ist ein Byte. Du verwechselst das mit Word. > xch a,r0 ; A <-> R0 austauschen (was ist in R0?) Ob MOV oder XCH, die Wirkung ist die gleiche. Der X51 hat nur zwei Indexregister, R0 und R1. Also nimmt man die selten bis nie als permanentes Register für laufend gebrauchte Variable. R0 und R1 sind "Schmierzettel". Was in R0 ist, interessiert hier nicht. > mov a,@r0 ; hole Byte aus Speicherstelle in R0 ((42h)+(43h)) in > den Akku (und überschreibe das unbekannte R0 .. facepalm) Falsch. Es wird das Byte, auf das R0 zeigt (R0 ist ein Byte breit, nix mit 42h und 43h) in den Akku geholt. Die beiden Befehle sind equivalent zu "MOV A, @A", ein Befehl, den X51 nicht kennt, den man aber des öfteren braucht.
:
Bearbeitet durch User
Georg G. schrieb: > Jobst M. schrieb: >> um das LSB in einem Byte... > Ein Byte hat kein LSB oder MSB. Ein Byte ist ein Byte. Du verwechselst > das mit Word. Nein, tue ich nicht. http://de.wikipedia.org/wiki/Bitwertigkeit#LSB >> xch a,r0 ; A <-> R0 austauschen (was ist in R0?) > Ob MOV oder XCH, die Wirkung ist die gleiche. Der X51 hat nur zwei > Indexregister, R0 und R1. Also nimmt man die selten bis nie als > permanentes Register für laufend gebrauchte Variable. R0 und R1 sind > "Schmierzettel". Was in R0 ist, interessiert hier nicht. Ja, schon richtig. Aber wenn zwei Register (A und R0) miteinander getauscht werden, fragt man sich, was nun im Akku steht, wenn man nicht weiß, womit R0 vorher geladen war. >> mov a,@r0 ; hole Byte aus Speicherstelle in R0 ((42h)+(43h)) in >> den Akku (und überschreibe das unbekannte R0 .. facepalm) > > Falsch. Es wird das Byte, auf das R0 zeigt (R0 ist ein Byte breit, nix > mit 42h und 43h) in den Akku geholt. Habe ich nie behauptet, dass es sich um 16-Bit handelt. Ich habe Dir doch gesagt, dass Du Dich bitte mit dem Code auseinander setzen sollst. In R0 steht das Ergebnis der Addition der Werte aus den Speicherstellen 42h und 43h. Aber zum zweiten Mal: Es geht gar nicht so sehr um diese Zeile. > Die beiden Befehle sind equivalent zu "MOV A, @A", ein Befehl, den X51 > nicht kennt, den man aber des öfteren braucht. Ach!? - Das ist mir schon klar. Gruß Jobst
Jobst M. schrieb: > Georg G. schrieb: >> Jobst M. schrieb: >>> um das LSB in einem Byte... >> Ein Byte hat kein LSB oder MSB. Ein Byte ist ein Byte. Du verwechselst >> das mit Word. > > Nein, tue ich nicht. http://de.wikipedia.org/wiki/Bitwertigkeit#LSB Wann wird die Menschheit endlich mal Case-Sensitiv und schreibt das B einfach klein wenn es um Bits geht... Die Sache erinnert mich an einen frühen Versuch von mir, den EPROM eines 8085-Systems mit einem AVR auszulesen. Der Disassembler hat mir auch so komische Sachen wie
1 | mov 27h,a |
2 | mov 28h,a |
3 | mov 29h,a |
4 | mov 70h,a |
5 | mov 45h,a |
6 | mov 42h,a |
7 | mov 43h,a |
8 | mov 41h,a |
9 | mov 46h,a |
10 | mov 56h,a |
11 | mov 4bh,a |
12 | mov 4fh,a |
13 | mov 52h,a |
14 | ;hier geht es noch 53 Zeilen so weiter |
rausgeschmissen. Am Ende hat sich herausgestellt das ich zwei Datenleitungen am EPROM vertauscht hatte. Ich würde vieleicht nochmal überprüfen ob der Speicher richtig ausgelsen wurde (sollte das Auslesen hier ebenfalls auf solch unkonvetionelle Weise erfolgt sein).
Niklas W. schrieb: > Wann wird die Menschheit endlich mal Case-Sensitiv und schreibt das B > einfach klein wenn es um Bits geht... Die Menschheit ist Case-Sensitiv. Bits schreibt man groß ;-) - Du hast es ja auch groß geschrieben. Edit: Wenn ich von dem LSB eines Bytes rede, sollte es allerdings auch klar sein ... Niklas W. schrieb: > Ich würde vieleicht nochmal > überprüfen ob der Speicher richtig ausgelsen wurde Dafür ergibt mir schon zu viel einen Sinn. Auch die von mir angemeckerte Zeile. Gruß Jobst
:
Bearbeitet durch User
Niklas W. schrieb: > Am Ende hat sich herausgestellt das ich zwei > Datenleitungen am EPROM vertauscht hatte. Ich würde vieleicht nochmal > überprüfen ob der Speicher richtig ausgelsen wurde (sollte das Auslesen > hier ebenfalls auf solch unkonvetionelle Weise erfolgt sein). Eprom wurde auf jeden Fall korrekt ausgelesen. Direkt aus der Fassung des Gerätes in die Fassung des Epromer's. Das Eprom wurde auch schon mehrfach kopiert, alles einwandfrei.
Hallo Stefan, das Disassembling via IDA Pro war nur ein erster Versuch meinerseits, dir einen ersten Eindruck vom Listing zu geben. Jobst xy hat das ja eindeutig dokumentiert, danke dafür :-) Wäre es möglich, den Schaltplan zu posten? Ich verfüge über eine virtuelle Simulationsumgebung, in der ich das Verhalten des Codes nachempfinden kann, wenn ich weiß, welche Peripherie an dem 80x1 angeklemmt ist. Weitere Informationen kann ich dir dann via PM zukommen lassen. Falls nicht, erwirb einen china-LA für 10 Öken und vollziehe das Verhalten der "black box" nach, falls du für die Zukunft gewappnet sein möchtest.
:
Bearbeitet durch User
Irgendwie passt für mich das disassemblierte Text-File nicht zum BIN. In der Text-Datei steht am Anfang ljmp X0250, an der Zielmarke steht davor org 250h. Im Bin-File steht (zumindest nach Umwandlung mit bin2hex aus meinem Raisonance Compiler) der Maschinencode 02 08 00, also ein Sprung ljmp nach 0800h... Und vor der Adresse 800 stehen im BIN auch reichlich FFs, an 800 steht 75 81 60, also mov SP, #60h Kann das jemand bestätigen?
:
Bearbeitet durch User
So, hab mal die HEX-Datei durch den Dissassembler von MCU8051IDE laufen lassen. Das Ergebnis passt zumindest zu meiner Vermutung...
:
Bearbeitet durch User
Bernhard Spitzer schrieb: > So, hab mal die HEX-Datei vom Dissassembler von MCU8051IDE laufen > lassen. Das Ergebnis passt zumindest zu meiner Vermutung... Wo laufen lassen? Hast du ein CompuBoard dafür benutzt, oder hast du einen eigenen Simulator geschrieben? Zeig mal dein Ergebnis bitte, worauf du dich beziehst.
Dieses BIN-File weit oben konnte ich aber auch nicht vernünftig lesen. Es wäre nett, wenn der TO das eingelesene EPROM gleich als Hex-File zur Verfügung stellte, damit diesbezüglich auch alle Mißverständnisse ausgeräumt sind. Ein EPROMMER kann in der Regel ein eingelesenes EPROM auch in anderen Formaten als BIN wieder geben, z.B. S1F oder Intel HEX. BIN ist nun wirklich das allerschlechteste Format, diese beiden letzt genannten ASCII-Formate wären erheblich besser.
Nö, ich habe die angehängte Datei mit Bin2Hex aus meinem Compiler umgewandelt und in FLIP geladen. Da war in der HEX-Ansicht in FLIP schon an den ersten 3 Bytes erkennbar, dass irgend was nicht mit dem zuerst geposteten Code übereinstimmt. Auf der Suche nach einem Disassembler kam ich auf den Hinweis, das MCU850IDE bereits einen enthält (habe ich erst kurz installiert). Also dort auf Tools/Disassemble und dann die HEX-Datei disassembliert. Ergebnis hängt ja oben an. Eben habe ich auch nochmal in MCU8051IDE mit Tools/Bin->Hex den selben Vorgang nochmal ausprobiert, selbes Ergebnis: der ljmp geht nach 0800h und dort steht mov SP, #60h EDIT: im Anhang ist jetzt die umgewandelte HEX-Datei
:
Bearbeitet durch User
Wilhelm F. schrieb: > Es wäre nett, wenn der TO das eingelesene EPROM gleich als Hex-File zur > Verfügung stellte Warum? Nichts ist sauberer als ein Binary-File. Die angeschlossene Peripherie ist weiterhin unbekannt.
:
Bearbeitet durch User
Ich habe langsam den Eindruck, als wenn es sich um (mindestens) zwei verschiedene Programme handelt. Der Speicherbereich um 60h ist bei dem 'anderen' Programm der UART Empfangsfifo (oder wie man das nennen möchte) ... Ich kann mir nicht vorstellen, dass sich der Stack darauf bewegen soll ... Gruß Jobst
Bernhard Spitzer schrieb: > EDIT: im Anhang ist jetzt die umgewandelte HEX-Datei OK, die sieht auch einwandfrei aus. D. V. (mazze69) schrieb: Warum? Nichts ist sauberer als ein Binary-File. Im Augenblick habe ich leider keinen Editor installiert, der BIN einwandfrei dar stellt. In Word Pad sieht es jedenfalls wie Mist aus. Werde ich mal nach holen. Meine Frage nach Intel-Hex-Format kam deswegen, weil ich noch einen ollen Disassembler für 8051 irgendwo herum fliegen habe, aus dem Jahr 1991, vom selben Hersteller (Ashling Microsystems), der für Intel selbst im Auftrag auch den ersten 8051-Makroassembler schrieb. Das Ding läuft wiederum nur über das Programm DOSbox, eine virtuelle DOS-Maschine, ist für heutige Maßstäbe nicht so komfortabel, und benötigt als Input eben genau das Intel-Hex-Format, kein BIN.
Jobst M. schrieb: > Ich habe langsam den Eindruck, als wenn es sich um (mindestens) zwei > verschiedene Programme handelt. > > Der Speicherbereich um 60h ist bei dem 'anderen' Programm der UART > Empfangsfifo (oder wie man das nennen möchte) ... Ach Quark habe ich geschrieben ... Der Fifo ist ab 3Ch - das sind 60 dezimal ... Gruß Jobst
hildesheimer schrieb: > Eprom wurde auf jeden Fall korrekt ausgelesen. Direkt aus der Fassung > des Gerätes in die Fassung des Epromer's. Das Eprom wurde auch schon > mehrfach kopiert, alles einwandfrei. Sicher, dass das EEPROM auch korrekt an den Prozessor angeschlossen ist? Einem EEPROM ist es egal, wie die Adressen und Daten angeschlossen sind. A0 muss nicht zwingend A0 sein, sondern könnte am Prozessor auch an A7 angeschlossen sein. Das gleicht gilt auch für die Daten. Sowas wurde früher gerne als Ausleseschutz gemacht. Mit einem "normalen" Programmer bekommt man nur noch Zahlensalat, aber kein sinnvolles Programm.
Christian H. schrieb: > Mit einem "normalen" > Programmer bekommt man nur noch Zahlensalat, aber kein sinnvolles > Programm. Naja, dann muss man halt für 8 Daten und 8 Adressen 20 billionenmal disassemblieren, und nimmt dann das sinnvollste. Ist so oder so ein Geduldspiel. Gruss Reinhard
Christian H. schrieb: > hildesheimer schrieb: >> Eprom wurde auf jeden Fall korrekt ausgelesen. Direkt aus der Fassung >> des Gerätes in die Fassung des Epromer's. Das Eprom wurde auch schon >> mehrfach kopiert, alles einwandfrei. > > Sicher, dass das EEPROM auch korrekt an den Prozessor angeschlossen ist? > Einem EEPROM ist es egal, wie die Adressen und Daten angeschlossen sind. > A0 muss nicht zwingend A0 sein, sondern könnte am Prozessor auch an A7 > angeschlossen sein. Das gleicht gilt auch für die Daten. Man kann hardwareseitig die Adressen und auch Daten eines EPROM vertauschen, z.B. so daß keine Kreuzungen mehr auf der Platine sind. Technisch kein Problem. Die Arbeit hat man dann aber dem entsprechend anderweitig in der Umgestaltung der Brenndaten. Ich sah bisher noch nie eine Platine, wo das mal so gemacht wurde.
Wilhelm F. schrieb: > Ich sah bisher noch nie eine Platine, wo das mal so gemacht wurde. Ich schon. Aber das ist hier nicht der Fall! Die Daten ergeben einen Sinn! Gruß Jobst
Jobst M. schrieb: > Wilhelm F. schrieb: >> Ich sah bisher noch nie eine Platine, wo das mal so gemacht wurde. > > Ich schon. > > Aber das ist hier nicht der Fall! > Die Daten ergeben einen Sinn! > > > Gruß > > Jobst Eben. Sonst würde bestimmt was ganz anderes dar gestellt, als 8051-Assemblercode.
Wilhelm F. schrieb: > Eben. Sonst würde bestimmt was ganz anderes dar gestellt, als > 8051-Assemblercode. Haha! :-) Nein, ich meinte auch, dass die Zusammenhänge Sinn ergeben. Gruß Jobst
Wilhelm F. schrieb: > Das Ding läuft > wiederum nur über das Programm DOSbox, eine virtuelle DOS-Maschine, ist > für heutige Maßstäbe nicht so komfortabel, und benötigt als Input eben > genau das Intel-Hex-Format, kein BIN. Die Umwandlung ist doch kein Problem! Was wir hier benötigen ist ein ....Bin oder IntelHex File. Alles andere ist sinnlos. Nein, den 8031 kenn ich noch nicht. Aber Programmcode vom Müll zu trennen, trau ich mir noch zu.
nun wir haben hier jetzt schon die unterschiedlichsten Versionen des Codes und auch noch mut unterschiedlichem Inhalt gesehen haben aber immer noch keinen Schaltplanauszug. Wieso sollte sich jemand der Ahnung von der Materie hat mit sowas beschäftigen? Für mich ist jetzt solange Ende, solange kein Schaltplan und eine finlale Version des Eprom Inhalts im Bin Format (8k) für ein 2764 Eprom vorliegt. Man vergleiche nur das 1. Disasm Listing mit den späteren Versionen. Das ist doch alles nur Rätselraten. Noch ein Hinweis: LJMP 0800h beim Reset ist der typ Init für DemoVersionen z.B des Keil C compilers. Mehr gibts erst nach vollständiger Info.... Thomas
Thomas schrieb: > LJMP 0800h beim Reset ist der typ Init für DemoVersionen z.B des Keil C > compilers. Dagegen spricht zum einen, dass durchaus auf Code Bestandteile unterhalb 0x800 zugegriffen wird und auch der Code sieht eher nicht nach Keil-C aus. Aber mit dem Schaltbild hast du Recht. Ohne Kenntnis der Peripherie ist es Blödsinn, auch nur eine Stunde für den ReAsm zu verschwenden. Ansonsten sind die 2k oder so echter Code (vieles sind nur Tabellen) eine Fingerübung für einen Abend.
Schaltplan muss erst digitalisiert werden. BIN für 2764 8k ist oben bereits vorhanden, Schlaumeier.
So, ich habe 2017.HEX von Bernhard Spitzer mal in DISA51 geladen, und disassembliert. Heraus kam das Log-File 2017.LOG im Anhang, welches aber eine ganz normale Textdatei ist. Die Darstellung sieht etwas anders aus, als im Disassembly 2017.TXT weiter oben. Auch die Inhalte scheinen unterschiedlich zu sein, das werde ich mir später noch mal anschauen.
Das sieht doch schön aus! (Ich will hier gar keine komplette Aufschlüsselung ...) Aber kann man jetzt ab 1800 bis 18F6 nicht erkennen, was dort "abgeht" ? Grüße
> bereits vorhanden, Schlaumeier.
ja ich bin ein Schlaumeier und weist du was dass Ding wäre schon lange
gegessen, wenn du die Infos bereitstellen würdest. Wenn ich mich richtig
erinnere bist es du doch der die Kiste nicht blickt oder?
Es gibt hier einige die von sowas Ahnung haben!
Wie hat jemand geschrieben: "Fingerübung für einen Abend".
Was mir schon so oft hier aufgefallen ist:
Die Frager glänzen durch grandiose Ignoranz und werden auch noch pampig
wenn Ihnen manche Antworten nicht gefallen. Alles in allem halt
Zeitverschwendung
Wie auch immer such dir doch die Infos selber zusammen.
@Wilhlem
ein Dissassember der keine Labels verwaltet braucht kein Mensch. Wie
schon vorher geschrieben Disassember gibt es auch in richtig. Es muss ja
nicht gleich IDA Pro sein.
Thomas
hildesheimer schrieb: > Aber kann man jetzt ab 1800 bis 18F6 nicht erkennen, was dort "abgeht" ? Es ist zumindest kein sinnloses Durcheinander von Bits. Der resultierende X51 Code sieht nach Überresten eines Debug Monitors aus, die beim Brennen des Eproms noch zufällig im RAM waren. Die Schnipsel enden alle mit Selbstmord, was darauf hin deutet, dass sie nicht zum "Wirkcode" gehören.
Hildesheimer schrieb: > Schaltplan muss erst digitalisiert werden. Einfach die Handzeichnung mit dem Scanner einlesen, schon ist der Schaltplan digitalisiert....
Thomas schrieb: > @Wilhlem > ein Dissassember der keine Labels verwaltet braucht kein Mensch. Wie > schon vorher geschrieben Disassember gibt es auch in richtig. Es muss ja > nicht gleich IDA Pro sein. > > Thomas Und ich glaubte schon, wir brauchten hier Leute, die behilflich sind. Nicht solche, die anderer Leute Dinge anmeckern. ;-)
So, ich hatte das 2017.HEX inzwischen auch mal im Simulator, und einen Breakpoint bei 1800h gesetzt, dann einfach gestartet. Dieser Bereich wurde nach ein paar Minuten Laufzeit von selbst nie erreicht. Zu Fuß bin ich den Code im Augenblick jetzt nicht mehr (bzw. noch nicht) durch gegangen. Drei Pins am P1 klapperten etwas, da hängt also außen bestimmt was dran. Es wäre noch möglich, daß eine äußere Beeinflussung an den Pins oder über die serielle Schnittstelle woanders hin verzweigt, aber so weit war ich noch nicht.
Danke! Es ist für mich so wichtig, zu wissen, ob dieser Bereich in irgendeiner Weise "mal" im Programmablauf benötigt wird. Wichtig deswegen, weil ich gerade eine neue Firmware schreibe und eben nach dem Schaltplan alles nachbilden kann. Aber ein "Bereich", der im Eprom gar nicht nötig ist - trotzdem aber Funktionales in sich hat, ist dann eben sehr interesant.
Es gibt keinen Schaltplan, noch was an den Pins hängt, noch was das Ding eigentlich macht, nur eine mehrfache Aussage, dass man den Vater (Ersteller des Programms?) nicht mehr fragen kann. Realname Pustekuchen. Warum werde ich das Gefühl nicht los, dass da jmd. nur einen Dummen sucht, der für einen die Arbeit macht oder sonst etwas faul an der Sache ist... Demnächst wird das Gerät dann mit einer neuen, aktuellen Hardware gewinnbringend vermarktet...
Realname stimmt nicht, war oben noch vorhanden, ist dann aber dazwischen irgendwann verloren gegangen...
hildesheim schrieb: > Danke! > Es ist für mich so wichtig, zu wissen, ob dieser Bereich in irgendeiner > Weise "mal" im Programmablauf benötigt wird. Noch ist ja längst nicht alles klar. Ein Schaltplan wäre nett, ansonsten hänge ich hier auch nur mit halber Kraft dran, wie ein Auto im Standgas bzw. Leerlauf, und ich habe keine Ahnung vom Ziel. Übrigens brannte ich auch schon mal mehr als ein völlig unabhängiges Programm in ein EPROM. Die Programme waren dann mit einem Jumper oder DIP-Schalter auf der Platine auswählbar. Vielleicht ist dein Fall ja auch sowas.
hildesheim schrieb: > Danke! > Es ist für mich so wichtig, zu wissen, ob dieser Bereich in irgendeiner > Weise "mal" im Programmablauf benötigt wird. Der Bereich wird nur einmal im Jahr zum Jahreswechsel durch einen externen Interrupt von der HW-Uhr ausgeführt ... oder so ... Gruß Jobst
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.