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...
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
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.
.... 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.
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.
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 ;-)
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 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".
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.
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.
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.
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.
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...
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.
