Forum: Mikrocontroller und Digitale Elektronik Tipps zum Vorgehen bei der Fehlersuche STM32F103 E-Bike-Controller


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 hochsitzcola (Gast)


Lesenswert?

Ich kämpfe gerade mit einem unschönen Phänomen bei meiner offenen 
Firmware für Lishui EBike-Controller.
Diese Controller gibt es in den verschiedensten Platinenlayouts, die 
Funktionalität ist aber immer die Gleiche.
https://github.com/EBiCS/EBiCS_Firmware/wiki

Jetzt habe ich eine sehr kompakte Controllervariante, die aus zwei 
aufeinandergesteckten Platinen besteht, bei der die Firmware leider 
zicken macht. Nach einer undefinierten, nicht reproduzierbaren Zeit 
scheint die Hauptschleife nicht mehr abgearbeitet zu werden, der 
Prozessor scheint aus den Interrupts nicht mehr herauszukommen. Das 
äußert sich darin, daß der Motor weiter läuft, der Controller aber auf 
keine Benutzeraktionen mehr reagiert. Das ist für den Fahrer natürlich 
nicht schön, wenn er nur noch Passagiert ist :-)
Ich habe das jetzt durch den Watchdog aufgefangen, so daß der Prozessor 
resettet, wenn das passiert, schöner wäre es natürlich, wenn man die 
Ursache bekämpfen könnte. Da das Problem bei allen anderen 
Layoutvarianten bisher nie aufgetreten ist, hab ich zuerst an ein 
EMV-Problem aufgrund dieser zweistöckigen Bauweise gedacht.
Wie kann man so einen nicht reproduzierbaren Bug am besten Debuggen? Der 
Debugger der STM32-Workbench steigt leider auch immer nach einigen 
Sekunden aus, wenn der Motor auf dem Rollentrainer mit ordentlich Last 
dreht.
Ich habe mir auch schon mit dem Oszi die Dauer der verschiedenen 
Interrupt-Routinen angeschaut und sehe auch, daß einzelne Routinen ab 
und zu deutlich länger brauchen als sonst, kann daraus aber nicht 
ableiten, woher die längere Dauer kommt...

Die Interrupts sind derzeit so konfiguriert:
1
HAL_NVIC_SetPriority(DMA1_Channel1_IRQn, 0, 1); //DMA ADC1
2
HAL_NVIC_SetPriority(ADC1_2_IRQn, 0, 0); //ADC1+2
3
HAL_NVIC_SetPriority(MemoryManagement_IRQn, 1, 0);
4
HAL_NVIC_SetPriority(BusFault_IRQn, 2, 0);
5
HAL_NVIC_SetPriority(UsageFault_IRQn, 2, 0);
6
HAL_NVIC_SetPriority(SVCall_IRQn, 1, 0);
7
HAL_NVIC_SetPriority(DebugMonitor_IRQn, 2, 0);
8
HAL_NVIC_SetPriority(PendSV_IRQn, 1, 0);
9
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
10
HAL_NVIC_SetPriority(RCC_IRQn, 3, 0);
11
HAL_NVIC_SetPriority(TIM1_UP_IRQn, 1, 0);
12
HAL_NVIC_SetPriority(TIM1_TRG_COM_IRQn, 0, 0);
13
HAL_NVIC_SetPriority(TIM1_CC_IRQn, 0, 0);
14
HAL_NVIC_SetPriority(TIM2_IRQn, 0, 1); //Motor Halls
15
HAL_NVIC_SetPriority(TIM3_IRQn, 3, 0);
16
HAL_NVIC_SetPriority(USART1_IRQn, 3, 1);
17
HAL_NVIC_SetPriority(DMA1_Channel5_IRQn, 3, 1); //DMA UARTRx
18
HAL_NVIC_SetPriority(DMA1_Channel4_IRQn, 3, 1); //DMA UARTTx
19
HAL_NVIC_SetPriority(EXTI9_5_IRQn, 2, 0); //Speed and PAS sensors
20
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

Ich kann mir aber auch nicht recht vorstellen, daß es an der Interrupt 
Priorisierung liegt, auch wenn ich damit etwas rumexperimentiert 
habe....

