Forum: Mikrocontroller und Digitale Elektronik Wie STM8 Assembler File "bearbeiten"?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

Kurze Frage:

vor mir liegt eine Control-Box mit einem STM8.

Aus dem nicht geschützten Prozessor habe ich Flash und Eeprom ausgelesen 
und den Flash Inhalt durch einen STM8 Disassembler geschickt. Im Eeprom 
sind nur 2 Byte geschrieben.

Jetzt hab ich zwar aus 8kB Flash 300kb Assembler Text gemacht, komme 
aber nicht richtig weiter.

Das Programm bedient u.a. eine serielle Schnittstelle und sendet Daten 
aus.
Das klappt auch prima. Ich müsste aber wissen, ob und welche Daten und 
Kommandos empfangen werden könnten.

Gibt es da eine gute Idee, wie ich das Programm besser lesen und 
verstehen könnte?

VG
Ralf

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Um aus einem Binary Informationen herauszuholen braucht man geeignete 
Tools wie z.B. Ghidra oder IDA Pro. Ein einfacher Disassembler eignet 
sich dafür nur in trivialen Fällen.

Damit kann man dann versuchen das Binary zu verstehen und im Tool so zu 
bearbeiten dass etwas verständliches dabei herauskommt.

: Bearbeitet durch User
von Andreas B. (abm)


Lesenswert?

Erstmal müsste man sich mit dem Prozessor selbst mal richtig auskennen 
(lernen). Z. B. den Bereich ab 0x008000 als int_s zu interpretieren, 
macht
wenig Sinn, das sind halt die Interrupt-Vektoren, also Adressen!

Die "neg   (0x00,SP)" danach sind Unfug, der Bereich ist einfach leer, 
aber das kann ein Disassembler ja nicht wissen. Außerdem: Irgendwelche 
Tabellen oder Strings durch den Disassembler zu schicken, produziert 
viele kByte Müll.

Man muss schon beim Reset-Vektor anfangen und sich dann durchhangeln, um 
halbwegs erkennen zu können, was Code und was eventuell Daten sein 
könnten.

von Dieter S. (ds1)


Lesenswert?

Ich habe nur mal auf die Schnelle reingeschaut, das eigentliche 
Hauptprogramm liegt bei 0x9B27. Allerdings ist das Ganze ziemlich 
unschön weil der Compiler für den STM8 einiges an Code produziert der 
nicht gerade die Lesbarkeit fördert (z.B. ist 0x8B18 die Runtime für 
einen "switch" und es gibt viel Code nur um die Parameter auf dem Stack 
zu verwalten).

von Rbx (rcx)


Lesenswert?

Ralf G. schrieb:
> Gibt es da eine gute Idee, wie ich das Programm besser lesen und
> verstehen könnte?

Schaue es dir auch im Hexeditor an.

von Ralf G. (dougie)


Lesenswert?

Ich danke herzlich, die Herren!

Ich hab gerade mal Ghidra und die Extension für STM8 installiert, aber 
ich befürchte ich muss da noch etwas Zeit für das Ghidra Manual 
einplanen.

Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert, 
aber irgendwie bekomme ich nichts informatives angezeigt.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
>
> Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert,
> aber irgendwie bekomme ich nichts informatives angezeigt.

Die Tools machen das nicht von alleine, man muss ihnen z.B. mitteilen 
was Code oder Daten sind. Und um zu erkennen was der Code dann macht 
braucht es in erster Linie Erfahrung damit man schnell an Ziel kommt.

Was etwas helfen könnte: wenn man den verwendeten Compiler und dessen 
Libraries kennt kann man das Erkennen der Runtime und Funktionen aus den 
Libraries teilweise automatisieren. Aber auch damit sollte man sich 
auskennen damit es nicht zu viel Zeit kostet.

Welcher STM8 ist es denn genau, dann kann man zumindest die IO Adressen 
zuordnen?

von Ralf G. (dougie)


Lesenswert?

Danke für deine Zeit und Aufmerksamkeit,  Dieter! Euch allen natürlich!

Es ist ein STM8S003F3P

