culfw@ARM

[OtisWright]

also ich glaube das ganze hängt mit meinem CC1101 Modul zusammen. ich hab das jetzt mal abgesteckt (Habe Jumper-Kabel an den Cube gelötet um das schnell tauschen zu können) und sowohl über USB als auch über LAN geht der Cube jetzt wieder.
Das heißt wohl, dass ich ohne neues CC1101 Modul und ändern der Board.h Datei nicht um das Vergnügen mit dem Cube herumkomme.

Danke sehr für die tolle Hilfe am Samstag Abend!

[freetz]

Hallo zusammen,

ich hatte vor gut einem Jahr schon einmal hier mein Problem beschrieben, das ich beim Flashen der Firmware meines Max Cubes hatte und konnte es damals irgendwie lösen:
https://forum.fhem.de/index.php/topic,38404.msg558765.html#msg558765

Nun wollte ich eine neuere Firmware aufspielen, hatte zu Anfang die gleichen Probleme mit dem Mac (bis ich auf meinen Post hier stieß ) und habe es jetzt wieder unter Ubuntu probiert. Das Aufspielen eines neuen Bootloaders klappt auch, aber wenn dann die LED blinkt und ich die Firmware hochladen will, bleibt die LED nach dem (anscheinend erfolgreichen) Update aus. dmesg sagt mir "unable to enumerate USB device", aber wenn ich dann mit RESET gedrückt den Cube einstecke, bekomme ich brav ein "Product: CUBELOADER" und kann das Spiel erneut (wenn auch ohne Erfolg durchführen.
Weitere Fehlermeldungen sind u.a.
"cdc_acm 2-1:1.0: failed to set dtr/rts"
"device descriptor read/64, error -71"
"device not accepting address 11, error -71"
Wie gesagt nur, nach dem Upload der Firmware, nicht, wenn ich im Bootloader Modus bin.

Ich bin mir ziemlich sicher, dass ich damals die CUL_V3_868MHZ.hex verwendet hatte, es war auf jeden Fall die Version 1.23.05. Aber um sicher zu gehen: Wie kann ich herausfinden, ob ich V2, V3 oder V4 einsetzen muss?

Freue mich über jede Hilfe, da ansonsten die Heizung hier sonst nur über die Außentemperatur gesteuert werden kann ...

Gruß,

F.

[freetz]

Ich habe nun zum Testen den neuen Cube (der für meine Eltern sein soll) auch versucht zu flashen, aber da komme ich trotz Überbrückens von J1 noch nicht einmal zum Löschen des Bootloaders. Der Cube blinkt am Anfang immer kurz und leuchtet dann dauerhaft. Gibt es da Erkenntnisse, ob neuere Cubes da einen Löschschutz haben?

[blueicechip]

Hallo freetz,

die CUL V 2/3/4 kenne ich nur für die Atmels für den Cube gibt es die a-cul CUBe Firmware.

Mit dem Bootloader Flashen hatte ich bisher keine Probleme, allerdings hatten ich auch grosse Probleme die Firmware per xmodem zu über tragen - lag aber an meinen Rechnern, mit einem ginges dann. Hatte aber auch nicht weiter nachgeforscht warum die anderen Rechner nicht korrekt per xmodem verbinden / übertragen wollten.

[freetz]

Wow. You made my day !
Ich Hirsch hatte vor dem Cube einen CUL-Stick im Einsatz (über ein Jahr her), den ich damals mit der CUL-Firmware geflasht hatte und dann bei der Suche nach den Files diese zuerst gefunden - und dachte irgendwie, dass die Files in CUBe nur für den Bootloader wären.
Nun tut's, diesmal sogar mit BOSSA und Tera Term aus der Virtual Machine von Parallels auf meinem Mac heraus . Der Upload hing am Ende dann zwar bei 100%, aber nach dem An- und Abstecken bootete der Cube wie er sollte.

Das Löschen des Bootloaders ging (im Gegensatz zum anderen Cube) nicht, wenn man die Kontakte nur an der Oberfläche verbunden hat, ich musste richtig mit einer Büroklammer in die Löcher gehen, dann ging's aber sofort.

Vielen Dank noch mal für die schnelle Hilfe im entscheidenden Punkt!

[uelpenich]

Code Auswählen Erweitern

Das bereits X21 einen Absturz verursacht ist ungewöhnlich.Um exakt zu sein, bei X21 erfolgt noch nicht der Absturz, erst bei *X21.
Aus lauter Verzweiflung hatte ich alles abgelötet und wieder angelötet, dabei aber einen Fehler gemacht und GOD0 nicht verbunden: => kein Absturz, aber auch keine Funktion des 433MHz Transceivers.
Ich habe neue Briefmarken bestellt und will sehen, ob damit der Fehler wieder auftritt.

Es hat lange gedauert bis die neuen Transceiver geliefert worden sind. Da der Fehler mit den neuen Transceivern in gleicher Weise auftaucht, habe ich mir die beiden Max!Cubes genauer angesehen:

Mit diesem Cube funktioniert es:
eQ-3  BC-LGW-O-TW
TRX868 / 868.3 MHz
Prozessor AT91SAM7x256
Das fest eingebaute Transceiver Modul hat ein QR-Code Label mit "12686872". Das Modul habe ich nicht geöffnet, um nachzuschauen welches Transceiver Chip verbaut ist.

Dieser Cube (etwas älter) hat die oben beschriebenen eigenartigen Neustarts in dem Augenblick, wenn der zweite Transceiver das erste Mal angesprochen wird (Befehl  *X21):
eQ-3  BC-LGW-O-TW-MD
TRX868-TI / 868.3 MHz
Prozessor AT91SAM7x512
eingebautes Transceiver Chip CC1100

Obwohl lt. TI der CC1100 etwas weniger Funktionen hat als der CC1101 funktioniert der CC1100 mit der Culfw Firmware.

Gibt es zu den beiden Cubes Erfahrungen was geht und was nicht?

[Telekatz]

Dieser Cube (etwas älter) hat die oben beschriebenen eigenartigen Neustarts in dem Augenblick, wenn der zweite Transceiver das erste Mal angesprochen wird (Befehl  *X21):

Das erste mal wird der zweite Transceiver bereits bei der Hardware Autodetection angesprochen und da wird er auch gefunden. Stürzt der Cube auch bei den Befehlen *C99 oder *Zr ab?

[uelpenich]

Das erste mal wird der zweite Transceiver bereits bei der Hardware Autodetection angesprochen und da wird er auch gefunden. Stürzt der Cube auch bei den Befehlen *C99 oder *Zr ab?

Vielen Dank für die Geduld. Jetzt funktioniert es.
Ich habe mit dem Befehl e den Cube zurück gesetzt. Und oh Wunder keine Abstürze mehr.

PS: Wer pflegt die Seite http://culfw.de/commandref.html ? Es wäre schön, wenn das Prefix * (** und ***) zur Ansprache des zweiten bis vierten Transceivers mit aufgenommen werden könnte.

[Wzut]

Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.

[Telekatz]

Möglicherweise öffnet irgend ein Prozess die USB Verbindung kurz. Das merkt der Cube und will daraufhin alle Nachrichten auch über USB ausgeben. Wenn die USB Verbindung dann wieder geschlossen wird, wird der USB Buffer nicht mehr geleert, der Buffer läuft voll, der Cube bleibt auf die Leerung wartend in einer Endlosschleife hängen und der Watchdog löst aus.

[uelpenich]

Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.

Es gibt zwei Arten von USB Kabeln: mit und ohne Brücke zwischen Pin 4 und Pin 5 (die Masse Verbindung). Diese Brücke entscheidet im angeschlossenen Gerät, ob das Kabel nur der Stromversorgung dient oder ob es für Stromversorgung plus Datenverkehr genutzt wird. Diese Unterscheidung wird von Navis und Mobiltelefonen gemacht. Ob das für den Cube mit culfw eine Rolle spielt ist einen Versuch wert.

[Wzut]

Wenn die USB Verbindung dann wieder geschlossen wird, wird der USB Buffer nicht mehr geleert, der Buffer läuft voll, der Cube bleibt auf die Leerung wartend in einer Endlosschleife hängen und der Watchdog löst aus.

OK, wenn es nur darum geht den Bufferinhalt abzuholen und nach /dev/nul weiterzuleiten werde ich das mal als Softwarelösung testen bevor ich die Kabel zerschneide.

[toxic-tonic]

Moin,

habe nach langem hin und her nun endlich meinen cube(x4) um ein 434MHz-Modul ergänzen können. Sieht auch ganz gut aus, außer, dass er es als 868MHz-Modul erkennt:

Code Auswählen Erweitern

...
-I- ** Valid PHY Found: 1
-I-  DM9161_ResetPhy
-I- Detected CC0: PN 0x00  VER 0x03
-I- Detected CC1: PN 0x00  VER 0x14
-I- Not detected CC2: PN 0xff  VER 0xff
-I- Not detected CC3: PN 0xff  VER 0xff
-I- Not detected onewire
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- init Complete
V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
*V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)

Muss ich die Frequenz in der Firmware anpassen, über einen Befehl oder soll ich in FHEM das einfach als Attribut übergeben?

Danke und Gruß

Tobias

[Telekatz]

Mach mal mit "raw e" einen Reset der Einstellungen.

[toxic-tonic]

Bingo! DANKE!!