Hallo Leute Kann mir jemand sagen wie ich in AVRstudio 6 eine *.hex oder *.bin Datei in Assembler decompiliere ? Ich habe hier im Forum gelesen, dass man das einfach öffnen muss, aber das geht irgendwie nicht, es wird dann einfach die Datei angezeigt, ohne Assembler Decompilierung.
Michael L. schrieb: > Kann mir jemand sagen wie ich in AVRstudio 6 eine *.hex oder *.bin Datei > in Assembler decompiliere ? geht damit nicht. Es gibt eventuell ander tools die das können aber mit dem Studio geht es nicht. Außerdem wird man sehr viel zeit einplanen müssen und dann den ASM code zu verstehen. Es gibt dann keine Label oder Namen mehr. Man kann ja nicht mal sauber zwischen daten und code unterscheiden.
Sucht du den Disassembler? http://www.atmel.no/webdoc/atmelstudio/atmelstudio.Debug.Views.Disassembly.html
Mein Problem ist folgendes: Ich habe ein Programm das für ein Arduino Bord mit ATmega328P geschrieben ist. Ich will das Programm aber auf einen ATmega328 flashen. Im Programm wird die serielle Schnittstelle angesteuert, wenn ich nun die *.hex Datei einfach auf den ATmega328 "draufwürge" stimmt die Baudrate der schnittstelle nicht ganz, ansonsten lauft das Programm einwandfrei. Ich will nun im Assemblercode nur die zwei Register der Baudrate anpassen, dann wider compilieren und auf den ATmega328 flashen.
Michael L. schrieb: > Ich will nun im Assemblercode nur die zwei Register der Baudrate > anpassen, dann wider compilieren und auf den ATmega328 flashen. dann mach es doch direkt im bin file. Suche dir die code sequenz für das setzen dieser Register und ändere sie. Wenn du glück hast gibt es sie nur einmal. die Codesequenz kannst du ganz einfach mit einem kleinen Testprogramm und dem Studio ermitteln. (oder mit hilfe der Opcode doku)
Assemblercode ist ASCII-Text. Jeder Editor liefert eine Suchfunktion mit. Wenn Du weist wie das zugehörige Register heißt bzw. unter welcher Adresse es zu finden ist, ist die Suche und das anschließende Ändern kein Problem. Musst Du allerdings komplette Befehlszeilen einfügen, so kommst Du nur mit einem Super-Komfort-Disassembler hin.
Sebastian S. schrieb: > Assemblercode ist ASCII-Text. > Jeder Editor liefert eine Suchfunktion mit. er hat aber nur die hex oder bin datei? Woher soll er denn den Assemblercode bekommen?
klausr schrieb: > Probier' mal "objdump -d" von den gnutools. wie soll das denn gehen? Ohne die type von µC als parameter kann das niemals funktionieren.
Spess53 schrieb: > Hi > Mit dem AVR Studio 4.19 geht das problemlos. > MfG Spess etwas technisch unmöglich soll damit gehen? Das kann ich nicht glauben. Ein Programm kann überhaupt nicht entscheiden ob es sich um irgendwelche Daten oder Programmcode handelt. Es mag eventuell in einigen Fällen gehen aber nicht "problemlos".
Angehängte Dateien:
... so sieht es momentan bei mir aus... Ich muss das Register UBRRnL und UBRRnH ändern, nichts einfügen. In der hex Datei sind aber nur Zahlen, Buchstaben da kommt ja kein Mensch draus... Die hex datei ist ja eigentlich 1:1 Assembler, sollte nicht so schwierig sein dies zu decompilieren, oder täusche ich mich ?
>Im Programm wird die serielle Schnittstelle angesteuert, wenn ich nun >die *.hex Datei einfach auf den ATmega328 "draufwürge" stimmt die >Baudrate der schnittstelle nicht ganz, ansonsten lauft das Programm >einwandfrei. Dann mach doch einen Quarz dran.
geht nicht da das Bord schon fix fertig ist, und ich eine Serie von 20Stk habe. Die Hardware ist also gegeben...
Michael L. schrieb: > Ich will nun im Assemblercode nur die zwei Register der Baudrate > anpassen, dann wider compilieren und auf den ATmega328 flashen. objdump liefert die ein Disassemby, jedoch kein Code, den du wieder in den Assembler füttern kannst. Ja nach Code geht das was du vorhast nich so einfach. Etwa dann wenn das UART-Register auf einen Wert gesetzt wird, der später nochmals verwendet wird. Ändern des Wertes wird dann auch die anderen Verwendungen beeinflussen. Schon mal gesehen sowas, ist also nicht rein theoretischer Natur. Peter II schrieb: > klausr schrieb: >> Probier' mal "objdump -d" von den gnutools. > > wie soll das denn gehen? Ohne die type von µC als parameter kann das > niemals funktionieren. Den µC braucht man nicht, es genügt die Emulation bzw. eine kompatible Obermenge davon, etwa: $ avr-objdump -m avr51 -D datei.hex Und dann viel Spaß beim Aufdröseln was Daten sind und was nicht. Vermutlich hat's folgendes Layout: 1) Vector-Tabelle (.vectors) 2) Daten (.progmem) 3) Code (.text) 4) Daten (.data, .rodata) und evtl. noch anderes Zeugs wie Bootloader etc.
Hi >etwas technisch unmöglich soll damit gehen? Das kann ich nicht glauben. >Ein Programm kann überhaupt nicht entscheiden ob es sich um irgendwelche >Daten oder Programmcode handelt. Braucht es auch nicht. Das kann ich selbst. Aber das Problem war doch, das er gar nichts disassembliert bekommt. Im 4er Studio brauche ich nur die .hex zu öffnen. MfG Spess
Michael L. schrieb: > Die hex datei ist ja eigentlich 1:1 Assembler, sollte nicht so schwierig > sein dies zu decompilieren, oder täusche ich mich ? nein ist sie nicht. weil in einem ASM programm auch Daten enthalten sind. z.b. irgendwelcher Text. Und dieser darf dann nicht in code umgewandelt werden. > In der hex Datei sind aber nur Zahlen, Buchstaben da kommt ja kein > Mensch draus... mit ein wenig Übung ist das machbar. aber das sind leute aus einer andere Generation die sich nciht von ein paar hex zeichen abschrecken lassen.
>geht nicht da das Bord schon fix fertig ist,
Selber schuld. Leb mit deinem Müll.
Das der interne RC Osci nicht für RS232 geeignet
ist kann man hier fast jeden Tag lesen.
Michael L. schrieb: > stimmt die > Baudrate der schnittstelle nicht ganz Wenn du einen Quarz verwendest, dann kannst du ja auch den Quarz entsprechend anpassen. Wenn du keinen dran hast, müsstest du jeden Prozessor einzeln abgleichen, das ist Blödsinn, dann hast du einfach unreparierbaren Schrott produziert. Gruss Reinhard
Michael L. schrieb: > geht nicht da das Bord schon fix fertig ist, und ich eine Serie von > 20Stk habe. Die Hardware ist also gegeben... Da wirst du nicht drumherum kommen, dir 20 Quarze zu kaufen und die da ranzupfriemeln. Das ist ja nicht nur die Toleranz. Dein Arduino-Code wurde für 16MHz kompiliert und jetzt hast du 8. Kannst aber mal probieren, auf dem PC die halbe Baudrate einzustellen. mfg.
Der Arduino Code wurde für 8Mhz geschrieben. Lade ich den Code in einen ATmega328P stimmt die Baudrate. Lade ich den Code in einen ATmega328 ist die Baudrate etwa 2k baud zu hoch. Es ist bei jedem Prozessor gleich viel daneben. Somit muss man dies nur einmal anpassen, und dann geht das immer.
Hi >Lade ich den Code in einen ATmega328 ist die Baudrate etwa 2k baud zu >hoch. Es ist bei jedem Prozessor gleich viel daneben. Die USART von ATMega328 und ATMega328P sind identisch. Bei gleichem Takt erzeugen beide bei einem identischen Wert von UBRR die gleiche Baudrate. Schon mal überlegt, woher eure Abweichung kommt? MfG Spess
Michael L. schrieb: > Somit muss man dies nur einmal anpassen, und dann geht das immer. Unwahrscheinlich, da nicht das "P" den Unterschied macht, sondern die unterschiedliche Produktionscharge. Abgesehen davon, dass man die Sache im Quellccode ändern könnte, wobei RC dann immer noch Krampf ist und nur für kleine Baudraten geht, man "könnte" schon... AVR-Studio 4 nehmen, Hex laden, memory breakpoint auf das UBR, mit Glück wird kein nicht-simulierbarer, blockierender Code vor dem Setzen der Baudrate ausgeführt, im Disassemblat passend ändern und per Programmerdialog des Studios zurückschreiben. Alternativ die Adresse im Flash merken, die Bytesequenz dort ist einzigartig und danach lässt sich im Hex suchen, dann Hex editieren, die Checksumme am Ende der Zeile anpassen und fertisch. Wenn das Schreiben des UBR per Simulations-Breakpoint nicht zu finden ist, dann eben das komplette Disassemblat "zu Fuß" durchsehen. Man könnte also - nur braucht's Kenntnisse in Assembler und ein bisserl weiteres Detailwissen. Allein die Fragestellung zeigt jedoch, dass davon nichts vorhanden ist. Also frag' den Schreiber der Software, ob er Dir das hinmurkst, d.h. eine Möglichkeit einbaut das OSCCAL z.B. über ein Byte im EEProm zu setzen, damit kann dann der interne RC passend gezogen werden und das kann geschehen, ohne das Hex für's Flash ändern zu müssen. Murks ist's trotzdem, aber für 1200 Baud o.ä. wird's laufen.
Michael L. schrieb: > Lade ich den Code in einen ATmega328 ist die Baudrate etwa 2k baud zu > hoch. Es ist bei jedem Prozessor gleich viel daneben. 2K? 3200 statt 1200? mfg.
http://atmel.com/Images/doc8035.pdf AVR512: Migration from ATmega48/88/168 to ATmega48P/88P/168P Der neuere 328 wird noch nicht genannt. Hier sind die Unterschiede aufgelistet: - "some register bits has been added..." - "low frequency crystal driver strength is reduced..." welche Registerbits das sind steht da leider nicht aber im Datenblatt: BODS and BODSE only available for picoPower devices ATmega48PA/88PA/168PA/328P Also nach "picoPower" suchen. Da gibts auch noch den Unterschied A oder P oder PA, nur nicht beim 328
Probier mal http://www.avrfreaks.net/index.php?module=Freaks%20Files&func=viewFile&id=1926&showinfo=1 Die Ausgabe ist halbwegs brauchbar.
Vielen Dank für eure Mühe und Tipps !! Aber das Problem hat sich nun erledigt ! Die Baudrate sollte 125k sein, hatte aber immer 127k, und dachte das dies das Problem sei. Nun hat sich herausgestellt das ein Fehlerhafter Spannungsregler die Ursache war. Er brachte zwar die 3.3V einwandfrei, hatte aber eine hohe Restwelligkeit die mir zum Verhängnis wurde. An der Seriellen Schnittstelle hängt ein HF-Modul, das dann vom Spannungsregler gestört wurde, und somit nicht sauber arbeitete. Der interne Oszillator des Atmega reicht allemal für diese Anwendung, auch wenn die Baudrate nicht ganz stimmt.
Georg G. schrieb: > Probier mal > http://www.avrfreaks.net/index.php?module=Freaks%2... > > Die Ausgabe ist halbwegs brauchbar. dieser Disassembler ist meiner Meinung nach brauchbarer, jedenfalls war ich damit wesentlich erfolgreicher: http://avr.myluna.de/lib/exe/fetch.php?media=de:disassembler.jpg wire
Michael L. schrieb: > Die Baudrate sollte 125k sein, 125000 Baud halte ich mit dem internen R/C für ein Gerücht. Aber evtl. muss es ja nicht zuverlässig und dauernd funktionieren. Dann reicht vielleicht auch, dass es ein bisserl funktioniert, so wie'n Blinker eben ;D
Hi
>125000 Baud halte ich mit dem internen R/C für ein Gerücht.
Ergibt bei genau 8 MHz einen Baudratenfehler von Null. Die 127kBd
entsprechen einer Oszillatorfrequenz von ca. 8,128 MHz und einem Fehler
von 1,6%. Etwes Luft ist da noch. Ob das auber unter allen Umständen so
bleibt (Spannung, Temperatu, Toleranz der Gegenstelle und ...) kann
niemand garantieren. Auf jeden Fall eine Fruzzellösung ohne Garantie.
MfG Spess
Spess53 schrieb: > Auf jeden Fall eine Fruzzellösung ohne Garantie. So sah ich das auch. Dass es mit idealen 8 MHz klappt war klar, aber nicht mit dem potentiell ungenauen und wandernden R/C. Da wird auch nix mit genau 8 MHz laufen, sondern ein wenig drunter oder drüber, kommen dann noch ein paar äußere Einflüsse dazu, wird bei einem der Baudratenfehler eben ein wenig kleiner, während's beim anderen soweit außer Toleranz kommt, dass es Ausfälle gibt. Aber das muss der TE selber wissen, handelt sich wahrscheinlich nur um Herzschrittmacher. Wenn einige der 20 Teilnehmer nur sporadisch reagieren, weiß er ja, wo er suchen muss.
Hi >So sah ich das auch. Wenn der TO früher mit dem eigentlichen Problem und den dazugehörenden Fakten herausgerückt hätte wäre die Diskussion ganz anders verlaufen. In Puncto Kommunikation mit internen Oszillator habe ich auch meine schmerzlichen Erfahrungen gemacht. Fernsteuerung eines Gerätes (mit ATMEGA128 4MHz intern) mit simulierter Gegenstelle auf dem PC programmiert. Lief problemlos. Mit realer Gegenstelle (PIC mit Quarz) war es ein Lottospiel. Seit dem läuft nichts mehr ohne Quarz. MfG Spess
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.