UNKNOWNCODE ZERR30D

[P.A.Trick]

Guten Morgen Forum,

eben ist mir folgender Eintrag im fhem-log aufgefallen.

Code Auswählen Erweitern


2014.07.29 09:25:52.140 4: CUL_0: CUL CUL_0 UNKNOWNCODE ZERR30D

Ich bin mir nicht sicher ob das ein Fehler ist, aber vielleicht kann mir jemand sagen was das für ein Gerät sein könnte?

[rudolfkoenig]

culfw/clib/rf_moritz.c: (== MAX)

ZERR3<CC1100_MARCSTATE> wird ausgegeben, falls MARCSTATE nicht auf RX steht.
Lustigerweise ist RX==0D, d.h. zw. den zwei Abfragen ist der CC1101 Status auf RX gesprungen.

[P.A.Trick]

MAX habe ich Rudi, aber ansonsten habe ich nur Bahnhof verstanden! Sorry!

[rudolfkoenig]

culfw programmiert den Funkchip (cc1101) auf Empfang. Der ist selbst ein kleiner Computer mit vielen Zustaenden (Initialisieren, Kalibrieren, Senden, Empfangen, etc). Wenn nach dem programmieren eine gewisse Zeit verstrichen ist, und der Zustand immer noch nicht auf Empfang (RX) steht, dann gibt es die Fehlermeldung.

[P.A.Trick]

Ah ok verstehe, also kann ich die Meldung ignorieren oder soll ich weiter analysieren?

[rudolfkoenig]

oder soll ich weiter analysieren?

Gerne, aber dann ohne meine Hilfe.

[gero]

Ich beobachte diese Meldung seit Oktober verstärkt in meinen Logfiles.
Verursacht wird sie durch rf_moritz.c Zeile 301ff:

Code Auswählen Erweitern

  //Wait for sending to finish (CC1101 will go to RX state automatically
  //after sending
  uint8_t i;
  for(i=0; i< 200;++i) {
    if( cc1100_readReg( CC1100_MARCSTATE ) == MARCSTATE_RX)
      break; //now in RX, good
    if( cc1100_readReg( CC1100_MARCSTATE ) != MARCSTATE_TX)
      break; //neither in RX nor TX, probably some error
    my_delay_ms(1);
  }

  if(cc1100_readReg( CC1100_MARCSTATE ) != MARCSTATE_RX) { //error
    DC('Z');
    DC('E');
    DC('R');
    DC('R');
    DC('3');
    DH2(cc1100_readReg( CC1100_MARCSTATE ));
    DNL();
    rf_moritz_init();
  }

Zum einen wird der Fehler verursacht, weil CC1100_MARCSTATE beim Wechsel von TX nach RX auf MARCSTATE_TXRX_SWITCH steht. Ab und zu beobachte ich auch ungültige Werte (z.B. 0x17), die durch das "SPI Read Synchronization Issue" (siehe CC1101 Silicon Errata http://www.ti.com/lit/er/swrz020d/swrz020d.pdf) zu erklären sind.

Ich habe bei mir obigen Code durch folgenden ersetzt:

Code Auswählen Erweitern

  //Wait for sending to finish (CC1101 will go to RX state automatically
  //after sending
  uint8_t i;
  uint8_t stat1,stat2;
  for(i=0; i< 250;++i) {
    my_delay_ms(1);
    stat1=cc1100_readReg( CC1100_MARCSTATE );
    stat2=cc1100_readReg( CC1100_MARCSTATE );
    if(stat1!=stat2) continue;
    if( stat1 == MARCSTATE_RX)
      break; //now in RX, good
  }

  if(cc1100_readReg( CC1100_MARCSTATE ) != MARCSTATE_RX) { //error
    DC('Z');
    DC('E');
    DC('R');
    DC('R');
    DC('3');
    DH2(cc1100_readReg( CC1100_MARCSTATE ));
    DH2(stat1);
    DH2(i);
    DNL();
    rf_moritz_init();
  }

Bisher tritt der Fehler nicht mehr auf.
Gruß,
Gero

[adb76]

Hallo Gero,

habe seit dem Einsatz eines MAX!-Wandschalters ebenfalls ab und zu die genannten ZERR30D Meldungen. Werde mal deinen Vorschlag entsprechend übernehmen und mir eine entsprechende CUL-Firmware kompilieren. Parallel würde mich interessieren, ob sich seit dem Einsatz des Patches irgendwelche Nebeneffekte ergeben haben, oder ob die Probleme seither vollständig gelöst sind?

Werde hier auch mal eine Rückmeldung geben, sobald die gepatchte Version bei mir eine Weile gelaufen ist.

Gruß,

André

[gero]

Hallo André,

die Firmware läuft bei mir seit einem knappen Jahr ohne jegliche Probleme.

Gruß,
Gero

[adb76]

So, jetzt habe ich diesen Patch seit ein paar Tagen in meinem MAX! Setup mit der a-culfw Firmware im Einsatz: läuft tadellos. Seitdem keine ZERR30D Meldungen mehr und auch sonst keine Probleme.

Daher für mich ein heisser Kandidat offiziell in die culfw bzw. a-culfw aufgenommen zu werden.  Gibt es eigenlich einen Grund was dagegen spricht?

P.S. Für alle MAX-Cube-User, die keine Lust haben selber zu kompilieren, findet ihr im Anhang die von mir eingesetzte Version auf Basis der a-culfw 1.05.04 mit der o.g. kleinen Anpassung (Beschreibung zur Verwendung dieser Firmware gibt es hier: http://forum.fhem.de/index.php/topic,38404.0.html)

Gruß,

André