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:
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
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.
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.
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.
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.
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
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".
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
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.
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.
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.
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.
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
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.
Thread beobachten
Seitenaufteilung abschalten