ARM-Controller zerschossen?

[ZwergNase]

Endlich läuft das Forum wieder...
Meine vorherige Erfolgsmeldung war wohl doch zu früh. Aber ich glaube ich bin weiter gekommen. Muss am WE noch etwas testen, dann melde ich mich wieder.

Oliver

[ZwergNase]

So, kurz noch zur Erklärung: Ich habe hier (in München, bin WE-Pendler) einen Testaufbau und daheim (Koblenz) mein Produktiv-System. Unterschied war bis gestern die KNX-Schnittstelle. Jetzt habe ich auch für das Test-System eine Schnittstelle mit TPUART aufgebaut (knxd 0.14.29-5).

Nach erneutem, gewissenhaftem Test bleibt es bei den beschriebenen Sympthomen und das Problem scheint behoben. Lediglich der finale Test im Produktiv-System steht am WE noch aus. Unterschied wäre jetzt nur noch, dass deutlich mehr Geräte am Bus hängen als hier im Testaufbau.

@Florian: Ich habe eine Reihe von Memory-Dumps hier gesammelt. Lediglich 1. ist kein Memory-Dump sondern die von mir seinerzeit kompilierte hex.

Ich bin gespannt ob im Produktiv-System auch wieder alles läuft,

Oliver

[Florian]

Sehe ich das richtig, dass die Dumps 1, 2, 3 von einem nicht funktionierenden Controller stammen und 4, 5, 6, 7 von einem funktionierenden?

Die Dumps 4, 5, 6, 7 scheinen mit der Version vom 3.12.2017 im Git übereinzustimmen (wenn man die Bereiche ausnimmt, in denen Konfiguration etc abgespeichert sind). Also die erste im Git hinterlegte Version.

Die HEX-Files 1, 2, 3 sind merkwürdig. Sie bilden wieder eine Gruppe, stimmen aber mit keiner der beiden Versionen im Git überein. Die Daten sind insofern seltsam, als dass das Image wesentlich kürzer ist, als meine Versionen. Und ziemlich am Anfang sind über 240 Bytes einfach mal 0xFF, während in meinen Images dort bereits Daten enthalten sind. Hast Du beim Kompilieren damals irgendwelche Optionen verändert? Auf alle Fälle scheint das Ergebnis ja nicht zu funktionieren...

Ich habe keins der HEX-Files wirklich ausprobiert, nur die Inhalte betrachtet.

Du kannst gerne auch mal die aktuelle Version aus dem Git ausprobieren. Für den Fall dass Du irgendwann auf ETS 5.6 oder neuer upgraden willst...

[ZwergNase]

Hallo Florian!

Danke, dass Du Dir die Zeit nimmst und Gedanken zu meinem Problem machst!

Jain: Wenn ich Hex 1 auf eines meiner Problemkinder flash, funktionieren Handbedinung und Realis aber am Bus geht nix. Hex 2 ist der Dump direkt nach dem Flashen und Hex 3 ist der Dump nach Inbetriebnahme.

Hex 4 stammt von einem intakten, programmierten Gerät. Hex 5 ist wieder der Dump direkt nach dem Flashen auf eines der Problemkinder, Hex 6 nach Inbetriebnahme am Bus und Hex 7 nachdem ich mit der ETS die Adresse geändert habe.

Das Hex 1-3 eine Gruppe bilden ist klar, es ist ja immer der selbe Dump nur zu verschiedenen Zeitpunkten. Ich habe damals mit MCUxpresso selber kompiliert und (vermutlich) keine Optionen geändert.
Das gleiche Resultat wie mit Hex 1-3 habe ich auch mit der Hex aus Github.

Ich habe inzwischen folgenden Verdacht:
1. ich habe keine Hardware zerschossen, sondern
2. beim programmieren mit ETS schaffe ich es das Image zu zerstören
3. knxd oder das Interface haben ein Problem beim programmieren der Adresse, wenn noch nie eine Adresse vergeben war (evtl. das gleiche Problem, dass auch bei 2. das Image zerstört)

Ich probiere jetzt:
1. Test mit einem anderen Interface (will mir mein Eli die Tage leihen)
2. ich baue gerade weitere Controller, mal schauen ob sich brandneue Geräte auch so verhalten
3. wenn 1. was liefert, compiliere ich mal ältere knxd Versionen

Verschiedene ETS habe ich auch schon probiert (4.0, 5,5 und 5.6), immer das gleiche Bild...

Ich melde mich wieder. Einstweilen Danke,

[Doumanix]

Hi zusammen,

mal ne blöde Zwischenfrage: mit was hast du den Dump gemacht Oliver (Software)? Hardware müsste doch der SB-Programmer auch für sowas taugen, oder übersehe ich was? Man braucht ja nur eine USB-zu-seriell-Schnittstelle, oder?

Ein Gedanke zum Problem: die Kombi aus KNXD & Interface kann es nicht zufällig sein? Hast mal EIBD mit deinem Interface probiert?

Grüße
Christian

[ZwergNase]

Guten Morgen!

Dumps habe ich mit den SB-Programmer und FlashMagic Version 12.30 build 588 gemacht.

Kombi knxd und das Interface (TPUART auch SB) ist inzwischen auch mein Verdacht. Prüfe ich als Nächstes, mein Eli will mir die Woche ein IP-Interface vorbeibringen.

Einen schönen Tag,

[Tontechniker]