Es ist die mehr oder weniger simple Steuerung einer Espressomaschine.
Es werden zwei Temperatursensoren (A/D) überwacht, 2 Pumpen und eine 
Heizung gesteuert.
Die Komplexizität des Codes kommt möglicherweise daher, das irgendwo ein 
PID Regler integriert ist, der die Heizung steuert.
Und eben das Serielle Interface (9600 8N1)

Das Ganze kommt aus Italien, aber meine Anfrage beim Hersteller ist 
bislang unbeantwortet. Ich habe deswegen keine Info zum verwendeten 
Compiler.

Aber ich lerne gerne! Daher danke für deinen Input!

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Das hier ist vielleicht auch einen Blick wert:
https://github.com/Prehistoricman/STM8-IDA

(die Seite hier fand ich ebenfalls gar nicht so übel: 
http://aquarel-electronic.de/STM8/ASM8/ASM8_Page.html)

von Dieter S. (ds1)


Lesenswert?

Vielleicht etwas zum Nachvollziehen, das ist zwar nur die 
Initialisierung der Hardware, hilft aber eventuell für den Einstieg:

1
0x962F     call   clock_init
2
3
0x9632     ld   a, #1
4
0x9634     call   port_init
5
6
0x9637     call   ADC_init
7
8
0x963A     call   TIM1_init
9
10
0x963D     ldw   x, #9600   ; baud
11
0x9640     call   UART1_init
12
13
0x9643     call   flash_enable_write
14
15
0x9646     jp   IWDG_init

: Bearbeitet durch User
von Ralf G. (dougie)


Lesenswert?

Hallo Dieter,

das sieht grossartig aus! Darf ich fragen, wie du die Funktionen 
gefunden hast?

VG
Ralf

Die Free Version von IDA bringt mich leider nicht weiter. Und nur für 
dieses eine Projekt die Pro Version kaufen, lohnt sich wahrscheinlich 
nicht.

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Ralf G. schrieb:
> Die Free Version von IDA bringt mich leider nicht weiter. Und nur für
> dieses eine Projekt die Pro Version kaufen, lohnt sich wahrscheinlich
> nicht.

Eventuell genügt die Demo-Version von IDA Pro
https://www.heise.de/download/product/ida-pro-57580

edit: ach so, ist wohl auch die Free-Version. Naja, schade eigentlich.

: Bearbeitet durch User
von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Ralf G. schrieb:
>
> das sieht grossartig aus! Darf ich fragen, wie du die Funktionen
> gefunden hast?

In diesem Fall ist es einfach, man schaut wo die paar IO Adressen, die 
die Firmware anspricht, im Code verwendet werden. Das ist hier sehr 
überschaubar, als Beispiel die Funktion IWDG_init:

1
IWDG_init:
2
 mov  IWDG_KR, #$CC
3
 mov  IWDG_KR, #$55
4
 mov  IWDG_RLR, #$FF
5
 mov  IWDG_PR, #6
6
 mov  IWDG_KR, #$AA
7
 ret

Ob man dafür Ghidra oder IDA Pro verwendet ist egal, das kann man mit 
beiden Tools so machen.

Noch ein bischen mehr, es gibt drei Interrupt-Funktionen: UART Rx 
(0x9D2A), Timer 1 (0x9E26) und ADC (0x9CFD).

An Adresse 0x8080 liegt eine Tabelle mit 921 Werten, diese wird in der 
Funktion Adresse 0x9746 verwendet. Als Kurve sieht die Tabelle so wie im 
Anhang aus.

Und die UART wird in der Funktion Adresse 0x9300 behandelt. Mir ist 
allerdings momentan noch nicht klar ob die Firmware überhaupt etwas mit 
den per UART empfangenen Zeichen macht.

: Bearbeitet durch User
von Ralf G. (dougie)


Lesenswert?

...du würdest mich jetzt gerade schwer beeindruckt sehen !!

Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem 
Datenblatt des Proz mit den jeweiligen Adressen?

Aber so grundsätzlich sind wir genau da wo ich hin wollte:

Die Steuerung kann in zwei Modi betrieben werden:
Im Power Save Mode geht sie nach 30min schlafen; im Normal Mode läuft 
sie durch. Das kann man umstellen mit so einer speziellen 
Einschalt-Prozedur, und ich vermute das wird im EEprom gespeichert, weil 
da stehen nur ein oder zwei Byte.

Einerseits ist der Power Save Mode super, aber die Aufheiz-Zeit ist mit 
20min recht lang. Ich hab die über den seriellen Port ausgegebenen 
Informationen an einen ESP8266 gegeben, der das an einen MQTT Server im 
Keller sendet.
Damit kann ich immer sehen, was dier Maschine macht.

Ich will eigentlich nur wissen, ob es ein Kommando gibt, mit der man die 
Maschine aus dem Power Save Mode wecken kann.

Dafür versuch ich das Ganze.

von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
>
> Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem
> Datenblatt des Proz mit den jeweiligen Adressen?

Einfach anhand der verwendeten IO Adressen, in diesem Fall sind die 
Funktionen klein und übersichtlich und es wird immer nur ein bestimmter 
Teil der Peripherie initialisiert. Ob es diese Funktionen eventuell in 
einer Library von ST gibt hab ich nicht geschaut, das ist aber 
eigentlich egal weil man hier sehr deutlich sieht dass es um die 
Initialisierung geht (der Code wird einmal am Anfang des Hauptprogramms 
aufgerufen).

Die Namen der IO Adressen entsprechen der Bezeichnung von ST, die stehen 
so im Datenblatt oder auch in diversen Header Dateien.

> Dafür versuch ich das Ganze.

Bisher sehe ich noch nicht dass die Firmware irgendetwas mit den 
empfangenen Zeichen macht.

Mit dem weiter oben vermuteten "switch" lag ich daneben, der Code 
scheint Bestandteil der Floatingpoint Library des Compilers zu sein.

: Bearbeitet durch User
von Ralf G. (dougie)


Lesenswert?

...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das 
Ende der Reise. Dann geht das eben so nicht.

Ich bezweifle, das die Italiener den SourceCode raus rücken, daher gäbe 
es dann nur den Weg die Bedienung der Maschine zu simulieren.
Ist zwar bei weitem nicht so elegant, aber der ESP hat nicht viel zu 
tun.

Ich werd mir morgen aber erst mal die Register Map des Proz ansehen.
Mit deinen großartigen Tipps, sollte ich das ein oder andere 
nachvollziehen und verstehen können.

Nochmals vielen Dank dafür!


Zumindest glaub ich gefunden zu haben, wo die UART Baud Rate gesetzt 
wird:

1
     ld    A, 0x03                          ;0x009C06,    B6 03          
2
            and   A, #0x0F                         ;0x009C08,    A4 0F          
3
            or    A, 0x00                          ;0x009C0A,    BA 00          
4
            ld    0x5233, A                        ;0x009C0C,    C7 52 33       
5
            ldw   X, 0x02                          ;0x009C0F,    BE 02          
6
            call  0x9CC3                           ;0x009C11,    CD 9C C3       
7
            ld    A, XL                            ;0x009C14,    9F             
8
            ld    0x5232, A                        ;0x009C15,    C7 52 32

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
> ...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das
> Ende der Reise. Dann geht das eben so nicht.

Ich werde mir das morgen weiter ansehen nicht dass ich etwas übersehen 
habe.

Was man prinzipiell machen könnte ist die Firmware zu patchen und die 
gewünschte Funktion zu implementieren. In diesem Fall ist aber der freie 
Platz im Flash sehr begrenzt, da sind nur noch ein paar Bytes frei. 
Vielleicht findet man ja nicht benutzen Library Code, den man 
rausschmeißen kann.

von Ralf G. (dougie)


Lesenswert?

....das der Speicher recht voll ist, war mir auch schon aufgefallen. Ich 
hab das auf die bregrenzten 8K geschoben, und den erwähnten PID Regler. 
Obwohl ich keine echte Vorstellung hab, wie viel Code das erfordert. 
Aber ein PID ist nun mal ein Klotz.

Das Patchen der Firmware würde meine aktuellen Fähigkeiten auf absehbare 
Zeit überfordern. Aber ich möchte dich nicht um deine Freizeit bringen!

von Dieter S. (ds1)


Lesenswert?

Könntest Du eventuell noch den Dump des EEPROM Bereichs hier hochladen, 
das macht es einfacher zu verstehen was genau damit gemacht wird. Danke.

von Motopick (motopick)


Lesenswert?

Dieter S. schrieb:
> Ralf G. schrieb:
>> ...wenn die SW keine emfangenen Zeichen auswertet, wäre das schon das
>> Ende der Reise. Dann geht das eben so nicht.
>
> Ich werde mir das morgen weiter ansehen nicht dass ich etwas übersehen
> habe.
>
> Was man prinzipiell machen könnte ist die Firmware zu patchen und die
> gewünschte Funktion zu implementieren. In diesem Fall ist aber der freie
> Platz im Flash sehr begrenzt, da sind nur noch ein paar Bytes frei.

Du koenntest ganz einfach einen groesseren STM8 nehmen.

von Ralf G. (dougie)


Angehängte Dateien:

Lesenswert?

....grössere STM8 ... muss schauen ob es den Pinkompatibel im gleichen 
Gehäuse gibt. Ne neue Platine wollte ich nicht machen. :-)

