mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32F1 bleibt hängen wegen einer seltsame Ursache


Autor: Stm M. (stmfresser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

ich habe ein seltsames Problem das den STM32F1 zum Stehen bringt. Und 
zwar wird eine ISR Funktion 'angleEstimate' mit ca 16KHz Takt 
aufgerufen, wo paar Messwerte verarbeitet werden.

Mit dieser Version tritt kein Problem auf.
void angleEstimate(void) {
  float angle_p = angle + angle_vel * 0.000064f;

  if (ABS(hallCounterL) > 0) {
    angle_m = (float) ((hallCounterL << 6) - (hallCounterL << 2));
    float error = angle_m - angle_p;

    angle = angle_p + 0.03340962f * error;
    angle_vel = angle_vel + 0.05676238f * error;
  }
}

Der Controller bleibt hängen wenn ich die Funktion wie folgt umschreibe
// R: 300, Q: 10000 
float Gain[2] = {0.03340962f, 0.05676238f};

void angleEstimate(void) {
  float angle_p = angle + angle_vel * 0.000064f;

  if (ABS(hallCounterL) > 0) {
    angle_m = (float) ((hallCounterL << 6) - (hallCounterL << 2));
    float error = angle_m - angle_p;

    angle = angle_p + Gain[0] * error;
    angle_vel = angle_vel + Gain[1] * error;
  }
}

Was mache ich falsch?

Vielen Dank.

Autor: Dennis R. (dennis_r93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Glaskugel sagt:
Alles Ok. Es wird so funktionieren.

ooooooooder: du schickst zuwenig Informationen mit.

Der Code an sich ist OK. Es wird sich an den Randbedingungen etwas 
geändert haben was dem uC sauer aufstößt.

füge mal folgende Informationen hinzu:
* wo bleibt er hängen?
* Wann (sofort? nach einer Stunde?)
* wie oft durchläuft er die Schleifebevor er einfriert?
* Listing der Adressen von wichtigen Variablen
* Wie groß ist der Stack? gibt es evtl einen Überlauf?
* Was passiert wenn du nur ine Variable in ein Array verschiebst?
* Hast du einen Debugger zur Hand?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stm M. schrieb:
> Der Controller bleibt hängen

Definiere "bleibt hängen". Springt in einen Fault Handler? Bleibt an 
einer bestimmten Instruktion stehen? Welche? Oder wird die ISR lediglich 
so langsam dass der Controller diese nur noch in Endlosschleife ausführt 
und nichts anderes mehr tut?
Welchen Compiler nutzt du, wie ist deine Compiler-Kommandozeile, wie 
sieht die Disassembly aus?
Kannst du "Gain" nicht "const" machen?

Autor: Stm M. (stmfresser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten!

Bei der Initialisierung stoppt er sofort bevor die Main Schleife 
erreicht wird. Ich hab leider keinen Debugger.
> arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra  -g3 -DDEBUG -DUSE_FULL_ASSERT -DTRACE -DOS_USE_TRACE_SEMIHOSTING_DEBUG -DSTM32F10X_HD -DUSE_STDPERIPH_DRIVER -DHSE_VALUE=8000000 -I"../include" -I"../system/include" -I"../system/include/cmsis" -I"../system/include/stm32f1-stdperiph" -std=gnu99 -MMD -MP -MF"src/main.d" -MT"src/main.o" -c -o "src/main.o" "../src/main.c"

Den Gain mit const, noch volatile versucht, keine Änderung.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der F1 besitzt keine FPU. Du solltest das ganze auf Festkommaarithmetik 
ändern.
Ansonsten sind aus den Code-Schnipsel keine Fehler erkennbar.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stm M. schrieb:
> Ich hab leider keinen Debugger.

Dann ändere das mal, so kann man nicht vernünftig arbeiten. Es versucht 
auch keiner Autos zu bauen ohne einen Schraubenzieher zu besitzen. Die 
Discovery Boards und Nucleo Boards haben einen ST-Link Debugger und 
kosten unter 20€. Wenn du dir ein paar graue Haare sparen möchtest (und 
auf jeden Fall wenn du noch viel mit ARM machen möchtest) nimm einen 
J-Link EDU für 50€. Ohne Debugger ist das alles nur stochern im Nebel...

mh schrieb:
> Der F1 besitzt keine FPU.
Richtig.

mh schrieb:
> Du solltest das ganze auf Festkommaarithmetik ändern.
Nicht nötig, es wird eben in Software gerechnet, was auch im Compiler 
Aufruf korrekt steht. Ist halt nur langsam. Das geht ja sogar auf dem 
AVR.

Zeig mal die Disassembly von beiden Varianten!

Autor: Dr. No (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Dann ändere das mal, so kann man nicht vernünftig arbeiten. Es versucht
> auch keiner Autos zu bauen ohne einen Schraubenzieher zu besitzen. Die
> Discovery Boards und Nucleo Boards haben einen ST-Link Debugger und
> kosten unter 20€. Wenn du dir ein paar graue Haare sparen möchtest (und
> auf jeden Fall wenn du noch viel mit ARM machen möchtest) nimm einen
> J-Link EDU für 50€. Ohne Debugger ist das alles nur stochern im Nebel...


Also man kann auch ohne Debugger gut auskommen, wenn man ein bisschen 
Erfahrung hat und systematisch vorgeht.

Ein Nucleo-Board kann man übrigens auch mit der J-Link-Software flashen, 
dann schlägt man zwei Fliegen mit einer Klappe und braucht nicht viel 
auszugeben, man ist dann ab ca. 10,- Euro für das Entwicklungssystem + 
J-Link-Debugger dabei (abhängig vom Nucleo-Board).

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. No schrieb:
> Also man kann auch ohne Debugger gut auskommen, wenn man ein bisschen
> Erfahrung hat und systematisch vorgeht.

Ja. Aber es ist einfach viel mehr Arbeit. Mit dem Debugger geht vieles 
einfacher und schneller. Und so manchen gemeinen Fehler kann man ohne 
praktisch gar nicht finden - Speicher Fehler in einer fremd 
eingebundenen Library oder eigenen komplexen Programmen... Da kann ein 
simpler watchpoint in kürzester Zeit zum Ergebnis führen.

Dr. No schrieb:
> Ein Nucleo-Board kann man übrigens auch mit der J-Link-Software flashen,
Richtig, aber das geht dann (offiziell) nur mit STM32.

Autor: Dennis R. (dennis_r93)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das arbeiten mit Debugger ist deutlich einfacher und angenehmer. Erst 
recht wenn man weis wie man damit umgehen muss;-)

Zu deinem Fehler:
Hast du mal versucht ein paar ausgaben zu machen?
Weist du schon, wo der Code Stecken bleibt?

Weist du wie man ein Disassembly erstellt?
Weist du wo du das Listing her bekommst?
Hast du mal mit der Reservierten Größe für den Stack gespielt?

Dein Code hat keinen Fundamentalen Fehler. Wenn du willst, dass wird dir 
helfen brauchen wir mehr informationen.

Autor: Dr. No (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Dr. No schrieb:
>> Also man kann auch ohne Debugger gut auskommen, wenn man ein bisschen
>> Erfahrung hat und systematisch vorgeht.
>
> Ja. Aber es ist einfach viel mehr Arbeit. Mit dem Debugger geht vieles
> einfacher und schneller. Und so manchen gemeinen Fehler kann man ohne
> praktisch gar nicht finden - Speicher Fehler in einer fremd
> eingebundenen Library oder eigenen komplexen Programmen... Da kann ein
> simpler watchpoint in kürzester Zeit zum Ergebnis führen.


Das streitet keiner ab, aber stmfresser kann ja schnell mal eine LED 
blinken lassen, wenn eine Variable einen Wert annimmt, der nicht 
zulässig ist, oder im nächsten Schritt die Werte über den USART 
ausgeben. Eventuell auch über ein Display, wenn noch Pins frei sind. Die 
meisten Fehler findet man damit auch recht fix.


> Dr. No schrieb:
>> Ein Nucleo-Board kann man übrigens auch mit der J-Link-Software flashen,
> Richtig, aber das geht dann (offiziell) nur mit STM32.


Klar, aber den benutzt er doch.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dr. No schrieb:
> schnell mal eine LED blinken lassen,

Da der Code sofort abstürzt kann er gar nix ausgeben. Er müsste die 
ganze Initialisieung voll mit Debug Ausgaben machen. Mit dem Debugger 
sieht man nach 2 Clicks wo es stecken bleibt.

Dr. No schrieb:
> Klar, aber den benutzt er doch.

Ja, jetzt - wenn er vorhat das ARM Thema zu vertiefen könnte es 
vorkommen dass er noch andere Controller nutzen will... das muss er 
jedenfalls selber wissen.

Ich tippe auf Fehler im Linker Script, dass sich da aufgrund der 
zusätzlichen Variable was verschiebt. Stack zu klein ist eine mögliche 
Variante davon.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stm M. schrieb:
> Bei der Initialisierung stoppt er sofort bevor die Main Schleife
> erreicht wird.

Es könnte sein daß bei der Initialisierung von Gain[] eine Funktion aus 
der softfloat-lib aufgerufen wird, bevor das softfloat vollständig 
initialisiert ist. Also ein Problem der Initialisierungsreihenfolge.

Probier mal das zu umgehen:
float Gain[2];

...

main()
{
    ...
    Gain[0] = 0.03340962f;
    Gain[1] = 0.05676238f;
    ...
    // ISR init

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Es könnte sein daß bei der Initialisierung von Gain[] eine Funktion aus
> der softfloat-lib aufgerufen wird

Das macht keinen Sinn. Erstens muss bei der Library nichts initialisiert 
werden, zweitens erfolgt die Initialisierung von globalen Variablen 
normalerweise im Startupcode auf Basis von Rohdaten, komplett unabhängig 
ob das floats oder Integer oder C++ Klassen sind, quasi per memcpy. Da 
ist es völlig unerheblich ob irgendeine Library schon initialisiert ist, 
da werden nur Bytes kopiert.

Solange der OP nichts von sich hören lässt bzgl. Disassembly kann man 
hier nicht viel machen...

Autor: Dr. No (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Dr. No schrieb:
>> schnell mal eine LED blinken lassen,
>
> Da der Code sofort abstürzt kann er gar nix ausgeben. Er müsste die
> ganze Initialisieung voll mit Debug Ausgaben machen. Mit dem Debugger
> sieht man nach 2 Clicks wo es stecken bleibt.


Den Debugger hat er ja nicht.
Also in den Init-Teil geschickt ein LED-Blink einfügen. Kommt es, nach 
hinten verschieben, kompilieren, neu flashen, Reset.
Kommt es nicht, nach vorne verschieben, ...
Das ist doch fix gemacht und er muss jetzt nicht noch ne Woche warten, 
bis ein Debugger oder ein neues Board geliefert wird.


> Ich tippe auf Fehler im Linker Script, dass sich da aufgrund der
> zusätzlichen Variable was verschiebt. Stack zu klein ist eine mögliche
> Variante davon.


Kann auch genauso gut ein Fehler im Makefile sein, oder...

Am besten, stmfresser postet kurz Linker-Skript, Makefile und die 
Ausgabe des Compilers, damit man die Speicherbelegung sieht.

Autor: STM Apprentice (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stm M. schrieb:
> Ich hab leider keinen Debugger.

Ich frage mich welche dämliche Erklärung es gibt so einen
vollwertigen, voll kompatiblen Debugger für unter 10 Euro
nicht zu benutzen.

wie z.B.:
Ebay-Artikel Nr. 172692663082

Autor: Dr. No (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Stm M. schrieb:
>> Ich hab leider keinen Debugger.
>
> Ich frage mich welche dämliche Erklärung es gibt so einen
> vollwertigen, voll kompatiblen Debugger für unter 10 Euro
> nicht zu benutzen.


Ich frag mich, wie dämlich man sein muss, um solch unverschämte und 
unqualifizierte Postings abzusetzen.
Oder ist das asoziale Elternhaus dafür verantwortlich?

Fragen über Fragen...

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stm M. schrieb:

> zwar wird eine ISR Funktion 'angleEstimate' mit ca 16KHz Takt
> aufgerufen, wo paar Messwerte verarbeitet werden.

Float-Berechnungen macht man nicht in einer ISR, zumindest wenn man 
keine FPU hat. Setz in der ISR nur die Werte auf und mach die Berechnung 
in einer Art Main-Schleife, oder in einem separaten Task.

Zum Zweiten scheint Deine ISR so einige Variablen zu nutzen (angle, 
angle_vel, angle_m, hallCounterL etwa), die nicht in der ISR deklariert 
sind. Das müssen folglich globale Variablen sein, die Du wahrscheinlich 
dann auch anderswo verwendest.

Wann immer Du dieselbe globale Variable in einer ISR und im 
Hauptprogramm gebrauchst, MUSS die mit "volatile" deklariert sein. Sonst 
kann der Compiler diverse häßliche Wegoptimierungen machen.

Geh erstmal das mti dem volatile an, weil das am einfachsten zu machen 
ist.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Definitiv Startup-Code oder Linkerscript, wenn es mit lokalen Variablen 
geht aber mit globalen nicht.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Float-Berechnungen macht man nicht in einer ISR, zumindest wenn man
> keine FPU hat. Setz in der ISR nur die Werte auf und mach die Berechnung
> in einer Art Main-Schleife, oder in einem separaten Task.

Wozu? Welchen Vorteil soll es bringen, die Rechenzeit in der main statt 
der ISR zu verbrauchen? Auf dem Cortex-M kann man schließlich auch die 
ISR durch wichtigere Interrupts unterbrechen lassen durch Einstellung 
der Priorität.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:

> Wozu?

Man hält ISRs so kurz wie möglich, damit bei hoher Auslastung ggf. eine 
Berechnung übersprungen wird. Aber manche Leute nutzen ja auch printf in 
ISRs...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Man hält ISRs so kurz wie möglich, damit bei hoher Auslastung ggf. eine
> Berechnung übersprungen wird.
Das wird sie auch, wenn die ISR lang ist. Da geht dann halt ein 
Interrupt verloren. Soweit kein Unterschied... Wobei ein System, bei dem 
Interrupts verloren gehen, mMn schon einen Designfehler hat.

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Auf dem Cortex-M kann man schließlich auch die
> ISR durch wichtigere Interrupts unterbrechen lassen durch Einstellung
> der Priorität.

So so, ist der STM auch so intelligent dass er seine aktuelle
ISR selbst unterbrechen kann um sie erneut abzuarbeiten?

Wenn die Rechnerei in der ISR so lang dauert dass schon wieder
ein IRQ daherkommt .....

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> So so, ist der STM auch so intelligent dass er seine aktuelle
> ISR selbst unterbrechen kann um sie erneut abzuarbeiten?

Ach so war das gemeint. Nein, das geht nicht. Das geht bei der typischen 
main-Schleifen-Verarbeitung so aber auch nicht, es sei denn man baut an 
allen Ecken und Enden Abfragen ein, ob die Berechnung abgebrochen werden 
soll. Die könnte man aber genauso in die ISR einbauen (Interrupt-Flag 
abfragen und dann einfach zurückkehren). Ist aber beides mMn ziemlich 
mies.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:

> Wobei ein System, bei dem
> Interrupts verloren gehen, mMn schon einen Designfehler hat.

ISRs als Worker zu mißbrauchen, IST ein Designfehler.

Autor: STM Apprentice (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Wenn die Rechnerei in der ISR so lang dauert dass schon wieder
> ein IRQ daherkommt .....

Wir kennen ja die Interrupt Gegebenheiten des TO nicht, aber
das ist wie beim AVR: wenn er zu lang in der ISR verharrt
wird er vor lauter Interrupts nicht mehr herauskommen und
"hängt" dann scheinbar ....

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> ISRs als Worker zu mißbrauchen, IST ein Designfehler.

Solange der selbe Interrupt nicht zu schnell wieder kommt, ist das 
überhaupt kein Problem. Das mache ich schon in einigen Projekten so und 
funktioniert wie gewollt - warum auch nicht?
In der ISR partout auf lange Verarbeitungen zu verzichten ist ein 
typischer Fall vom "Angry-Monkey-Syndrom" aka "das haben wir schon immer 
so gemacht". Bei uC's ohne Interrupt-Prioritäten wie dem AVR mag das 
sinnvoll sein, beim Cortex-M ist das aber hinfällig. Wenn man in der ISR 
nichts anderes macht als ein Flag zu setzen, kann man die ISR auch 
gleich komplett weglassen und einfach in der main() das Interrupt-Flag 
in der Peripherie abfragen - das ist gewiss nicht die Intention von 
Interrupts.

Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Dr. Sommer schrieb:
>
>> Wobei ein System, bei dem
>> Interrupts verloren gehen, mMn schon einen Designfehler hat.
>
> ISRs als Worker zu mißbrauchen, IST ein Designfehler.

Das ist mir zu dogmatisch.

Was man in einer ISR macht oder nicht, hängt vom Scheduling-Konzept 
Deines Programms ab. Da gibt es verschiedene Varianten und welche da 
Sinn machen hängt von den Möglichkeiten Deines µCs (ISR-Prioritäten 
möglich ja/nein, etc.) und vor allem aber den Anforderungen der 
Applikation ab.

Aber das schweift jetzt langsam vom Thema ab.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:

> Wenn man in der ISR
> nichts anderes macht als ein Flag zu setzen, kann man die ISR auch
> gleich komplett weglassen und einfach in der main() das Interrupt-Flag
> in der Peripherie abfragen - das ist gewiss nicht die Intention von
> Interrupts.

Offensichtlich (Stichwort 16 kHz) geht es dabei um Timing, und man 
verwendet deswegen ISRs, um die Meßwerte mit festem Raster zu erfassen. 
Kann man auch in der main machen, das wird dann aber deutlich 
frickeliger, mit Delays und all sowas.

Daß man die Meßwerte mit festem Raster erfaßt, bedeutet nicht, daß man 
auch gleich die ganze Signalverarbeitung drauf loslassen muß.

Und sich über Interruptprioritäten ein Multitasking-RTOS in Sparversion 
zu bauen, ist auch nicht gerade ein Design-Highlight. ^^

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.