Hat jemand einen Tipp, wie man sich hier systematisch der Problemlösung 
nähern kann?

Gruß
hochsitzcola

von weiter weg (Gast)


Lesenswert?

hochsitzcola schrieb:
> Hat jemand einen Tipp, wie man sich hier systematisch der Problemlösung
> nähern kann?

Deine unzureichend geschützte Hardware so aufbauen dass sie nicht 
gestört werden kann.

von weiter weg (Gast)


Lesenswert?

hochsitzcola schrieb:
> https://github.com/EBiCS/EBiCS_Firmware/wiki

Zitat von dort:

Caution: all of this project is highly experimental and all you are 
doing is on your own risk!

von weiter weg (Gast)


Lesenswert?

hochsitzcola schrieb:
> Wie kann man so einen nicht reproduzierbaren Bug am besten Debuggen?

Der Fehler liegt vermutlich an R42 deiner Schaltung.

von Martin S. (martinst)


Lesenswert?

hochsitzcola schrieb:
> Der Debugger der STM32-Workbench steigt leider auch immer nach einigen
> Sekunden aus, wenn der Motor auf dem Rollentrainer mit ordentlich Last
> dreht.
Ist die Spannung vom Controller stabil?
Der Debugger sollte nicht aussteigen. Dann kann man auf den Bug warten.

von weiter weg (Gast)


Lesenswert?

Martin S. schrieb:
> Der Debugger sollte nicht aussteigen

Tut er auch nicht. Sondern seine Controller Hardware "steigt aus".

von hochsitzcola (Gast)


Lesenswert?

Martin S. schrieb:
> Ist die Spannung vom Controller stabil?

Beim Debuggen wird der Prozessor ja zusätzlich über den STLink mit 
Spannung versorgt. Daran sollte es also nicht liegen.

weiter weg schrieb:
> Deine unzureichend geschützte Hardware

Das ist ja keine selbstentwickelte Hardware sondern ein kommerzielles 
Produkt.
Lishui bietet diese Controller in den verschiedensten Bauformen an und 
nur der LD-LS05-F macht Probleme....
https://www.lsdzs.com/ls_product/product.php?lang=en&class2=19

https://www.lsdzs.com/ls_product/showproduct.php?lang=en&id=86

Gruß
hochsitzcola

von mitlesa (Gast)


Lesenswert?

hochsitzcola schrieb:
> Beim Debuggen wird der Prozessor ja zusätzlich über den STLink mit
> Spannung versorgt.

Voll der Käse. Ein ST-Link bietet keine Versorgung sondern
testet die Spannung des zu bearbeitenden Controllers.
Die Annahme dass ein Debugger ein Target vollwertig mit
Spanung versorgt zeugt von maximaler Ahnungslosigkeit.
Von stabiler Versorgung kann keine Rede sein, selbst wenn
es einen Debugger gibt der eine Versorgung liefern kann.

hochsitzcola schrieb:
> Das ist ja keine selbstentwickelte Hardware sondern ein kommerzielles
> Produkt.

Und deshalb hat es garantiert keine Macken bzw. Fehler?
Träum schön weiter.

hochsitzcola schrieb:
> nur der LD-LS05-F macht Probleme....

.... und du kannst deinen Anteil daran haben dass er problemlos
funktioniert oder eben mit Macken läuft. Der/die Fehler sitzen
auf dem Board bzw. vor deinen Bildschirm.

von temp (Gast)


Lesenswert?

Ich kenne ja deine Entwicklungsumgebung nicht, aber wenn man wie ich das 
Segger Embeddet Studio nimmt und einen jlink, dann kann man selbst in 
dem festgefahrenen Zustand den jlink verbinden und dann das Programm 
unterbrechen. Da sieht man dann wenigstens wo er (meistens in der 
Hardfault-Loop) hängt. Ob das mit dem stlink und deinem Debugger geht 
weiss ich nicht. Oder nur den Ozone-Debugger von Segger benutzen sollte 
auch gehen.

von hochsitzcola (Gast)


Lesenswert?

mitlesa schrieb:
> Ein ST-Link bietet keine Versorgung sondern
> zeugt von maximaler Ahnungslosigkeit.