Anbei auch noch der Schaltplan des Ganzen soweit ich ihn abgezeichnet 
habe.... Zwei Scheiberegister hintereinander als Treiber für die ganzen 
Ausgänge und eine Handvoll Eingänge.

von Dieter S. (ds1)


Lesenswert?

Danke, der EEPROM Dump bestätigt das was ich bisher im Code dazu gesehen 
habe. Im RAM liegt ein Flag dass 0 oder 1 ist, je nach dem was im EEPROM 
steht, das Byte 0x55 im EEPROM ist dabei nur ein Magic-Wert der anzeigt 
dass der Wert im EEPROM gültig ist.

Ich sehe aber immer noch nicht dass irgendetwas mit den per UART 
empfangenen Daten gemacht wird.

Ich denke ein einfacher Patch wäre machbar, irgendetwas in die Richtung 
dass nur ein Zeichen ausgewertet wird und dieses dann das obige Flag im 
RAM auf 0 oder 1 setzt. Die Frage ist ob das alleine ausreicht um den 
Power-Mode zu wechseln.

Hast Du einen Debugger (SWIM) für den STM8? Dann könnte man das vorab 
ausprobieren indem man das Flag per Debugger ändert und schaut was 
passiert.

Ansonsten müsste ich schaue ob die Firmware auch in einem STM8 
Eval-Board läuft, ich sollte irgendwo ein passendes hier haben.

