ARM-Controller zerschossen?

[ZwergNase]

Guten Abend zusammen,

bei der Suche nach einem Fehler habe ich im laufenden Betrieb (also Busspannung lag an) einige Controller (LPC1115_4TE_TOP V1.1) von meinen ou6_cs Aktoren getauscht.
Jetzt habe ich vier Controller die offenbar nicht mehr über den Bus kommunizieren:

• Flashen
• Handbedinung, Relais
• Prog-LED/Taster
• Programmieren über ETS
• Programmiermodus erkenne
• Geräteinfo mit ETS auslesen

Im Nachhinein glaube ich, war das stecken der Platine (Verbinder P1) eine schlechte Idee weil die Schutzdiode SMAJ40C ja auf der untersten Platine bestückt ist. Bin da leider nicht so fit, aber kann es sein, dass L2 beim "abziehen" EIB Eingangs- bzw. Ausgangsstufe zerstört? Evtl. sogar gleich den Port am ARM?
Tauschen von Q1, Q2 und Q3 hat leider keine Besserung gebracht. Ich fürchte der ARM ist hin und den habe ich bisher noch nie wirklich vernünftig ausgelötet bekommen.

Hat noch jemand eine Ideen oder Vorschläge wie ich weiter vorgehen kann oder kann zumindest jemand meinen Verdacht bestätigen?

Vielen Dank für Vorschläge,
Oliver

[Doumanix]

Hi Oliver,

ich dachte eigentlich, dass der LPC111x robuster ist als der LPC922. Von letzterem hatte Hans ja schon vor langem dokumentiert, dass man das Abziehen des Kabels im Betrieb unterlassen sollte.

Ob das wirklich deine LPCs zerstört hat, kann ich nicht beurteilen ... aber was auslöten / einlöten angeht, kann ich dir ggf. behilflich sein. Kannst dich ja mal wieder direkt melden.
Mit ner Heißluftpistole an der Rework-Station geht das eigentlich recht zuverlässig. Kommt halt auch auf deine Platinen an. Einmal wieder raus und rein geht oft gut. Mehrfach rumfummeln endet gern in kaputten Pins auf dem Board. Ich hatte mal eines, da hab ich den Fehler einfach nicht gefunden und hab dreimal am LPC rumgefummelt. Sah echt gruselig aus danach und war definitiv Müll...

Gruß
Christian

[suttermichi]

Hi.

Ich hatte letztens auch einen ARM zerschossen (blöderweise beim experimentieren und testen an der Pinleiste EIB+ auf einen Pin gehängt...)

Was das auslöten angeht, kann ich dir auch die Heissluftvariante empfehlen.

Ich habe das sogar einfach mit einer Heissluftpistole vom Discounter gemacht. Du musst nur aufpassen dass es dir die kleineren Bauteile nebendran nicht auslötet und gleich wegpustet. Aber sonst funktioniert es tiptop um alle Pins gleichzeitig aufzuheizen und dann den uC wegnehmen!


Lg Michi

[Florian]

Das Stecken oder Ziehen von P1 unter Spannung ist in der Tat eine schlechte Idee. Das Problem ist die zufällige Reihenfolge, in der die verschiedenen Signale am Stecker kontaktieren. Wenn erst EIB+ & diverse Signale kontaktiert werden und danach erst GND, dann liegen kurzzeitig undefinierte Spannungen auch oberhalb vom erlaubten Bereich an den IOs.
L2 ist gar nicht so das Problem, D14 stellt einen Strompfad bereit, wenn plötzlich die Verbindung am EIB-Eingang wegfällt. Noch fließender Strom wird von C3 abgepuffert.

Mich verwundert allerdings, das Du sagst, die Handbedienung geht. Verstehe ich das also richtig: Du kannst mit den Tasten die Relais schalten und die LEDs zeigen das auch an? Das würde heißen, das ziemlich viel funktioniert: Die Messung der Ladespannung der Elkos, die SPI-Kette zu den Relais-Treibern, Tasterabfrage und LEDs. Merkt sich der Controller den Schaltzustand der Relais über Power-Cycles hinweg?

Daher frage ich sicherheitshalber nach: Die jetzt scheinbar defekten Controller haben vorher funktioniert? Hast Du schon mal erfolgreich Kontakt zur ETS mit denen aufgebaut?

Als erste Wiederbelebungsversuche schlage ich vor, dass Du die uC nochmal vollständig löschst (Erase all Flash+Code Rd Prot) und neu programmierst. Unter Flash Magic darf die Option "Fill unused Flash" NICHT angehakt sein.