Hallo Oliver,
du kannst mir auch gern das TPUART- Interface zuschicken. Ich überprüfe das gern kostenlos für dich (nur das Rücksendeporto müßtest du beilegen).
Meine Installation läuft mit EIBD seit ca. einem Jahr ohne Probleme.
Wenn du was zum Überprüfen schicken möchtest, bitte PN an mich, dann bekommst du meine Adresse.
Gruß
Hans

[ZwergNase]

Guten Morgen zusammen!

Danke für das Angebot Hans, ich glaube ich bin einen Schritt weiter aber bei Bedarf komme ich sehr gerne darauf zurück.
Ist noch nicht fertig ausgetestet aber ich glaube es liegt an knxd. Ich habe die Woche eine alter Version kompiliert (v0.12) damit scheint zumindest ein Teil der Probleme behoben.
Ich gehe dem jetzt weiter nach, teste fleißig und melde mich dann wieder.

Allen hier erst mal ein schönes Wochenende,
Oliver

[ZwergNase]

Guten Abend!

Ich denke ich weiß jetzt was passiert ist:

1. Ich hatte nie einen Controller zerschossen aber (und das kann ich noch nicht nachstellen) ich glaube, man kann den Controller beim programmieren mit der ETS "lahmlegen".
   Weil mir mein ETS-Projekt abgeraucht ist, musste ich alle Controller neu programmieren. Das hat nicht immer funktioniert und einige Controller haben gar nicht mehr reagiert. Diese Controller habe ich dann wild getauscht und auch neu geflasht.
2. Ein neu geflashter selfbus-Controller hat aber offenbar die default-Adresse 0.0.0.
   Er antwortet nämlich beim suchen nach Geräten im Programmier-Status so:

   Code: Alles auswählen

   Layer 1 [14:tpuart/Base      1315.188] RecvLP(009): B0 00 00 00 00 E1 01 40 EF

   Das zweite und dritte Byte (00 00) ist die Sender-Adresse. Kann das jemand bestätigen?
3. Bis zur Version v0.14.4 hat knxd die Sender-Adresse 0.0.0 auf seine eigene Adresse umgesetzt. Das war aber wohl mehr ein Bug als ein Feature. Seit dem Commit b7000ed wird so ein Paket nicht mehr weitergeleitet sondern führt zur Fehlermeldung "Packet not from us". Der Programmier-Modus wird dann nicht mehr erkannt und man kann den Controller mit der ETS nicht ansprechen.
4. Ich hatte tatsächlich irgendwann knxd geupdated. Das ist schon eine Weile her aber seitdem habe ich halt keine frisch geflashten Controller mehr mit der ETS programmiert. Daher ist das Problem lange nicht aufgefallen.
5. Ich habe die sblib in der Datei src/eib/bus.cpp so verändert (letzte Zeile):

   Code: Alles auswählen

   void Bus::begin()
   {
       ownAddr = (userEeprom.addrTab[0] << 8) | userEeprom.addrTab[1];
   #if BCU_TYPE != BCU1_TYPE
       if (userEeprom.loadState[OT_ADDR_TABLE] == LS_LOADING)
       {
           byte * addrTab = addrTable() + 1;
           ownAddr = (*(addrTab) << 8) | *(addrTab + 1);
       }
   #endif
       
       if (ownAddr == 0) ownAddr = 0xff01; // if no address present, default to 15.15.1

   Damit ist die Default-Adresse nach dem flashen 15.15.1.

Kann bitte jemand der mehr Ahnung von der sblib hat als ich mal über den Fix nachdenken und sagen ob ich das Problem richtig erkannt und behoben habe?
Ich weiss, dass der richtige Weg entweder ein Patch oder ein Pullrequest ist. Aber das Compilieren läuft bei mir gerade sehr provisorisch. Mit einer aktuellen MCUXpresso Version bekomme ich den build leider nicht hin. Ich arbeite gerade mit einer auf die Schnelle aus dem Backup hergestellten Version...

Als "Abfallprodukt" habe ich übrigens jetzt Docker-Images mit knxd in allen möglichen Versionen, schön sauber sortiert. Bei Interesse gerne melden.

Grüße,

[Doumanix]

Hi Oliver,

deine Theorie klingt plausibel. Auch der eibd meldet sich selbst unter der 0.0.0. Und ja, die SB Geräte auch, wenn ich mich recht erinnere.
Interessant wäre an dieser Stelle natürlich mal wieder, wie denn ein offizielles gerät reagiert. Ich kann mich bei den meinen nicht mehr erinnern.

Leider kann ich aktuell nichts selber flashen, ich muss mir erst wieder ein Kabel zum Flashen besorgen... aber ich habe mal compilliert.

Verstehe ich richtig, dass du deinen Fix selbst nicht ausprobieren konntest? Falls du testen willst, kannst du ja mal die hex hier verwenden:

out8-bcu1_newDefaultAddress.zip

(13.06 KiB) 352-mal heruntergeladen

Das ist eine 8out-bcu1, mit Handbedienung, ohne Zerodetect, mit deinem Fix.

Das Dockerfile würde mich interessieren. Vielleicht treffen wir uns mal kurz im Slack. Ich überlege schon seit längerem, wie wir das Thema mit ner Visu, mit nem knxd oder eibd, etc. sauberer bereitstellen können, ohne dass man immer gleich ganze Images neu laden oder bauen muss.

Grüße
Christian