Debuggen des Bare-Metal-STM32 der siebten Ebene der Hölle

Hier ist eine nicht ganz so kurze Geschichte über die Behebung eines Problems, das manchmal ärgerlich, unmöglich, unglaublich schwierig, frustrierend und insgesamt einfach eine schreckliche Zeit mit der bloßen STM32G4-Firmware für den bürstenlosen Moteus-Motorcontroller war.< / p> Hintergrund

Zunächst etwas Kontext:

moteus führt eine Reihe von Tests mit jeder Firmware-Version durch. Es gibt Komponententests, die mit Firmware-Teilen ausgeführt werden, die für die Ausführung in einer Hostumgebung kompiliert wurden. Es gibt eine Hardware-in-the-Loop-Dynamometer-Testvorrichtung, mit der eine separate Testbatterie ausgeführt wird. Es gibt auch einen End-of-Line-Tester, der verwendet wird, um Tests auf jeder Karte und andere Leistungstests auf Firmware-Ebene durchzuführen.

Aufgrund all dieser Tests sind wir zuversichtlich genug, neue Firmware-Images zu veröffentlichen, sobald alle Tests bestanden sind, und versuchen, Karten mit Firmware auszuliefern, die innerhalb von ein oder zwei Wochen auf allen Karten und Geräten, die auf den Markt kommen, ist Tür. Allerdings wird darauf geachtet, dass Großaufträge alle die gleiche Firmware haben. Meine Saga begann also, als ich ein paar Dutzend Platinen mit der End-of-Line-Testvorrichtung neu programmierte, damit sie alle mit der neuesten Version übereinstimmten.

Das erste Symptom

Als ich ging, um sie neu zu programmieren, bestand ein großer Teil der Platinen die Tests für die Qualität der Strommessungen nicht, was darauf hindeutet, dass die Strommessungen zu viel Rauschen aufwiesen, insbesondere wenn die Stromführung 0 war Es gab Lötprobleme auf der Platine, oder die Testvorrichtung hatte korrodierte Kontakte oder möglicherweise Firmware-Probleme. Als Reaktion darauf wurden die Kontakte des Testgeräts sehr sorgfältig gereinigt, ich überprüfte, dass dies bei vielen Boards passierte, die alle zuvor bestanden hatten, und es gab nur 3 Änderungen, die die Firmware in irgendeiner Weise beeinflussten, was harmlos genug erschien. /p>

Sobald ich losgelassen hatte, dass das Problem ein Zufall war, öffnete ich tview auf dem End-of-Line-Fixture und tatsächlich, wow, da war ein Problem:

Beachten Sie, wie die Werte in servo_stats.adc_cur3_raw zwischen dem scheinbaren wahren Wert und 2048 zu schwanken scheinen. Ich habe solche Probleme schon früher gesehen, im Zusammenhang mit der ADC-Konfiguration und der Taktrate andere), aber an der ADC-Konfiguration hat sich vor über einem Jahr absolut nichts geändert, also kann es das nicht sein, oder?

Die erste Stufe der Diagnose

Also erstmal. Jetzt, wo ich ein Problem beobachten kann, ist es reproduzierbar. Ich habe git bisect in den entsprechenden Firmware-Versionen verwendet, und tatsächlich korrelierte eine der Änderungen positiv mit dem Problem: 64f2a82575795d782ff3806ea2036f4cd2f02ef0 Diese Änderung bringt jedoch absolut nichts ...