IO4 verhindert Start

Hallo,

ich habe aktuell das Problem, sobald ein IO4 an einem Master Brick angeschlossen ist, startet dieser nicht mehr.

Die Lichtorgel nach dem Anschliessen kommt nicht und der Master Brick taucht auch nicht im Brick Viewer auf. Die WiFi Extension versucht auch nicht sich zu verbinden.

Dieses Phänomen lässt sich an einem zweiten Master reproduzieren. Auch wenn nur das IO4 angeschlossen ist.

Am IO4 liegt es nicht, denn an einem DC Brick funktioniert es einwandfrei.

Das konnte ich mit der Firmware 1.4.4 und der 1.4.5 feststellen.

An beiden von mir verwendeten Mastern ist ein WiFi aufgesteckt.

Noch ne kleine Ergänzung: Ist auf dem Master eine RS485 Extension gibt es keine Probleme. Es scheint also in Kombination mit der WiFi Extension aufzutreten.

Getestet mit FW 1.4.2 und 1.4.5.

Hast Du mal versucht die Master-Extension vom Master-Brick zu löschen, also weder RS485, WIFI oder Chibi im Master-Brick zu hinterlegen. Ext.Type also None.

Geht es dann mit Master und IO4 ?

Hatte vorkurzem ähnliches Problem (http://www.tinkerunity.org/forum/index.php/topic,929.0.html), eine RS485 war noch weiterhin gültig im Eeprom obwohl eine Chibi am Master angesteckt war.

Habe ich soeben probiert. Und der Master hängt trotzdem. Sobald ein IO4 am Master hängt und ein WiFi auf ihm residiert ist es aus. Das beisst sich was.

Also warten auf Montag und 1.4.6.

Du sollst die WIFi Ext. nicht anschließen, also der Master-Brick mit dem IO4 alleine und die Ext.Type auf None setzen, warum sollte es dann mit der WIFI zu tun haben !?

Ansonsten scheint die Ext.Pinne vom Master-Brick auf den Typ RS485 dauerhaft gesetzt zu sein, ich hatte das Problem mit RS und Chibi, Abhilfe schaffte die alte FW 1.1.7. Im Anschluß upgrade auf neuere FW 1.4x or whatever.

Das mag ja sein, aber ich brauche die WiFi an diesem Stack. Und das IO4. FW 1.1.7 und WiFi geht ja auch nicht.

Also warte ich mal bis TF eine Bereinigung bereit stellt. Die Extensions scheinen es in sich zu haben. Seitem löst ein Bug den anderen ab.

Ach ja, was aber gegen Deine Theorie spricht: Ohne das IO4 arbeitet der Stapel einwandfrei. Ich hatte den nun auch seit er bei mir ist in Betrieb - mit 3 AnalogIn und einem Temperature. Nun habe ich ein AnalogIn weggenommen und das IO4 rangehängt und nix geht mehr.

Hallo ArcaneDraconum,

habe hier gerade mal einen WLAN Stapel auf die aktuelle 1.45 geflasht. Kein Probleme.

Temp,Ambient,Humidity,IO4 + Master 1.4.5 + WLAN.

Kann es sein, dass zufaelligerweise ein Brickletkabel kaputt ist (Draht ab oder Kontakte werden reingedrueckt) und du es so benutzt hast, dass es zu diesem Ergebnis kommt?

Zieh mal vorsichtig an jedem Draht und schaue ob du ihn aus dem Stecker ziehen kannst.

Ist es egal an welchem Port das IO4 steckt?

Alle Kontakte der Stecker am Master sind in Ordnung?

Ich wuerde einen Hardwarefehler immer noch nicht ausschliessen.

Der Loetkolben.

Hallo Löti,

Habe dasselber Bricklet mit anderem Kabel an einen anderen Master gehängt. Auch dieser Master startet nicht. Mit diesem Kabel das IO4 am DC Brick funzt es dann. Ich denke das Kabel kann ich ausschließen.

Ich kann es auch nicht reproduzieren. Ich hab einen Stapel bestehend aus Master Brick mit WIFI Extension und 2x Analog In, 1x Temperature, 1x IO4 (siehe Anhang für FW Versionen). Hab mich auch einmal per Ad Hoc WIFI drauf verbunden, geht auch.

OK ... Ich werde nach dem DTM Gemetzel nochmals testen und die Ergebnisse hier niederschreiben...

Aaaaaalso verschiedene Tests:

Stack1: Step-Down / Master (1.4.5) / RS485, neues Kabel, IO4 (1.1.1) funzt.

RS485 runter, WiFi drauf: funzt

Stack2: Master (1.4.5), gleiches Kabel, IO4 (1.1.1): funzt nun auch

WiFi drauf: tut immer noch

Stack3: Step-Down / Master (1.4.5) /WiFi, gleiches Kabel , IO4(1.1.1) an Port D, AnalogIn (1.1.1) an Port A, AnalogIn an Port C: nix geht

WiFi runter: geht immer noch nicht

AnalogIn beide weg: geht immer noch nicht

IO4 an Port B: wieder nix

IO4 an Port A: funzt!

IO4 an Port C: funzt

IO4 an Port A, AnalogIn an B, AnalogIn an D: alle 3 werden erkannt

Somit: sobald das IO4 an der (vom USB aus betrachtet) linken Seite hängt geht nix. Andere Bricklets an den Ports werden aber erkannt.

Ach ja WiFi drauf, unverändert. Scheint also an dieser speziellen Portkombi zu liegen.

Ach ja: eines noch: Der Stack 2 hat nur funktioniert, weil das IO4 an Port A hing. Ein neuer Test mit dem IO4 an Port D: nix geht.

Ich kann es also immer noch an verschiedenen Masters reproduzieren:

Kannst du die IO-4 Firmware einmal neu flashen?

Klingt irgendwie pervers, aber es hat geholfen. Nun scheint es portunabhängig zu sein.

Statt Kuba libre, Porta libre - verträgt sich auch besser mit dem Führerschein.

Na dann mal vielen Dank - schnelle Hilfe am Sonntag. Das ist normalerweise richtig teuer. 

Ach ja... ich mach mal den Thread dicht.

Nochmals vielen Dank für die schnelle Zielführung.

So ich habe das Thema nochmals aufgemacht, weil noch Fragen aufgetaucht sind.

Meine Vorgehensweise: Ich hatte das IO4 an dem ersten Stack, an dem es geklemmt hat und zwar an Port A, an Den Ports B und D hingen die AnalogIns. Dann habe ich das IO4 neu geflasht und die AnalogIns an die Ports A und C gehängt, das IO4 an D. Das war auch mein ursprünglicher Aufbau. Der jetzige Aufbau funzt prima.

An was es letztendlich lag weiß ich auch nicht. Die IO Firmware ist ja nicht so neu. Ich hatte bisher die gleichen Bauteile im Einsatz, geändert hat sich in den letzten 4 Wochen nur, dass das RS485 runter gekommen ist und das WiFi drauf. Und ein paar Runden neue Master Firmware.

@TF

Da wir nicht genau wissen woran es liegt, wuerde mich aber interessieren, ob in der Bricklet FW Informationen sind an welchem Ports die Bricklets arbeiten duerfen und an welchen nicht. Wie kamt ihr darauf diesen Rat zu geben?

Muss man damit rechnen, dass bei einer Erstinbetrebnahme einer Masterextension die FW (Brick oder Brickelt) nicht klarkommt??

Meine WLAN Extension habe ich seinerzeit erst erfolgreich zum laufen bekommen, als ich den Masterbrick neu geflasht habe. Das kann sicher Zufall gewesen sein.

Ggesicherherte Erkenntnisse habe ich nicht, aber die Master-FW war vor dem aufstecken der WLAN Extension aktuell und der Masterbrick arbeitete einwandfrei.

Ueber Infos wuerde ich micht freuen.

Der Loetkolben

@TF

 

Da wir nicht genau wissen woran es liegt, wuerde mich aber interessieren, ob in der Bricklet FW Informationen sind an welchem Ports die Bricklets arbeiten duerfen und an welchen nicht. Wie kamt ihr darauf diesen Rat zu geben?

Alle Bricklets funktionieren an allen Ports aller Bricks. Da gibt es keine Einschränkungen.

Da das Problem hier durch neu Flashen des IO-4 Bricklets gefixed wurde, würde ich vermuten, dass das im EEPROM des Bricklets gespeicherte Plugin eine Macke hatte. Das würde auch erklären, warum das Problem an 2 Master Bricks auftrat. Warum es dann nur am Master Brick und dann auch noch von Port und der Extension Konfiguration abhängt ist nicht klar.

Muss man damit rechnen, dass bei einer Erstinbetrebnahme einer Masterextension die FW (Bick oder Brickelt) nicht klarkommt??

 

Meine WLAN Extension habe ich seinerzeit erst erfolgreich zum laufen bekommen, als ich den Masterbrick neu geflasht habe. Das kann sicher Zufall gewesen sein.

WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere Firmware verwendet?

Mir fällt gerade ein, daß ich noch ein zweites IO4 habe. Dieses hängt zur Zeit am DC Brick. Ich werde dieses mal an einen Master hängen und schauen, ob ich da auch unerwartetes feststellen kann.

Ich werde da heute Abend mal ne Zeile dazu hier hinterlassen...

Hallo photron,

WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere

Firmware verwendet?

Ja das war mir klar. Ich hatte eine aktuelle FW drauf, die schon WLAN konnte. Ich bekomme es nicht mehr genau zusammen wie es war, aber die Extension hat sicht nicht mit dem WLAN verbunden, obwohl ich alle Parameter richtig eingestellt hatte. Ein neuflashen der Masterfirmware brachte dann den Erfolgt.

Ob es wirklich am neuflashen lag oder Murphy es aufgegeben hat mit zu aergern kann ich nicht sagen. Seitdem laeuft der Stack aber reibungslos.

Verbesserungsvorschlag: FW mit Checksumme sichern und der Master prueft dies beim booten???

Alternative: Im Brickviewer kann man die FW testen. Also auslesen und mit einem CRC Code (Fingerprint) vergleichen den es zu jeder FW gibt.

Der Loetkolben

Hi,

ich gebe hier auch mal meine Erfahrungen dazu.

Aus meiner Sicht scheint es einen Zustand bei Fehlern in der Stackkommunikation zu geben, der zum gemeldeten Fehlerbild (Stack hängt bis zum Abklemmen eines bestimmen Bricklets) führt. Reparatur ist nur(?) durch Neuflaschen der Firmware der Brick möglich. Ich hatte das Problem bis vor kurzem massiv. Die Umgebung ist dabei ein Brickdaemon der auf einem OpenWrt Router läuft. Anscheinend verkraftet der Brickd schlecht Memoryprobleme. Es gibt zwar keine Fehlermeldungen, aber irgendwann hängt sich der Stack (oder Teile davon) einfach weg. Ich hatte zunächst versucht ihn dann via Reset-Kommando wiederzubeleben. Hat auch manchmal funktioniert. Nicht selten war der Stack aber nicht wiederzubeleben und hing mit o.a. Fehlerbild. Seit ich den Speicher häufig aufräume (OpenWrt schreibt halt Logfiles normalerweise ins RAM) läuft der Stack seit etwa einer Woche stabil durch. Zum Nachstellen des Fehlerbildes empfehle ich also mal Kommunikationsfehler zu provozieren (z.B. durch usb resets o.ä)

skippi, dass brickd Problem haben kann wenn ihm der RAM ausgeht kann ich verstehen. Warum da aber irgendwie das Neuflashen von Bricks einen Effekt haben soll sehe ich nicht.

Tja, ich hatte das Problem auch nicht gemeldet weil ich es nicht reproduzierbar Beschreiben konnte. Ich musste aber mindestens viermal eine Brick neu flashen. Es trifft auch nicht immer die Masterbrick. Ich habe noch eine Servobrick im Stack, die noch nicht ernsthaft im Einsatz ist, aber auch Bricklets bedient. Auch dort ist das Problem einmal aufgetreten. Man müsste mal durch die Resetroutine durchschauen.

Gesucht ist ein Stück Code das ggf. auf ein Ereignis wartet das nicht Eintritt wenn ein Bricklet angeschlossen ist das im falschen Zustand ist. Dies muss vor dem "Blinkenlights" sein, denn das machen die Bricks beim Reset dann nicht mehr.

Dieser Deadlock wird durch das 'flashen' anscheinend beseitigt.

Mir fällt in diesem Zusammenhang gerade ein: Wird beim Reset nicht Code aus den Bricklets übernommen ? Gibt es da eine Umschaltung Code / Betrieb ?

Allerdings mussten die Bricklets bei mit nicht beim Flashen angeschlossen sein.

Der 'Schalter' muss auf der Brick selbst liegen.

Falls ich noch etwas herausfinde lege ich es hier ab.

Also Leute,

eines kommt mir etwas merkwürdig vor. Als die - damals neue - Firmware 1.1.1 für das IO4 erschienen ist, habe ich nach einigen Tage meine beiden IO4s geflasht. Alles hat prima getan. Letztes Wochenende habe nach 2 Wochen Test mit den AnalogIns wieder ein IO4 angehängt und hatte untenstehende Probleme. Wohlgemerkt: Das IO4 ist an seinen "alten" Port angehängt worden. Der Unterschied war nur kein RS485, dafür WiFi.

Ein neuflashen der IO4 Firmware brachte Abhilfe. Nun habe ich das Spiel mit dem anderen IO4 ausprobiert. Und siehe da.... an Port B & D hängt der Stack.

DAS KANN KEIN ZUFALL SEIN!

Habt Ihr irgendwann heimlich die IO4 1.1.1 Firmware ohne Revisionswechsel getauscht? Dass ein Flashfehler bei einem Auftritt sehe ich gerne ein, aber bei zweien????

Ach ja... ein neuflashen hat den Fehler auch diesmal behoben. Da hattet Ihr doch fehlerhafte FW auf Eurem Server.

Ich weiß, das ist ein echtes Misstrauensvotum, aber irgendwie kommt ich mir veräppelt vor.