BongoListe

Haken und Ösen

Während der Entwicklung der Schaltung sind einige Haken und Ösen aufgetaucht, die es zu lösen galt. Diese sind hier mal aufgelistet.

SPI Master Select

Bei der ersten Kommunikation über CAN-Bus hatten wir das Problem, dass nach einigen Sekunden jeglicher Verkehr zusammenbrach. Nur ein Reset konnte die Kommunikation wiederbeleben. Eine Vermutung lag in der Ursache der SPI-Kommunikation. Ein Blick ins Datenblatt des ATmega brachte schnell die Lösung: Wird ein ATmega als SPI Master programmiert, muss der Pin /CS als Ausgang konfiguriert werden. Wird er als Eingang konfiguriert, kann der ATmega von außen als Slave umkonfiguriert werden. Genau das ist passiert. Der Pin /CS war nicht beschaltet und obendrein als Eingang konfiguriert. Somit war es ein offener Eingang, ohne Pull-Up-Widerstand. So war der Zustand undefiniert und hat früher oder später den ATmega in SPI-Slave-Modus gebracht. da für den MCP sowieso ein /CS-Pin gebraucht wurde, musste nur die Verbindung umgestöpselt werden.

Problem gelöst

PCA braucht unterschiedliche Widerstände für unterschiedliche CAN-Busgeschwindigkeiten.

Das Problem ist nicht wirklich aufgetaucht. Das liegt aber eher daran, dass nur zwei CAN-Knoten über 10cm miteinander kommuniziert haben. Tatsächlich wäre das Problem höchstwahrscheinlich unter der Eisenbahnanlage aufgetaucht, wo mindestens ein Dutzend Knoten miteinander kommunizieren müssen. Außerdem war die Geschwindigkeit noch bei ungefährlichen 250 kbit/s. Der gewählte Widerstand sorgt für die Flankensteilheit und somit für ein sauberes Signal. Ein entsprechend gewählter Widerstand erhöht die Zuverlässigkeit.

Problem gelöst

CAN-Knoten stürzt ab

Mit der Eisenbahn-Firmware lief diese nur wenige Sekunden. Danach konnte der Knoten nur durch Aus- und Einschalten wiederbelebt werden. Eine erste Vermutung lag darin, dass vielleicht die Spannugnsregler überlastet sind. Das hat sich aber nicht bestätigt. Denn das Gateway arbeitete einwandfrei. Eine weitere Vermutung brachte die Ursache: Durch eine Race-Condition wird Datenmüll in den MCP geschrieben. Dieser konfiguriert den CLKOUT-Ausgang aus. Dadurch hat der ATmega keinen Takt mehr. Auch nicht nach einem Reset, denn dieser betrifft nicht den MCP. Somit kann nur durch Aus- und Einschalten der Takt reaktiviert werden. Erste Lösung war, dem ATmega einen eigenen Quartz zu spendieren, um wieder arbeitsfähig zu werden. Die zweite und wichtigere Lösung war, die Race-Condition zu finden, um eine saubere Kommunikation mit dem MCP zu gewährleisten. Einige fehlende cli()/sei()-Pärchen lösten das Problem.

Problem gelöst

CAN-Frames gehen verloren

Das war ein Effekt, der nur beim Konfigurieren reproduzierbar auftrat. Eine schnelle Lösung sah vor, an den richtigen Stellen Delays einzufügen. Das kann aber nicht die Lösung sein, denn das Problem wäre im Verbund mit Sicherheit wieder aufgetaucht. Die Lösung bestand darin. Sämtliche CAN-Frames zum Versenden und Empfangen in einen Interrupt-sicheren Ringpuffer zu schreiben. Das Software-Modul wird sowohl für die Firmware, als auch für das Gateway verwendet.

Problem gelöst

CAN-Knoten verliert Firmware nach Stromausfall

Der ATmega hat einen Bootloader, über den mittels CAN-Frames die Firmware geflasht werden kann. Das funktioniert soweit gut, allerdings verliert der ATmega nach einem Stromausfall seine Firmware. Der Bootloader bleibt erhalten. Vermutlich ist die Flash-Sequenz nicht ganz korrekt. Bei einem Hardware-Fehler würde der Bootloader ebenfalls betroffen sein. Laut ATmega-Datenblatt auf Seite 252 unten kann eine schlechte Spannungsversorgung zu seltsamen Effekten im Programmierregister führen. Dadurch kann Flash und EEPROM versehentlich programmiert werden. Ein Umstecken des Spannungsreglers hat Abhilfe geschaffen, da er nicht sauber vom Gateway getrannt war. Bei den produktiven Schaltungen wäre das Problem vermutlich nicht aufgetaucht, da dort die Spannunsregler sowieso räumlich getrennt sind.

Nach zwei Wochen intensiver Nutzung ist das Problem nicht mehr aufgetaucht: Problem gelöst

CAN-Konfiguration wird nicht beendet

Eine Konfiguration von vier Weichen und einem Gleis ist diese korrekt erfolgt. Nach generierter Konfiguration werden scheinbar CAN-Frames verloren. Erste Hinweise schienen so auszusehen, dass die Frames gar nicht erst über das Gateway liefen. Ein Flood-Ping hat ergeben, dass 500 Pings korrekt mit 500 Pongs beantwortet werden. Erst darüber scheint ein Überlauf stattzufinden und die Rate bricht ein. Die Konfiguration mit 51 Frames zum Senden und 11 erwarteten Antwort-Frames sollte daher kein Problem darstellen. Das Gateway scheint also nicht das Problem darzustellen, es muss am CAN-Knoten liegen.

Eine Verhinderung des Watch Dog Resets wurde deaktiviert. Trotzdem löst der WDT einen Reset aus. Es scheint, dass der WD keinen Reset erfährt. Durch Zufall ergab das Log der "kurzen" Konfiguration, dass das Kommando CFGEND etwa 700 ms für das Speichern von fünf Geräteeinheiten braucht. Bei der generierten Version werden aber acht Einheiten im EEPROM gespeichert. Das ist zu lang für den WD. Ein Abschalten in den EEPROM-Save-Routinen löst das Problem.

Und vor Allem: Es gehen keine CAN-Frames verloren. Das ist gut, weil das einfach nicht passieren darf! Somit ist wohl auch das hier beschriebene Problem endlich vom Tisch!

Problem gelöst