Pages: [1] 
|
 |
|
|
Author
|
Topic: STM32F4 debugging mit ST-Link-V2? (Read 2571 times)
|
|
DF8OE
Administrator
 Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
 
|
 |
STM32F4 debugging mit ST-Link-V2?
« on: 25. November 2015, 09:47:36 »
|
|
Jetzt ist es soweit: ich denke, ich brauche eine Debuggingmöglichkeit.
Der EEPROM-Code ist fertig, aber er funktioniert nicht vollständig. Ich habe auch schon ein paar Stellen in Verdacht - könnte das relativ leicht feststellen, wenn ich an den entsprechenden Stellen einen Breakpoint setzen könnte und dort mal den Inhalt einiger Variablen anschauen könnte.
Der Code ist *grausam". Aber es geht aus Kompatibilitätsgründen nicht anders...
Es funktioniert bereits alles (umkopieren des virtuellen EEPROMs in den seriellen,, Lesen aus dem seriellen). Nur beim Schreiben der Daten in den seriellen EEPROM hapert es noch.
Wer möchte, kann sich ja mal die Funktion UiDriverSaveEepromValuesPowerDown() anschauen. In dieser stattlichen Funktion lädt Clint jedes Word einzeln aus dem PROM und schreibt entweder einen Defaultwert oder den aktuellen Wert zurück. Das sind 383 Word-Schreibvorgänge!!! Wenn man die "einzeln" in den seriellen EEPROM machen würde, dauert as Ausschalten ca. 60 Sekunden  Also habe ich folgenden "Trick" benutzt:
Ich reserviere am Anfang genug RAM, um die gesamte Konfiguration aufzunehmen. Dann lade ich den kompletten Inhalt es seriellen EEPROMs in diesen RAM und lasse die schreib/lesewütigen Aufrufe von Clint in diesem RAM durchführen. Und wenn alle seine Änderungen durch sind, dann schreibe ich den nun modifizierten RAM in einem einzigen sequentiellen Write zurück in den seriellen EEPROM.
Die Schreib/Lesefunktionen aus dem EEPROM sind fertig und funktionieren. Sonst würde das Umkopieren ja nicht klappen.
Ich denke, dass das Problem in der Reservierung des RAMs liegen wird. Da RAM nicht gerade üppig vorhanden ist, lege ich den Bereich am Anfang der UiDriverSaveEepromValuesPowerDown() mit
static uint8_t puffer[MAX_VAR_ADDR];
an (wobei MAX_VAR_ADDR die Menge der zu verarbeitenden Bytes ist). Innerhalb der Funktion werden die jetzigen Lese/Schreibvorgänge in jeweils eine neue von mir kreierte Funktion umgelenkt, in der entschieden wird, ob in den virtuellen EEPROM geschrieben werden soll (also "alten Code benutzen") oder ob die Vorgänge in den RAM laufen sollen. Dazu greife ich in meinen neuen Codeblöcken auf einen auch dort gültigen Pointer zu, in dem ich in der UiDriverSaveEepromValuesPowerDown() den reservierten "puffer" geschrieben habe.
Nicht schlagen: Ich würde das alles ganz anders machen, wenn ich nicht kompatibel bleiben müsste!!!
Jemandem diesen Code zum "Querlesen" zu geben, wäre eine glatte Zumutung. Deswegen möchte ich wissen, ob es möglich ist, mit dem ST-Link V2 hier ein Debugging durchzuführen. Wie gesagt: ich habe ein paar Stellen in Vermutung, kann das aber nicht ohne weiteres überprüfen...
Mit dem STM32F4 arbeite ich seit 4 Monaten und habe keine weiteren Erfehrungen damit...
vy 73
Andreas
|
|
 Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #1 on: 25. November 2015, 11:20:06 »