von Ralf G. (dougie)


Lesenswert?

Ja, einen einfachen ST Link V2 hab ich hier, der SWIM kann. Damit hab 
ich den Prozessor ausgelesen.

Damit ich nicht am Live-System experimentieren muss, hatte ich mir dazu 
extra eine identische Steuerung als Ersatzteil in Italien bestellt. Von 
der ist die Firmware.

Wenn ich damit testen sollte, müsste ich mir ein Rig bauen, mit dem ich 
zumindest so viel Hardware simuliere, das die Steuerung läuft.

Um die Maschine aus dem StandBy zu holen, wird normalerweise der Hebel 
für den Kaffeebezug kurz betätigt. Dabei wird PD1 (SWIM) kurz auf Low 
gelegt. Vielleicht wäre das einfacher im Code zu realisieren?
Hätte auch den Vorteil, das die Maschine dann wieder in StandBy geht, 
sonst bräuchte es wieder ein anderes Flag im EEprom.
Wenn ich das Datenblatt recht in Erinnerung habe, mag diese Version des 
STM8 nicht gern so viele Schreibzugriffe auf das EEprom.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
>
> Um die Maschine aus dem StandBy zu holen, wird normalerweise der Hebel
> für den Kaffeebezug kurz betätigt. Dabei wird PD1 (SWIM) kurz auf Low
> gelegt. Vielleicht wäre das einfacher im Code zu realisieren?

Das ist nicht so einfach da für das Auswerten der Eingänge diverse 
Zähler für das Entprellen mitlaufen, man hat also nicht einfach nur ein 
Flag dass man setzen muss.

> Wenn ich das Datenblatt recht in Erinnerung habe, mag diese Version des
> STM8 nicht gern so viele Schreibzugriffe auf das EEprom.

100.000 Zyklen für den Datenspeicher (EEPROM) wenn ich das richtig 
interpretiere, nur die Firmware sollte man nicht öfters als 100 mal neu 
programmieren.