Und: Wie ist die Stromaufnahme vom Aktor im Betrieb? Wenn ich mich richtig erinnere, liegt sie direkt nach dem Einschalten um die 20mA (Aufladen der Elkos) und geht dann auf rund 5mA zurück. Nur so von der Größenordnung, die genauen Werte habe ich nicht im Kopf. Nach jedem Schaltvorgang steigt der Strom kurz wieder.

Ist der Widerstand R30 mit 5,6Ohm noch intakt? Bitte nachmessen!

[ZwergNase]

Guten Abend und vielen Dank für Eure Vorschläge!

@Florian: Ja, Relais lassen sich per Hand schalten und zeigen das auch an. Den Schaltzustand merkt sich der Controller nicht (komisch, oder?). Wenn die Busspannung wiederkehrt, sind alle LEDs aus und sobald die ELKOs geladen sind, schalten die Relais auch auf aus.

Die Controller hatte ich alle nach dem Aufbau geflasht, adressiert und zum Test alle Kanäle per KNX einmal durchgeschaltet. Zwei der vier Controller waren bereits voll im Einsatz.

Beim erneuten Flashen am Wochenende hatte ich in der Tat den Hinweis "Fill unused Flash nicht anhaken" vergessen. Jetzt bin ich vorgegangen wie von Dir beschrieben, leider ohne Erfolg.

Die Stromaufnahme liegt bei allen Controllern bei maximal 19-20mA. Im Ruhezustand allerdings (nur Power-LED an) sind es bei mir durch die Bank 10mA. R30 ist überall intakt. Wegen dem erhöhten Strom hatte ich vermutet, dass auch im Ruhezustand ein Strom durch R30 fließt, dem ist aber nicht so (Spannungsabfall über R30 0V).

Ich habe aus den Beispiel-Anwendungen bei der sblib dieses Beispiel mal geflasht und weiß jetzt zumindest schon mal, dass alle Controller KNX empfangen (Pin EIB_IN ist Ok).

Morgen wollte ich C17 ausbauen und ein kleines Programm schreiben, das EIB_OUT "blinken" lässt. Dann weiß ich endgültig ob der ARM einen Schlag hat oder nicht...

Ich Bericht

Schöne Grüße,
Oliver

[Florian]

Das wird alles immer merkwürdiger.

Dass sich Deine auffälligen Controller den Schaltzustand nicht merken können, deutet auf Probleme beim Abspeichern des Systemzustands hin. Ein Busspannungsausfall wird normalerweise früh genug erkannt und dann werden die Zustände abgespeichert.
Eine Ursache für Probleme beim Abspeichern können korrupte Verwaltungsinformationen der MemMapper-Unit sein, die für das Abspeichern des Systemzustandes und auch Teile der KNX-Konfiguration zuständig ist. Daher mein Rat mit "Fill unused Flash" nicht wählen und "Erase all Flash" wählen. Genau dabei werden nämlich die Verwaltungsinfos wieder auf den Ursprungszustand zurückgesetzt.

Kannst Du bitte in FlashMagic die Speicherbereiche angucken, wo der MemMapper seine Daten ablegt: "Display Memory..." ab Adresse 0xEA00 bis 0xEFFF. Hier sollten viele, viele FF-Daten stehen und nur wenige andere. Wenn hier nur Nullen stehen, ist der Speicher nicht gelöscht worden. Mach bitte mal einen Screenshoot der angezeigten Daten direkt nach 0xEA00.

Hast Du die rote LED auf dem Controller bestückt, die bei Stromversorgung leuchtet? Ein Experiment: Schalte einen (oder mehrere) Kanäle ein, schalte dann die Busspanungsversorgung ab. Was passieren sollte: Nach einer ganzen Weile geht die grüne Kanal-LED aus. Ungefähr 3 Sekunden danach erst geht die rote LED aus. Das zeigt, dass die Busspannungsmessung korrekt funktioniert und der Controller den drohenden Spannungsverlust rechtzeitig bemerkt.

Der Programmer sollte bei den Experimenten nicht angeschlossen werden.


Zu den Stromwerten, ich habe gerade nochmal nachgemessen:
Beim Ladevorgang: 21mA Idle: Um die 10mA
Also sind Deine Messungen vollkommen normal.

[ZwergNase]

Hallo Florian,

