In der zweiten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem ich mich ausnahmsweise mal selbst beschäftigt habe. Damit ich mich dazu nicht selbst ausfragen muss springt netterweise Chris als Gastinterviewer ein. Problem dieses mal ist ein Gerät, das dann und wann einfach neu startet, und wieder einmal könnte die Ursache sowohl in der Software als auch in der Hardware zu finden sein. Es folgt eine Suche durch die verschiedenen möglichen Ursachen für Neustarts von Geräten, die uns an Watchdogs, Übertemperatur, den Eigenheiten von PoE, WAD pins und Dioden vorbei zur Lösung führt. Und wieder einmal steht die Größe der Änderung in keiner Relation zur vorherigen Suche.
In der zweiten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem ich mich ausnahmsweise mal selbst beschäftigt habe. Damit ich mich dazu nicht selbst ausfragen muss springt netterweise Chris als Gastinterviewer ein. Problem dieses mal ist ein Gerät, das dann und wann einfach neu startet, und wieder einmal könnte die Ursache sowohl in der Software als auch in der Hardware zu finden sein. Es folgt eine Suche durch die verschiedenen möglichen Ursachen für Neustarts von Geräten, die uns an Watchdogs, Übertemperatur, den Eigenheiten von PoE, WAD pins und Dioden vorbei zur Lösung führt. Und wieder einmal steht die Größe der Änderung in keiner Relation zur vorherigen Suche.
In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann. So auch in der Welt der Software. In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen. Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch auftretenden Geistern im System führt, um bröckelnde Software, deren Quellcode schon vor Jahren verloren gegangen ist, und manchmal auch um ganz was anderes.
Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken orientieren:
00:00 Chris und Leonard fachsimpeln über LoRa, Gatways und Minimum Viable Products. Es soll ein Prototyp eines LoRa Gateways gebaut werden um die Anforderungen und Problemstellungen kennenzulernen. 08:40 Wie entwickelt man Software für ein eingebettetes System? Hersteller-BSP/-Kernel/-Bootloader vs. Mainline - Vor- und Nachteile. Was unterscheidet Yocto von "normalen" Linux-Distributionen? 12:15 LoRaWAN-Software Semtech Forwarder vs. Chirpstack. 13:40 Das eigentliche Problem - das Gerät läuft nicht durch sondern power-cycled nach zwei Stunden. 15:00 Möglicher Grund für neustartendes System: 1. Ein Watchdog schlägt zu und startet es neu. 27:30 Möglicher Grund für neustartendes System: 2. Die CPU/ein anderes IC schaltet wegen Übertemperatur ab 30:15 Möglicher Grund für neustartendes System: 3. Sich falsch verhaltender PoE-Injector 34:15 Auf den PoE-Leitungen zeigen sich komische Effekte wie z.B. dann und wann einbrechende Versorgungsspannung. Aber: das periodische Neustarten tritt auch auf wenn die PoE-Spannung aus einem stabilen Netzteil kommt. 39:00 Der PoE-IC auf dem Gerät selber schaltet die Versorgungsspannung ab. 42:15 Ursache des Abschaltens ist der WAD (Wall Adapter) Pin des PoE-IC, der bei angeschlossenem Netzteil die PoE-Versorgung abschalten soll. Allerdings ist kein Netzteil angeschlossen. 49:15 Grund für die Spannung am WAD-Pin ist das Aufladen der Eingangskapazität über rückwärts durch eine Diode fließenden Leakage-Strom. Durch einen Widerstand nach GND kann der Leakage-Strom abgeleitet werden. 57:00 Meldung an den Hersteller. Der WAD-Pin und einmal dort gewesener Widerstand nach GND wird im Changelog der Boardrevision erwähnt, die wir haben. Der Widerstand wurde bewusst entfernt. 60:00 Abschluss. Wieder einmal hat sich gezeigt: "Always check your voltages". Erst die Spannungsversorgungen anschauen bevor man nach komplexeren Problemen sucht.