Ist denn die RS232 auch aktiv wenn die Maschine im Standby ist, werden 
also auch in diesem Fall Daten ausgegeben? Die CPU geht nach meinem 
bisherigen Verständnis nicht in den Halt, die sollte immer laufen.

Was anderes, ich sehe bei der Ausgabe über die UART einen Wert der 
entweder ein "C" oder ein "+" ist, weißt Du eventuell was das ist? Das 
steht vermutlich im Zusammenhang mit dem Eingang PC3.

Nachtrag: Ein paar Beispiele der UART Ausgabe in den beiden 
Betriebsarten wären interessant.

: Bearbeitet durch User
von Ralf G. (dougie)


Lesenswert?

Egal ob Aktiv oder Standby, der UART läuft da permanent und ohne 
Änderung durch.

Etwa 3 mal pro Sekunde kommt so ein String:

C1.22,116,124,093,0840,1,0\n

Das erste ist Betriebsart und Versionsnummer (1.22)
Dann Dampftemperatur ist,
Dampftemperatur target,
Wassertemperatur,
Zähler für irgend einen Boost mode (bei mir immer 0000),
Flag für Heizung an oder aus,
Flag für Pumpe an oder aus

von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
>
> Das erste ist Betriebsart und Versionsnummer (1.22)

Ist die Betriebsart (da sollte das "C" bzw. "+" kommen) der Standby 
Modus oder etwas anderes?

Nachtrag: Welche Funktion haben b1, b2 und b3 an CN6? Wie schon 
geschrieben, PC3 hat etwas mit der Betriebsart ("C" bzw. "+") zu tun.

Ausserdem geht in Deinem Schaltplan die Verbindung zu PC4 vermutlich zu 
PC5.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Ralf G. schrieb:
> Keine Ahnung wie ich das anfangen kann

Zuerst mal musst du dich mit dem Mikrocontroller vertraut machen. Dazu 
gehört in deinem Fall auch dessen serielle Schnittstelle. Du musst ihn 
selbst in Assembler programmieren können, sonst wirst du den Code nie 
verstehen.

Ralf G. schrieb:
> Die Komplexizität des Codes kommt möglicherweise daher, das irgendwo ein
> PID Regler integriert ist, der die Heizung steuert.

Ich glaube du schätzt das falsch ein. Ein PID Regler braucht nur wenige 
Zeilen Code.

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Steve van de Grens schrieb:

> Ich glaube du schätzt das falsch ein. Ein PID Regler braucht nur wenige
> Zeilen Code.

Nunja, wenige Zeilen Code in welcher Sprache? In C z.B. können diese 
wenigen Zeilen Code schon einen ziemlich fetten Blob erzeugen. Wenn z.B. 
float als Datentyp genutzt wird...

von Steve van de Grens (roehrmond)


Lesenswert?

Ob S. schrieb:
> In C z.B. können diese
> wenigen Zeilen Code schon einen ziemlich fetten Blob erzeugen. Wenn z.B.
> float als Datentyp genutzt wird...

Ja, aufblähen kann man alles beliebig. Aber man muss nicht.

Eine Aussage wie "wahrscheinlich ist es der PID" zu schieben, ohne den 
Code verstanden zu haben, ist jedenfalls abwegig. Genau so 
Wahrscheinlich kann es 100 andere Ursachen haben. Es kann auch sein, 
dass 80% davon gar kein Programmcode ist, sondern z.B. statische Texte 
oder Keys für Verschlüsselung.

In 8kB hatte man früher mal ganze Videospiele untergebracht.
Beispiele:
http://homecomputerworld.com/8kb-roms-vc20.html
http://homecomputerworld.com/4kb-roms-vc20.html

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Steve van de Grens schrieb:

> Eine Aussage wie "wahrscheinlich ist es der PID" zu schieben, ohne den
> Code verstanden zu haben, ist jedenfalls abwegig.

Das würde ich ohne jede Bedenken unterschreiben. Da hast du einfach mal 
Recht. Du hast es nur halt nur etwas fadenscheinig begründet.

> Genau so
> Wahrscheinlich kann es 100 andere Ursachen haben. Es kann auch sein,
> dass 90% davon gar kein Programmcode ist, sondern z.B. statische Texte
> oder Keys für Verschlüsselung.