ich habe zunächst gelöscht. Dann ist tatsächlich der ganze Speiche mit FF gefüllt. Nach dem Flashen sieht der Speicher ab EA00 aus wie im Screen-Shot "nach Prog".
Dann habe ich den Aktor an den Bus angeschlossen, drei Kanäle eingeschaltet (LEDs an, Relais haben geschaltet) und die Busspannung abgeschaltet.
Wie Du beschrieben hast, gehen erst die grünen LEDs aus und 2-3 Sekunden später die rote Power-LED.
Danach sieht der Speiche raus wie im zweiten Screen-Shot. Ich habe drei veränderte Bytes markiert.

Ich hatte inzwischen ein kleines Test-Prg geflasht um den EIB-Out Pin zu prüfen. Der funktioniert ebenfalls. Die Ausgangsstufe vermutlich auch, das "blinken" vom Pin war zu langsam um mit dem Oszi ordentlich zu messen. Da muss ich morgen noch mal ran...

Hilft vielleicht die Debug-Version von Deiner Software? Ich habe einen Serial-USB Adapter hier...

Eine Sache habe ich noch:
Im Sourcecode habe ich den Hinweis gefunden mit Optimierung O3 zu kompilieren.
Ob ich das damals gemacht habe, weiß ich nicht mehr... momentan streikt allerdings mein Compiler und ich benutze nach wie vor meine hex von vor einem Jahr. Allerdings auch in 11 weiteren Aktoren die seit einem Jahr erfolgreich laufen...
Kannst Du mir zur Sicherheit bitte trotzdem eine hex schicken mit der ich noch eimal testen kann?

Vielen Dank für Deine Hilfe,
Oliver

Dump nach Inbetriebnahme mit 3 geschalteten Kanälen

nach Start.png (93.46 KiB) 7290 mal betrachtet

[Florian]

Deine Ausschnitte aus dem Speicher sehen für mich vollkommen normal aus. Ich musste mich gerade erst mal wieder einlesen, aber die Verwaltungsdaten in den ersten 256 Byte sehen gut aus, genauso wie die 2*256 folgenden Daten. Auch Deine Beschreibung vom Verhalten ist Ok. Also hat uns das dem Problem überhaupt nicht näher gebracht. Warum der anscheinend korrekt abgespeicherte Schaltzustand nicht wieder geladen wird - dafür habe ich momentan keine Erklärung.

Im Anhang findest Du Bus_Mon.hex (gezipped), ein Programm nur mit Debugausgabe, ohne sonstige Nutzfunktion. Es sollte alle empfangenen und gesendeten Pakete auf der seriellen Schnittstelle ausgeben. Als Sonderfunktion werden auch beschädigte empfangene Pakete ausgegeben, die werden normalerweise verworfen. Ich kann das Programm gerade nicht ausprobieren - ich hoffe mal, dass es noch so funktioniert wie in meiner Erinnerung. Es sollte möglich sein, dem Bus_Mon-Device eine Adresse zuzuweisen und den Gerätestatus abzufragen. Es ist ein BIM112, aber im Grunde ist das egal.

Das Hex des Schaltaktors findest Du im Git:
https://github.com/selfbus/software-arm ... bim112.hex

[ZwergNase]

Meine Controller laufen wieder!

Nachdem ich die Controller mit dem Memory-Dump eines funktionierenden und in der ETS vollständig programmierten Controllers geflash habe, scheint wieder alles gut.

Weil ich mir keinen Reim darauf machen kann und um auszuschließen, dass das beobachte Problem nur mein Hirngespinst war, habe ich mit vier Controllern die folgende Prozedur durchgeführt:

1. mit FlashMagic (FlashMagic: 12.30 build 5883) Speicher vollständig gelöscht
2. HEX von GitHub programmiert, Haken „Fill unused Flash“ nicht gesetzt
-> Symptome wie oben beschrieben

3. mit Memory-Dump aus vorhandenem Controller geflasht
-> alle Probleme weg

Diese Schritte kann ich offenbar beliebig wiederholen. Nach 1. & 2. zeigen die Controller das beschriebene Problem. Nach 3. scheint wieder alles gut…

@Florian: Ich habe noch zwei Controller übrig behalten, falls Du noch eine Idee hast und das Thema vertiefen möchtest. Ich bin ratlos…

Schöne Grüße,
Oliver

[Florian]

Kannst Du bitte einen funktionierenden und einen nicht funktionierenden Controller auslesen und die HEX-Dateien hier einstellen. Dann kann ich die beide vergleichen. Vielleicht kommen wir so einer Lösung näher.

Welche ETS-Version benutzt Du?