Probleme mit Somfy und nanoCul - Ich brauche Hilfe beim debuggen

[viegener]

Ich habe jetzt 2 Tage in das debuggen eines Problems im Zusammenhang mit Somfy und dem nanoCul hereingesteckt, das von verschiedenen Leuten gemeldet wurde --> siehe z.B. hier: http://forum.fhem.de/index.php/topic,24158.msg359907.html#msg359907

Ich habe deshalb einen nanoCul(433MhZ) zum Testen gebaut und mit der aktuellen culfw-r525 versorgt. Der tut auch sauber (sendet und empfängt auch Somfy). Das Problem lässt sich leicht nachstellen, wenn man nach dem initialisieren auf slowRF/X21 folgenden Befehl mehrfach hintereinander an den CUL übergibt (ich tue das in einer seriellen Console)

Code: [Auswählen]

YsA8200267012345Ergebnis der cul blinkt schnell (ca. 3 mal pro Sekunde) und reagiert nicht mehr auf Befehle.

Jetzt habe ich es weiter eingegrenzt (stark verkürzt):

1) Wenn man cli/sei in der Somfy-Routine verwendet (zwischen Anfang Senden und Abschluss), wird der Absturz vermieden, allerdings fehlt dann gelegentlich das erste Zeichen aus dem nächsten Befehl
--> Also treten Interupts im UART auf und zwar mindestens 2, denn ein Zeichen wird verschluckt.

2) Also weiter in den UART-Routinen. Wenn ich in der serialc. ISR-Routine (für RX) den rb_put überspringe solange SOMFY läuft. Werden zwar Kommandos übersprungen aber es gibt keinen Abstürze mehr (und es fehlt auch immer ein ganzes Kommando)
--> Also habe ich mir den Ringbuffer (rb_put) angeschaut.

Von hier komme ich aber nicht weiter. Ich verstehe nicht, warum Aufrufe von rb_put in Konflikt mit der Bearbeitung von Somfy-Sende-Befehlen stehen und eigentlich ist mir auch immer noch nicht klar, woher das hektische Blinken im Fehlerfall kommt.

[mgernoth]

Hallo,

der Ringpuffer sollte eigentlich richtig gegen Interrupts geschützt sein.

Wenn ich das richtig sehe, ist der TTY-Puffer des nanoCUL anscheinend 128 Byte lang. Wenn der Puffer voll ist, werden neu ankommende Zeichen weggeschmissen. Wie reagiert Somfy, wenn "defekte" Kommandos ankommen? Kann es sein, dass Somfy länger als 2s blockiert?

Das Blinken hört sich irgendwie nach kaputtem Watchdog an, der durch den Arduino-Bootloader nicht richtig initialisiert wird und beim Booten gleich wieder einen Reboot triggered. Lässt sich das auch durch ein "B" im Terminal reproduzieren?

Evtl. mal das wdt_enable im nanoCUL.c deaktivieren.

Viele Grüße
  Michael

[viegener]

OK, das ist schonmal extrem hilfreich! Ich versuchs mal der Reihe nach:

- Das mit dem Interuptschutz habe ich gesehen und es wird auch der letzt I-Flag status restoriert (und nicht einfach eingeschaltet)

- defekte Kommandos (also zu kurz  etc sollten keine Problem darstellen, da ein statischer Buffer mit fromhex ausgelesen wird, damit wird im Zweifelsfall eine falsche Zahl gelesen wo etwas fehlt. Sauber ist das nicht, aber das habe ich mal eben ergänzt, macht aber wie erwartet keinen Unterschied

- Mehr als 2 sec. normalerweise eher nicht für ein einzelnes Kommando, aber bei mehreren hintereinander schon. Handgestoppt  sind es eher 1sec. Aber ich habe die Wiederholrate mal auf 99 gesetzt und voila, auch das erzeugt das Problem.

- Spannend: Ja ein einfaches B bringt Ihn in denselben Zustand. OK, also "kaputter Watchdog", den hatte ich überhaupt nicht gesehen.
Jetzt ist mir auch klar, warum ich alle LED_ON in beteiligten Bereichen auskommentieren kann und das Blinken bleibt ...

- Ohne wdt_enable kann ich auch mit 99 Wiederholungen ohne Probleme Kommandos absetzen, kein Blinken es dauert aber natürlich mehr als 10sec bis die Antwort kommt.

OK: Passt, Allerherzlichsten Dank!!!

Was bleibt an Fragen:
- Warum funktioniert der Watchdog nicht richtig auf dem nanoCul  (scheint ein Problem mit dem alten Arduino Bootloader zu sein
Vermutlich müsste mal jemand versuchen den aktuellen Optiboot bootloader auf den Nano zu packen, wie hier beschrieben
https://bigdanzblog.wordpress.com/2014/10/23/installing-the-optiboot-loader-on-an-arudino-nano-to-fix-the-watch-dog-timer-wdt-issue/

- Warum dauert es auf dem nanoCul so viel länger aus auf dem SCC und dem BuswareCUL?

Mein Vorschlag, watchdog für nanoCul deaktivieren (auch Verlängerung auf 4sec bringt nur begrenzt Hilfe)?

Ausserdem würde ich mich um einen Patch für den somfy-Code (Wiederholungen runtersetzen, Befehlslänge prüfen)

[mgernoth]

Hallo,

- Mehr als 2 sec. normalerweise eher nicht für ein einzelnes Kommando, aber bei mehreren hintereinander schon. Handgestoppt  sind es eher 1sec. Aber ich habe die Wiederholrate mal auf 99 gesetzt und voila, auch das erzeugt das Problem.

Hmm, das wdt_reset() wird nur im Minute_Task aufgerufen. Wahrscheinlich kommt der einfach nicht dran, wenn die ganze Zeit Kommandos aus dem Puffer abgearbeitet werden. Baue doch mal ein wdt_reset() an den Anfang von somfy_rts_send.

- Warum dauert es auf dem nanoCul so viel länger aus auf dem SCC und dem BuswareCUL?

Sollte es nicht, evtl. kommt da aber das wdt_reset() durch die andere Implementierung der Kommunikation (CUL) dran bzw. die Geräte booten einfach wieder normal durch (SCC).

Mein Vorschlag, watchdog für nanoCul deaktivieren (auch Verlängerung auf 4sec bringt nur begrenzt Hilfe)?

Ich würde stattdessen ein wdt_reset in die somfy_rts_send einbauen.

Viele Grüße
  Michael