Natürlich. Bei sehr vielen Programmen (insbesondere bei welchen mit 
einen "GUI") gibt es mehr Daten als Code. Eine Sache tauchte ja im 
Thread-Verlauf bereits auf: eine Tabelle. Auch Daten, kein Code.

von Rbx (rcx)


Lesenswert?

Man hat glaube ich auf der reinen Hardwareseite bessere Karten. Damit 
kann man ein Steuerungsmuster "auspiepen".
Ein paar brauchbare Steuerungsroutinen im gesuchten Zusammenhang zur 
Hand wäre auch nicht verkehrt.

von Cyblord -. (cyblord)


Lesenswert?

Ralf G. schrieb:
> Ich hab gerade mal Ghidra und die Extension für STM8 installiert, aber
> ich befürchte ich muss da noch etwas Zeit für das Ghidra Manual
> einplanen.
>
> Keine Ahnung wie ich das anfangen kann. Das Binary hab ich importiert,
> aber irgendwie bekomme ich nichts informatives angezeigt.

Hab mir jetzt auch mal Eimer und Kelle gekauft. Aber das Haus steht noch 
nicht.

von Ralf G. (dougie)


Lesenswert?

Dieter S. schrieb:
> Ralf G. schrieb:
>>
>> Das erste ist Betriebsart und Versionsnummer (1.22)
>
> Ist die Betriebsart (da sollte das "C" bzw. "+" kommen) der Standby
> Modus oder etwas anderes?
>
> Nachtrag: Welche Funktion haben b1, b2 und b3 an CN6? Wie schon
> geschrieben, PC3 hat etwas mit der Betriebsart ("C" bzw. "+") zu tun.
>
> Ausserdem geht in Deinem Schaltplan die Verbindung zu PC4 vermutlich zu
> PC5.

Das mit C und + ist korrekt. Es gibt einen Schalter, der je nach 
Position im "C = Coffee-Priority" oder "+ = Dampf-Priority" Mode fährt. 
Ist ein anderes Temperaturprofil.

Dann gibt es noch einen 3 Positionen Schalter um die bevorzugte 
Wassertemperatur in 3 zwei-Grad Schritten wählen zu können (meine 92 /94 
/96)

Und es gibt noch 3 LEDs Wassermangel, Maschine Heizt auf und der Power 
Switch.

Rest muss ich morgen raus suchen... und kann sein, das ich da noch einen 
Fehler im Plan habe

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Danke, dann gehen b1, b2 und b3 an CN6 vermutlich an die Schalter, es 
sieht auch so aus als ob die beiden anderen Eingänge unterschiedliche 
Temperaturen auswählen.

Noch etwas, Du schreibst weiter oben dass es ausreicht den Pegel an PD1 
zu ändern um die Maschine aus dem Standby zu holen. Wenn Du sowieso 
schon mit einem ESP8266 an der Maschine bist wäre es dann nicht am 
einfachsten damit den Pegelwechsel zu erzeugen? Dann braucht man gar 
nichts an der Firmware patchen.

von Ralf G. (dougie)


Lesenswert?

Das war ja auch meine Idee weiter oben. Software ändern hätte ich ohne 
deine Hilfe eh nicht realisieren können, also ging es mir um eventuell 
vorhandene undocumented Features, wie eben eine Möglichkeit via Rx.

Aber mit dem ESP und einem BSS138 sollte das doch auch gehen.

Eine Routine mit einer subscription am MQTT Server hatte ich schon dafür 
angelegt.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
>
> Aber mit dem ESP und einem BSS138 sollte das doch auch gehen.

Das wird die sauberste Lösung sein. Ich gehe inzwischen ziemlich stark 
davon aus dass die per UART empfangenen Daten ignoriert werden. Ein 
einfacher Patch der das entsprechende Flag für den Standby ändert wäre 
zwar vermutlich machbar, würde aber wohl ein paar Iterationen brauchen 
bis er auch funktioniert.

: Bearbeitet durch User
von Ralf G. (dougie)


Lesenswert?

…das ist doch das gewünschte Ergebnis! Ich kann nicht angemessen 
ausdrücken, wie dankbar ich für dein Interesse und Anteilnahme bin!