Ich liebe dieses Forum, man trifft immer wieder auf herzliche 
Artgenossen.
Ich bin kein Profi, aber die Behauptung, der STLink könne das Target 
nicht mit Spannung versorgen, zeugt nicht gerade von tiefem know how ;-)

temp schrieb:
> meistens in der Hardfault-Loop

Würden denn dann die Interrupts weiterlaufen? Der Motor läuft ja sauber 
weiter, die Kommutierung funktioniert ja also offensichtlich noch.

Auf JLink und Segger umzusteigen würde für mich wahrscheinlich ein 
Vierteljahr Einarbeitung bedeuten. Nur um festzustellen, daß der Code im 
Hardfault-Loop hängt?!

Gruß
hochsitzcola

von mitlesa (Gast)


Lesenswert?

hochsitzcola schrieb:
> Ich bin kein Profi, aber die Behauptung, der STLink könne das Target
> nicht mit Spannung versorgen, zeugt nicht gerade von tiefem know how

Aha, also nicht nur voll ahnungslos sondern auch noch massiv
beratungsresistent.
Schau in das Datenblatt deines ST-Link, vielleicht lässt du
dich wenigstens damit "beraten".

von hochsitzcola (Gast)


Lesenswert?

mitlesa schrieb:
> massiv beratungsresistent.

Allein, das ich hier immer wieder Fragen stelle, obwohl ich weiß, daß 
ich hier gern von vermeintlich Allwissenden beschimpft werde, zeugt wohl 
schon vom Gegenteil ;-) Glücklicherweise gibt es hier ja auch User, die 
in freundlich helfen.

Ein klassisches "Datasheet" zum STLink kenne ich tatsächlich nicht und 
in dem User Manual steht nichts zu Belastbarkeit von Pin 1 und 2, da 
steht lediglich als Function Target VCC für den STLink.
https://www.st.com/resource/en/user_manual/um1075-stlinkv2-incircuit-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf

Meine Erfahrung zeigt: Mit der Spannungsversorgung über den STLink lässt 
sich der Prozessor flashen und die Peripherie wie UART, ADC etc. 
betreiben.

Ich werde auf jeden Fall testen, ob der Fehler weiterhin auftritt, wenn 
ich extern stabilisierte 3,3V  auf VCC gebe.

Gruß
hochsitzcola

von hochsitzcola (Gast)


Lesenswert?

Korrektur, nicht Pin1 / 2 sondern Pin19 VDD 3.3V :-)

von Stefan F. (stefanus)


Lesenswert?

hochsitzcola schrieb:
> Beim Debuggen wird der Prozessor ja zusätzlich über den STLink mit
> Spannung versorgt. Daran sollte es also nicht liegen.

Normalerweise ist es anders herum. Der Debugger wird vom Target 
versorgt.

Außer man nimmt diese schrottigen China ST-Link Sticks, die das genau so 
falsch handhaben, wie deren USBASP Sticks. Die Chinesen kopieren sogar 
ihre Fehler mehr als 10 Jahre lang.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

hochsitzcola schrieb:
> Ein klassisches "Datasheet" zum STLink kenne ich tatsächlich nicht und
> in dem User Manual steht nichts zu Belastbarkeit von Pin 1 und 2, da
> steht lediglich als Function Target VCC für den STLink.

Und zwar deswegen, weil es nicht vorgesehen ist, das der Adapter eine 
Stromversorgung für das Target liefert.

Pin 1 und 2 sind in der Fußnote so beschrieben:

"The power supply from the application board is connected to the 
ST-LINK/V2 debugging and programming board to ensure signal 
compatibility between the boards."

Will sagen: Das application Board soll damit die Treiberstufen des 
ST-Link versorgen, damit die Spannungen auf der Schnittstelle zum 
application Board passen.

Pin 19 liefert hingegen eine Versorgungsspannung, aber nicht auf den 
isolierten Varianten des Adapters. Und außerdem soll er weder bei SWD 
noch bei JTAG verwendet werden. Da steht in den beiden Spalten eindeutig 
"Not connected".

Selbst wenn man Pin 19 verwenden wollte: Ohne Angabe wie viel Strom man 
da entnehmen darf, kann man damit nicht viel anfangen. Auf keinen Fall 
würde ich da einen kompletten Motor-Controller dran hängen.

