Massive "reset" Probleme nach Update auf Protokoll 2.0

Ich habe jetzt alle Bricks und Bricklets auf Protokoll 2.0 aktualisiert - puh, aber ging soweit.

Jetzt habe ich leider arge Probleme im Betrieb.

Mein Teststack besteht aus

- Master 2.0 mit Step-Down-Power Supply + WLAN Ext.

- Quad Relay

- Servo Brick mit nur einem Servo

Steuere ich das Servo Brick einzeln => alles OK.

(Es kommen ca. 10-15 Servo-Befehle pro Sekunde)

Gebe ich aber zusätzlich alle 2 Sekunden einen Monoflop Impuls auf das Quad-Relais (Thread 1) und sende parallel dazu die Servo-Requests bootet der Stack nach kurzer Zeit neu (kann ich in wenigen Sekunden herbei führen).

Booten bedeutet: die LED-Reihe leuchtet auf und die WLAN Ext. connected sich neu.

Mit API 1.0 hatte ich das nicht.

Die Servo-Requests laufen bei mir in einer Queue seriell ab.

Aber ein anderer Thread sendet die Quad-Relais Befehle.

Ich hatte in 1.0 die Synchronized-Blöcke geprüft und das sah OK aus. Die write() Befehle der IP-Connection schließen sich eh aus.

Was ist hier in 2.0 anders?

Was kann den Master dazu bringen, neu zu booten?

Kleiner Zusatz:

- auch im normalen Betrieb des Servo lese ich in einem separaten Thread schon alle 2 Sekunden Spannung und Stromverbrauch vom Master aus, das scheint keine Probleme zu machen

- kommt hier das Setzen des Quad-Relais hinzu (seriell nach Auslesen der Spannung, aber theoretisch parallel zum Steuern des Relais), hängt sich der Master auf.

Auf Client-Seite bekomme ich erst eine TimeoutException und dann eine NotConnectedException.

Ich werde jetzt probehalber alle Commands wieder serialisieren in einem Thread.

Dein Stack kann ja (wenn die Bindings korrekt im Multithreading funktionieren) eigentlich keinen Unterschied merken, aus wie vielen Threads er angesprochen wird.

Mein Tipp wäre, dass möglicherweise die Bindings nicht thread-safe sind und dem Stack dadurch irgendwann Müll schicken woraufhin dieser einen Neustart durchführt. Ist aber wild ins Blaue geraten.

Hilfreich zur Unterstützung/Widerlegung dieser Theorie wäre es, wenn du einen TCP-Dump o.ä. von der Session erzeugen könntest. Dann wäre es möglich nachzuvollziehen welche Pakete wann geflogen sind. (eigentlich ein dummer Vorschlag... ich habe gar kein Tool um die Daten effizient untersuchen zu können )

Mhhh, schwer zu sagen. Der Master sollte eigentlich nur dann neustarten, wenn er über "reset()" getriggert wird.

Kannst du das irgendwie in ein Programm packen was ich hier ausführen kann? Würde das gerne reproduzieren.

Probleme mit dem Threading halte ich für sehr unwahrscheinlich. Spätestens die "send" Aufrufe auf dem Socket sind normalerweise atomar. D.h. da sollte wenn nur etwas auf PC Seite durcheinander geraten können.

Das mit dem "in ein Programm packen" dauert etwas, wenn ich's heute nicht mehr hinbekomme...

Man merkt aber deutlich:

- steuere ich das Servo hin und her und "parallel" dazu

  wird alle 2s Spannung/Strom vom Master ausgelesen, läuft es flüssig

- kommt zusätzlich nach dem Auslesen von Spannung/Strom ein

  setMonoflop(), dann "hakt" das Servo in und recht schnell

  bekomme ich eine TimeoutException z.B. im getStackVoltage()

  und der Stack bootet neu.

- Das Relais schaltet nur eine Leuchtdiode

Ich hab's extrahiert!

Anbei das ZIP mit dem Java-Code.

Dort gibt es unter src/bricktest/Main.java die Anwendung hier ist der Connect leicht zu finden. Der ServoThread.java konfiguriert das Servo. Aktuell hängt am PIN 2 (von 7) das Servo. Die Anwendung startet 3 weitere Threads