Das ist in Foren heutzutage eher selten! Ich hab jetzt viele 
Einstiegspunkte, wo ich weiter lernen kann, so wie es die Zeit zulässt.
Aber wie heisst es? Der Ingenieur treibt den Grad der Perfektion nicht 
weiter, als es der Sache dienlich ist! 😄

Ich werde das mit dem Transistor und ESP probieren und berichten!

Nochmals meinen aufrichtigen Dank!

VG
Ralf

von Dieter S. (ds1)


Lesenswert?

Der Vollständigkeit halber nochmal zu dem Binary: Der Compiler ist 
EWSTM8 von IAR. Die oben erwähnte Tabelle (die steht im Zusammenhang mit 
der Temperatur, eventuell ist das die Kalibrierung der 
Temperatursensoren) belegt schon fast 2 KByte, zusammen mit der Runtime 
des Compilers (insbesondere für Floatingpoint Arithmetik) wird schon 
fast die Hälfte des 8 KByte großen Flash belegt. Damit bleiben noch ca. 
4 KByte für die eigentliche Funktionalität der Software.

von Ralf G. (dougie)


Lesenswert?

Darf ich noch fragen, womit du die Namen der jeweiligen Routinen 
bekommen hast?
Mein Disassembler liefert ja leider nur die ASM Befehle

von Harald K. (kirnbichler)


Lesenswert?

Die Frage wurde doch schon beantwortet:


Dieter S. schrieb:
> Ralf G. schrieb:
>>
>> Woher hast du denn die Namen der Funktionen? Sind das Namen aus dem
>> Datenblatt des Proz mit den jeweiligen Adressen?
>
> Einfach anhand der verwendeten IO Adressen, in diesem Fall sind die
> Funktionen klein und übersichtlich und es wird immer nur ein bestimmter
> Teil der Peripherie initialisiert.


Die I/O-Adressen der Peripherie stehen im Datenblatt.

von Dieter S. (ds1)


Lesenswert?

Ralf G. schrieb:
> Darf ich noch fragen, womit du die Namen der jeweiligen Routinen
> bekommen hast?

Das Beispiel mit den Namen für die Hardware-Initialisierung ist ja 
relativ einfach: Wenn z.B. eine Funktion einmalig beim Programmstart 
aufgerufen wird und den ADC initialisiert dann ist ein Name wie 
"ADC_init" naheliegend. Man kann das natürlich beliebig benennen, es 
sollte halt einigermaßen zu dem passen was die Funktion macht.

Wenn man jetzt z.B. die Compiler Runtime anschaut dann kann man u.a. die 
Funktionen für die Floatingpoint Arithmetik benennen (etwa fadd32, 
fsub32, fmul32 und fdiv32 bei IAR).

Wie lange es dauert bis man erkennt was eine Funktion macht hängt u.a. 
von der eigenen Erfahrung ab, die Tools können aber teilweise bei dem 
Erkennen von Runtime Funktionen helfen.

von Ralf G. (dougie)


Lesenswert?

... ich hab das jetzt in Ghidra zumindest so weit, das ich das bin-file 
disassembled habe und er mir etliche Funktionen anzeigt. Leider aber mit 
vielen Fehlern.

Ich hab bislang nur einiges in Atmel AVR Assembler für Tiny und Mega-8 
geschrieben. Hier ist für mich jetzt sowohl der Prozesser & Code als 
auch das Tool neu ... das dauert dann eben etwas, bis man sich zurecht 
findet.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Das Binary hat folgenden Aufteilung in Code bzw. Daten:

1
0x8000-0x807F: Interrupt Vektoren
2
0x8080-0x87B1: die weiter oben bereits mehrfach erwähnte Tabelle
3
0x87B2-0x9E13: Code
4
0x9E14-0x9E25: Daten für die Initialisierung des RAM
5
0x9E26-0x9FE3: Code
6
0x9FE4-0x9FED: Daten für die Initialisierung des RAM

Im Code kommen allerdings auch vereinzelt Daten vor (.z.B. Floatingpoint 
Konstanten), die werden dann von der davor stehenden Funktion geladen 
und es geht nach den Daten mit dem Code weiter. Das sind aber maximal 
vier Bytes am Stück, meistens ist es nur ein Byte.

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.