: Bearbeitet durch User
von mitlesa (Gast)


Lesenswert?

Stefan F. schrieb:
> Und zwar deswegen, weil .....

Deine Romane helfen bei beratungsresistenten Personen nicht.

von temp (Gast)


Lesenswert?

hochsitzcola schrieb:
> Würden denn dann die Interrupts weiterlaufen? Der Motor läuft ja sauber
> weiter, die Kommutierung funktioniert ja also offensichtlich noch.
>
> Auf JLink und Segger umzusteigen würde für mich wahrscheinlich ein
> Vierteljahr Einarbeitung bedeuten. Nur um festzustellen, daß der Code im
> Hardfault-Loop hängt?!

Ich habe hier nicht davon gesprochen, dass das bei dir der Code im 
Hardfault hängt, das war nur ein Beispiel.
Solange du nicht mal deinen Debugger vernünftig zum Laufen bekommst, 
würde ich hier besser nichts mehr Fragen, die Gefahr sich lächerlich zu 
machen ist schon ganz schön groß.

Wir kennen keine einzige Zeile deines Codes oder haben nur in etwa eine 
Ahnung was du überhaupt wie in die Interrupts verteilst noch kennen wir 
sonst irgendwelche Details. Was soll uns das sagen "der Controller aber 
auf
keine Benutzeraktionen mehr reagiert"? Ich kann erahnen das das über 
UART passiert. Alle andern können raten. Liegt es daran dass das 
Hauptprogramm nicht mehr läuft, da helfen Blinkerspiele oder ist dein 
UART kaputt?

Ein immer mal wieder vorkommendes Problem ist das zu frühe Verlassen des 
Interrupts. So in etwa Interrupt Flag löschen und gleich return. Da ist 
es mir jedenfalls selbst schon unter gekommen, dass der Interrupt sofort 
wieder neu gestartet wird, weil das Rücksetzen des Interrupflags noch 
nicht in der Hardware angekommen ist. (Höher priorisierte Interrupts 
kommen in so einer Konstellation trotzdem noch dazwischen).
Oder wurde eine Flag gar nicht erst gelöscht? Alles möglich.
Hier wird dir sicher keiner helfen können ohne sich tiefer 
einzuarbeiten.
Aber wozu? Wenn selbst dein Debugger abschmiert sehe ich keine 
Möglichkeit einer systematischen Fehlersuche. Frohes Kaffeesatzlesen.

von Axel S. (a-za-z0-9)


Lesenswert?

hochsitzcola schrieb:
> scheint die Hauptschleife nicht mehr abgearbeitet zu werden, der
> Prozessor scheint aus den Interrupts nicht mehr herauszukommen.

Mußmaßungen ohne Grundlage.

Wenn du den Debugger schon angesteckt hast und der "aussteigt" (was auch 
immer das bedeutet) hast du wohl einen Fehler in der Hardware.

von hochsitzcola (Gast)


Lesenswert?

Danke für eure Rückmeldungen. Der Code ist Open Source und bei Github 
verfügbar, siehe Link im Eingangspost.
Ich bin Maschinenbauer. Die ganze Programmiererei mache ich (jetzt schon 
eine ganze Weile) learning by doing.
Die User-Interaktion passiert über digitale Eingänge für PAS (Pedal 
Assist Sensor, im wesentlichen ein Rechtecksignal) und Bremse. Analoge 
Eingänge für Gas-Signal, lineare Reku, Drehmoment an der Kurbel, sowie 
über UART (Display/Bedien-und Anzeige Panel).
Ich werde jetzt noch mal versuchen herauszufinden, warum der Debugger 
aussteigt...

Gruß
hochsitzcola

von Kevin M. (arduinolover)


Lesenswert?

Wenn das aussteigen nur passiert wenn der Motor angesteuert wird könnte 
das ein EMV Problem sein. Das sollte mit einem Oszi schnell 
herauszufinden sein.

Der tot bei solchen Störungen ist schlecht Kabelführung und zu lange 
Kabel am Debugger, da könntest du bei Bedarf als erstes ansetzen.

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]
  • [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.

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