- 1. Thread verarbeitet die Servo-Commands die ohne Response sind

- 2. Thread verarbeitet die langsameren Servo-Commands die mit Response sind

- 3. Thread 'füttert' Thread 1 mit Servo Befehlen

- dazu kommt der main-Thread der den 2. Thread mit Status Befehlen und Relais Befehlen füttert.

Warum so viele Threads: eine GUI läuft asynchron über Event-Handler und nie Synchron zu zyklischen Threads. Das habe ich hier versucht, zu simulieren.

Bei mir führt das in kurzer Zeit zu einem Timeout und Reboot des Stacks. Der Timeout könnte auch ein Threading Problem sein, aber dann sollte der Stack nicht neu booten - oder?

BrickTest.zip

Gucke ich mir direkt morgen früh an!

Noch ein kleiner Tippfehler oben: der 2. Netzwerkthread verarbeitet die Statuscommands mit Response, keine Servocommands.

Mhh, läuft bei mir erstmal soweit durch.

olaf@pc:/tmp/BrickTest/src$ java bricktest.Main

UID: 5Vihz1  Type-ID: 13  type: 0

UID: dbs  Type-ID: 26  type: 0

UID: aqG  Type-ID: 21  type: 0

UID: aUt  Type-ID: 25  type: 0

UID: 6xgNMy  Type-ID: 11  type: 0

UID: 6QHafZ  Type-ID: 14  type: 0

UID: cuw  Type-ID: 225  type: 0

QUAD MONOFLOP 2 for 200ms

Count: 0  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 1  Voltage: 0.0

Count: 2  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 3  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 4  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 5  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

QUAD MONOFLOP 2 for 200ms

Count: 6  Voltage: 0.0

Count: 7  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 8  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 9  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 10  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 11  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 12  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 13  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 14  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 15  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 16  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 17  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 18  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Count: 19  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

Wie hast du das genau zusammengesteckt (welches Bricklet wo, welche Bricks wie aufeinander)?

Tritt das Problem auch auf, wenn du keinen Servo am Servo Brick angeschlossen hast?

Ui, ich hab mit Hilfe deines Codes einen potentiellen Buffer Overflow im WIFI Extension Code gefunden.

Ich konnte das zwar nicht so gut reproduzieren, allerdings wird dies trotzdem mit hoher Wahrscheinlichkeit dein Problem gewesen sein.

Vielen Dank für die Hilfe !

Ich habe

- ganz unten: Step Down Power Supply

- drüber Master

- drüber Servo

- oben WLAN Ext.

Das Relais hängt am Master. Im Beispiel scheint hier keine Step-Down-Power Supply dran zu sein (Voltage ist 0).

Diese Stelle hier:

Count: 5  Voltage: 0.0

QUAD MONOFLOP 2 for 200ms

QUAD MONOFLOP 2 for 200ms

Count: 6  Voltage: 0.0

Count: 7  Voltage: 0.0

Ist schon ein "Zucken". Das müsste gleichverteilt kommen.

Wenn sowas bei mir passiert dauert es bei mir nicht lange und der Stack bootet neu. Über meine GUI konnte ich das in wenigen Sekunden reproduzieren. Mit der immer konstanten Rate de Servos im Testprogramm musste ich öfter probieren, bis ich eine Zeiteinstellung gefunden habe, bei der es überhaupt passiert.

Hattest du jetzt 2.0.1 auch schon getestet?

Mit der immer konstanten Rate de Servos im Testprogramm musste ich öfter probieren, bis ich eine Zeiteinstellung gefunden habe, bei der es überhaupt passiert.

Ich kenne den Fix von borg nicht, deswegen kann ich mich auch durchaus täuschen, aber da das Fehlverhalten das du beschreibst ganz arg vom Timing abzuhängen scheint würde ich das Threading definitiv nochmal untersuchen. (Außer borg sagt, dass der Buffer Overflow auch ganz bestimmtes Timing o.ä. vorrausgesetzt hat)

eine Frage noch an TF (oder Kenner der Firmware):