|
|
Hallo Andreas,
wo setzt Du
ts.ser_eeprom_in_use auf 0xFF ?
Grüsse,
René
|
|
Logged
|
|
|
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #3 on: 25. November 2015, 11:46:15 »
|
|
> Ich nehme an, Du hast den Code aus dem GitHub devel-DF8OE...
Natürlich :-)
|
|
Logged
|
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #4 on: 25. November 2015, 12:49:40 »
|
|
Ich habe mal kurz reingeschaut. Irgendwie scheint mir, dass es noch etwas "durchgängiger" sein könnte.
Also, in copy_serv2virt(void) wird wie folgt gezählt:
for(count=1; count < 381; count++)
Beim Vergleich aber, werden alle 382 verglichen:
for(count=1; count < MAX_VAR_ADDR; count++)
Aber in UiDriverSaveEepromValuesPowerDown() werden 768 reserviert aber nur 383 geschrieben:
for(i=1; i<=MAX_VAR_ADDR; i++)
irgenwie verstehe ich das jetzt nicht.
vy 73 de René
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #5 on: 25. November 2015, 13:14:48 »
|
|
Im Moment werden nur Variable n unterhalb von 150 genutzt. Diese "Zahlen" sind im aktuellen Code alle durch eine Konstante ersetzt worden (MAX_VAR_ADDR). Die steht zur Zeit auf 383: das ist die definierte EEPROMlänge dess virtuellen EEPROMs.
Die verify-Rputine habe ich nur zum Debuggen gebraucht, die ist jetzt obsolet.
Kann sein, dass ich irgendwo beim letzten Wort (die MAX_VAR_ADDR sind ja WORDS, als 2 Bytes) geschlampt habe. Das ist aber unbedeutend, da die definierte Länge *deutlich* über der genutzten liegt.
Da die copy, Lese und sequentiellen Schreibroutinen alle funktionieren, kann der Fehler nur in der Denkweise zum power-off-speichern liegen.
Entweder, ds Reservieren des RAM ist falsch, oder der RAM ist nicht mehr gültig, wenn die Schreib/Lesefunktionen daraus aufgerufen werden. Ich setze die ts.ser_eeprom_in_use bei Beginn der power-off-save-Funktion auf 0xAA und in den aufgerufenen Funktionen wird, wenn ts.ser_eeprom_in_use 0xAA ist, auf den RAM zugegriffen...
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #6 on: 25. November 2015, 13:20:48 »
|
|
Versuch mal den Speicher global zu allozieren. Also nicht in der Funktion.
73, René
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #7 on: 25. November 2015, 13:45:48 »
|
|
Hatte ich auch schon vermutet und durch deine Bestärkung ausprobiert. Leider kein Unterschied. Der serielle EPROM wird definitiv mit irgendwas beschrieben: aber das ist "totaler Müll".
Das erste Wort wird im virtuellen EEPROM nicht genutzt, weil es "unzuverlässig ist", so Clint). Da das aber nicht für den seriellen EEPROM gilt, verwende ich diese beiden Bytes im seriellen EEPROM für:
ts.ser_eeprom_type (verwendeter serieller EEPROM)
ts.ser_eeprom_in_use
...und sogar diese beiden Bytes sind nach dem Ausschalten geschreddert - auf die greift die "Vermuddelungsroutine" von Clitnt aber gar nicht zu - die beginnt erst ab Word1 (== Byte 3)
Zumindest dieser Fehler muss folglich in diesen Teilen der power-off-Funktion liegen:
- auslesen des seriellen EEPROMS in den Buffer
- zurückschreiben desselben
...ich werde mal einen grossen Teil von Clints Routinen komplett übergehen und einfach nur auslesen und zurückschreiben...
vy 73
Andreas
EDIT:
Wenn ich den gesamten Block von Clint in der power-off-save-Funktion ausdokumentiere, dann wird der Speicher nicht geschreddert. Also liegt das Problem im Zusammenspiel von Clints Code und meinen "getrickten" Teilen, in dem ich die Routinen von Clint auf den Speicher arbeiten lasse...
EDITEDIT:
Danke, René. Durch Deinen Anstoß habe ich diesen Fehler gefixt:
die Adressierung im virtuellen EEPROM geschieht WORD-weise, im RAM aber BYTE-weise. Also muss die übergene Adresse vor der Verwendung mit 2 multipliziert werden 
Jetz geht auch das Abspeichern, aber bei jedem Einschalten kommt die Meldung "new firmware found - preparing EEPROM". Das ist jetzt eine andere und vermutlich wesentlich harmlosere Baustelle. Hier habe ich vermutlich wirklich irgendwo it den von Dir angesprochenen "Zahlen" geschlampt...
|
| « Last Edit: 25. November 2015, 14:05:02 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #8 on: 25. November 2015, 14:46:28 »
|
|
Hallo Andreas,
super!!!! :-)
Sag mal, inwieweit musst Du kompatibel bleiben?
Ich würde gerne den Code etwas überarbeiten, damit die Wartbarkeit etwas mehr gegeben ist. Die Warnings rausfriemeln, an der einen und anderen Stelle ein Enum rein etc.
vy 73 de René
PS: ich habe leider noch kein Board zum testen, aber da ich seit 25 Jahren vollamtlich in C und C++ Code, den STM kenne, trau ich mir das im Blindflug zu.
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6284
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #9 on: 25. November 2015, 15:35:20 »
|
|
Hallo René,
die Sache mit der Kompatibilität sehe ich so:
Man kann/soll/darf alles verändern, solange es mit dem EEPROM-Format und der "Standard-Hardware" des mcHF läuft. Insofern muss ich jetzt darauf achten, dass die seriellen EEPROM-Erweiterungen nicht stören, wenn jemand (und weite Teile der Yahoo-NG-Mitglieder werden das tun) die serielle EEPROM-Mod ignoriert. Wenn das ein paar KB Flash schluckt, ist das nicht weiter schlimm. Und wenn weitere Erweiterungen irgendwann mal die Flash-Kapazität von 512KB sprengen - dann stört mich das auch nicht. In diesen Dingen bin ich "knallhart". Seit Anfang Mai habe ich gepredigt, dass man den 50 Cent teureren STM mit 1MB Flash nehmen sollte - wer sich dessen verweigert hat, der hat selbst Schuld.
Mit den Codebereinigungen ist das so eine Sache - ich war da auch schon mal dran und habe nach einigen "Stirnrunzelereignissen" die Aktion zunächst vertagt.
1) Im Code sind RAM-Alloziierungen der art test_a[1000] etc. Diese Variablen werden zwar deklariert - aber niemals benutzt. Der GCC warnt natürlich. Du kannst diese Zeilen auch einfach auskommentieren - die Warnings sind dann weg. Aber das Binary ist dann nicht mehr lauffähig (darauf ist Clint bei seinen letzten Bereinigungsversuchen reingefallen). Ich habe davon noch einige Stellen gefunden. Man kann sie ausdokumentieren - die Warnings sind dann weg - aber das bin ist nicht mehr lauffähig. Clint schiebt das auf "buggy gcc" - ich vermute eher unbedachte Programmierung dahinter. Aber die Sache pilzt derart auf, dass ich zur Zeit lieber "mit fassbarem Ergebnis" programmiere, als bereinige...
2) Wenn Du auch nur irgendeine Codeoptimierung aktivierst, ist das bin ebenfalls nicht mehr lauffähig. Auch das ist mitnichten ein Fehler des gcc - auch das liegt mit 99,999% Sicherheit an der Programmiertechnik.
Deswegen bin ich am Zweifeln, ob Dir deine Erfahrung da hilft oder ob Du nicht doch einen mcHF zum Verifizieren deiner Arbeit brauchst. Da liegt noch einiges im Argen - und wenn wir das gelöst haben, dann wird ALLES gehen, was ein Amateur mit dem Gerät machen will.
Wenn Du solange schon mit dem STM arbeitest, lass mich bitte neugierig sein:
- arbeitest Du unter Windows oder unter Linux?
- ist es mit dem ST-Link V2 möglich, ein Debugging, so wie ich es im ersten Post geschrieben habe, möglich?
Ich werde jetzt erstmal schauen, wo die restlichen Kinken liegen - salût
vy 73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #10 on: 25. November 2015, 15:56:28 »
|
|
Hallo Andreas,
ich sehe, dann muss mein mchf erstmal fertig sein. Das muss noch warten, weil ich vorerst ein anderes Projekt fertigstellen möchte.
Zu 1)
Das der GCC in dem Bereich buggie ist, schliesse ich fast aus. Die von Dir beschriebenen Probleme deuten auf schlechtes Memory Management hin. Ich habe dazu auch schon einige Stellen gesehen beim durch den Code "surfen"
Allerdings macht mich sowas auch etwas nachdenklich, das ist wie wenn man auf das Fundament der Pfahlbauten einen Hochhaus baut. Früher oder später bricht das komplett zusammen.
Zu 2) dasselbe. Da fehlen zum Beispiel einige volatiles. Der Stack ist schon nach den ersten paar Calls versaut. Das kann funktionieren, aber stabil ist es so nie.
Zu Deinen Fragen: entwickeln tu ich auf Linux. Ich habe aber auch ein Windows und Mac zum testen (ich arbeite oft an OpenSource Software).
Wegen dem debuggen, ja das geht, ist allerdings sehr träge.
Vy 73 de René
Edit:
>Wenn Du solange schon mit dem STM arbeitest, lass mich bitte neugierig sein
Mit dem STM bin ich erst vier Jahre unterwegs, privat. Beruflich entwickle ich in einem anderen Bereich auf Solaris und Linux.
|
| « Last Edit: 25. November 2015, 16:27:02 by hb9frh » |
Logged
|
|
|
|
|
|
hb9frh
schon länger dabei
Offline
Posts: 57
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #12 on: 25. November 2015, 16:55:13 »
|
|
Hallo Andreas,
dieser Link dürfte Dir helfen:
https://www.mikrocontroller.net/articles/STM32F4-Discovery#stlink
Das mit dem Optimizer klappt nicht ohne volatiles. Das ist ja das Problem. Arbeiten tu ich auch nur mit Konsole (vi, ctags, cmake, git [-flow]). Eclipse ist mir zu "schwer".
Das Problem wird sein, umso mehr Code, umso mehr Aufwand.
Vy 73 de René
|
|
Logged
|
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:STM32F4 debugging mit ST-Link-V2?
« Reply #14 on: 26. November 2015, 09:57:48 »
|
|
Andreas,
wie Du schon von mir gehört hast, ist das mit Eclipse und gdb / ST-Link kein Problem. Ich muss mal sehen, wie ich das hier ordentlich beschreiben kann.
Klar ist, wenn man Debuggen will, müssen einige Compiler-Schalter passen und einige Optimierungen sind nicht möglich, wodurch der Code größer wird. Wenn den Release-Code debuggt, muss man damit leben, dass man hin und wieder "nur" Assembler Code zu sehen bekommt... Kann man aber beim ARM gut lesen.
Der arm-gcc-4.9.2 hat einen Bug im Linker und daher muss man unbedingt auf den 4.9.3 bzw. den gcc-arm-none-eabi-4_9-2015q1 oder neuer von linaro wechseln. Der Bug betrifft nicht nur den arm-none sondern auch den arm-linux- Zweig und darüber sind nicht nur wir, sondern auch OE und Angstroem gestolpert.
Es kann sein, dass es kein Defekt im Linker selbst ist, sondern dass geänderte default-flags dazu führen. Letztendlich ist es egal, da man das Problem mit einem einfach zu installierenden Paket auf allen Plattformen umschiffen kann.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
Pages: [1] 
|
|
|
|
|
|
|
.