Gibt es noch Möglichkeiten den Stack abzuschießen indem man kaputte Pakete sendet oder wurde der Code in 2.0 dahingehend (hoffentlich) vollständig abgedichtet? Ich weiß, dass sowas in den 1.x Versionen durchaus mal vorkommen konnte mit falschen Paketen den Stack zu zerschießen.

Ich habe noch nicht mit der 2.0.1 getestet. Dazu komme ich erst Donnerstag oder Freitag.

Ich muss leider mitteilen, dass das Problem nicht gelöst ist:

mein Stack hängt sich immernoch auf an und zu auf, aber es wird deutlich schwerer, dass zu erzeugen.

Wenn das Relais alle 1-2 Sekunden einen Monoflop macht und ich parallel dazu mit manueller Steuerung das Servo bewege bootet der Stack irgendwann neu.

Vor allem zuckt das Servo sehr stark (bleibt stehen), wenn das Relais ein ist. Ich werde mal versuchen, die Commandfolgen mit Timing aufzuzeichnen - dauert aber etwas.

Einen Deadlock in der Anwendung würde ich ja verstehen, aber ein Reboot des Stack ist eigenartig.

Was mir auch aufgefallen ist: das Auslesen von Spannung / Strom dauert teilweise über 80ms, d. h. die Response kommt nicht in 6-7, sondern in über 80ms. Ist der Stack zu stark belastet? Mit Firmware Version 1 hatte ich diesen Effekt nicht so deutlich.

Die "Reproduzierbarkeit" des Aufhängens des Stacks ist nicht mehr gegeben. Ich hab es noch 2x geschafft innerhalb von 1 Stunde probieren.

Davor war es nach 10-20 Sekunden probieren reproduzierbar.

Mein Fazit:

der WLAN Fix hat eine deutliche Verbesserung gebracht.

Es scheint aber noch ein versteckter Bug vorhanden zu sein, der sich jedoch nicht so oft zeigt und ich bekomme ihn nicht reproduziert.

Auch ich habe noch immer Probleme seit dem Update auf 2.0.1. Hier eine kurze Beschreibung:

• Stack mit WLAN-Modul und Step-Down
  
• Temperatur-, Luftfeuchte-, Luftdruck- und Helligkeits-Bricklets
  
• Verbindung: "Access Point: Static IP"
  
• Power Mode: "Full Speed"
  

Stack läuft mittlerweile ca. 1 Tag problemlos. Dannach ist der Stack zwar mittels Ping erreichbar, jedoch kann z.B. über den brickv keine Verbindung mehr hergestellt werden.

Nach einem Neustart (durch Abschalten des Stroms) ist der Stack wieder erreichbar.

Ich bin dran, solche Sachen die sich nur alle paar Tage reproduzieren lassen sind leider wirklich schwer zu debuggen .

So, es gibt jetzt die erste beta von Master Brick Firmware 2.0.2: http://download.tinkerforge.com/_stuff/brick_master_firmware_2_0_2_beta1.bin

Das ist definitiv noch nicht die finale Version 2.0.2, es fehlen noch ein paar Kleinigkeiten die ich heute nicht mehr geschafft hab. Desweiteren hab ich bisher nur mit WPA und noch nicht ausführlich im AdHoc/AP Modus getestet.

Hab ziemlich viel umgerissen, hauptsächlich um bessere Fehlerbehandlung und besseres Debugging/Logging zu erlauben: https://github.com/Tinkerforge/master-brick/commit/510e9350b2c7769222bbbd839254809baafafe2c

Wer Lust und Zeit hat: Bitte testen ob die Firmware einen Unterschied bringt .

@borg

Was ich nach testen dazu sagen kann ist das die Firmware definitiv stabiler läuft.

Ich hab alles aus dem git genommen (brickd, brickv, master-fw).

Es hängt sich auch nicht mehr auf wenn ein prozess auf die wifi-extension zugreift und gleichzeitig ein enumeration durchgeführt wird.

Wenn meine neue bestellung ankommt teste ich dann auch noch mit chibi und rs485 im zusammenspiel.

Gruß

Da ich leider immernoch sporadische Reboots und Hänger des Stack habe noch ein paar Zwischenergebnisse:

• Das Problem tritt nur auf, wenn ich den Stack per WIFI verbinde
  
• Ist der Stack per USB angeschlossen und der Client kommuniziert mit dem brickd, habe ich den Absturz gar nicht, auch nicht sporadisch.
   
  

Das hilft für eine genaue Fehleranalyse leider nicht weiter, verstärkt aber die Vermutung, dass noch im Bug im WIFI-Code versteckt ist.

Hallo Admins,

anbei habe ich ein neues Testprogramm (siehe src/bricktest/Main.java) mit dem ich den Effekt zumindest in wenigen Sekunden soweit bekomme, dass der Stack

• mehrere Sekunden lang aussetzt und die Servos danach die Befehle "nachholen" (das würde ich gerne mal auf Video aufnehmen ...).
  Das die Servos die Befehle nachholen deutet darauf hin, dass die Befehle in einem Netzwerkpuffer (auch dem Socket-Puffer) oder im Puffer der WLAN-Ext. stehen und dann verarbeitet werden.
  
• der Client eine TimeoutException bekommt
  
• der Stack danach meist per WLAN nicht mehr ansprechbar ist und neu gestartet werden muss, weil eine Exception beim erneuten Connect kommt:
  Exception in thread "main" java.io.IOException: Connection failed: Keine Route zum Zielrechner
  Über USB ist der Stack dann meist noch ansprechbar!
   
  
• Oder ich kann noch connecten, aber der enumerate liefert nichts mehr zurück. Über USB geht es dann oft noch!
  

Was ich leider nicht geschafft habe: dass der Stack von alleine neu bootet.

Einmal kam eine "kaputte" Response, die zu dieser Exception geführt hat:

Exception in thread "Brickd-Receiver" java.lang.ArrayIndexOutOfBoundsException: 5
at com.tinkerforge.IPConnection.getFunctionIDFromData(IPConnection.java:760)
at com.tinkerforge.IPConnection.handleResponse(IPConnection.java:676)
at com.tinkerforge.ReceiveThread.run(IPConnection.java:102)

In Summe schicke ich hier recht schnell Befehle zum Stack.

Der Testaufbau benötigt:

- Masterbrick mit WLAN

- Step-Down-Power Supply

- Servobrick (Servos müssen nicht dran hängen, mit Servo auf Kanal 0+1 sieht man's aber besser)

- 1 Ind. Quad Relais

- 1 Ambilight Sensor (müsste auch ohne gehen)

Ich werde noch versuchen, das Testprogramm direkt auf dem Tablet auszuführen und den Stack als Access Point zu konfigurieren. Dann ist weniger Netzwerkhardware dazwischen, die das beeinflussen kann.

test.zip

Alle klar, gucke ich mir an. Komme aber wahrscheinlich erst am Montag dazu.

Der Effekt tritt auch auf, wenn ich das direkt vom Tablet aus ausführe. Allerdings merkt man, dass es vom Tablet aus minimal langsamer läuft (CPU nicht so stark).

Ist der Stack im Access Point Mode habe ich nach einer Weile auch Hänger, allerdings bekomme ich die oft erst beim 2. Durchlauf. Auch dann hilft nur noch der Reset, um WIFI wieder ansprechbar zu machen.

Abends bin ich wohl nicht mehr voll konzentriert :

das "nachholen" der Servobefehle kommt aufgrund der Queue, die ich Client-seitig drin hab. Die ist dafür, damit kein Servo-Befehl verloren geht, wenn gerade ein anderer Befehl aktiv ist. Normal stehen da vielleicht 2-5 Befehle drin.

In diesem Fall passiert es aber, dass der Socket-write für 0,5-1,5 Sekunden blockiert und in dieser Zeit viele Befehle auflaufen. Das dürfte aber erstmal kein Problem sein. Aber wenn diese "Blockade" zu oft auftritt, ist irgendwann der Stack der WLAN gar nicht mehr ansprechbar.

Das Herabsetzen des Delays zum Auslesen der Spannung (Main.java, sleep) auf z.B. 1165ms verstärkt den Effekt noch etwas.