Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32

Begonnen von Ralf9, 13 Dezember 2019, 12:48:26

Vorheriges Thema - Nächstes Thema

Ralf9

Hallo Reinhard,

die Kennung müsste ich dann so im RAM speichern, daß sie bei einem Reset nicht neu initialisiert wird.
Ich habe dies gefunden, das müsste ich dann mal testen ob dies auch beim STM32 funktioniert.
https://atadiat.com/en/e-how-to-preserve-a-variable-in-ram-between-software-resets/

ZitatBei mir schlägt weiterhin der Watchdog sporadisch aber regelmäßig zu. Zwischen einer Stunde und zwei Tagen habe ich schon alles gesehen. Eventuell gibt es ja da Regelmäßigkeiten.
Bei Dir ist anscheined irgendwas besonderes, daß der Watchdog so oft zuschlägt.
Betreibst Du den Maple an einem Testsystem oder am Produktivsystem. Hast Du evtl fhem Module durch die fhem ab und zu blockiert wird?

Ber der LAN Version hat der Watchdog nach ca 2,5 Tagen das erste mal und nach ca 3,5 Tagen das zweite mal zugeschlagen.
Über USB habe ich bis jetzt eine uptime von 5 Tagen und 6 Stunden

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Telekatz

Wenn du nur wenige Bytes vor einem Reset retten möchtest, kannst du beim STM32 auch die Backup Register (BKP) verwenden.

Reinhard.M

Sagen wir mal Testsystem. Ich beschäftige mich erst seit ein paar Monaten mit FHEM um meine Rollosteuerung zu zentralisieren. Habe aber Gefallen daran gefunden mehr und mehr andere Dinge einzubinden  :)
Für die Rückmeldung würde ja bereits ein Byte genügen das jeweils beim Einstieg in die Funktion gesetzt wird. Damit könnten wir zumindest feststellen ob es immer bei dem gleichen Aufruf zum Reset kommt. Was denkst du?

Ralf9

Ja ein Byte würde reichen.

Ich habe hier was gefunden
https://www.mikrocontroller.net/topic/264560?goto=new#new

demnach wird damit geschrieben
      PWR_BackupAccessCmd(ENABLE);
      BKP_WriteBackupRegister(BKP_DR1, 0x0000000C);
      PWR_BackupAccessCmd(DISABLE);


und damit gelesen
     BKP_ReadBackupRegister(BKP_DR1)

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Wäre perfekt, würde ich gleich einspielen wenn du es eingebaut hast.

Ralf9

Kann eine Weile dauern, muß es erst mal an einem Testsketch testen und rausfinden welche inludes notwendig sind
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M


Ralf9

Habe nun eingebaut, daß in einigen Stellen verschiedene Werte ins Backupregister geschrieben werden 

1  FifoReceive begin
2  FifoReceive end
3  processMessage begin
4  print MS Nachricht
5  print MC Nachricht
6  print MU Nachricht
7  processMessage end
8  HandleCommand begin
9  HandleCommand end


In der Setup Routine wird der Wert des Backupregister dann ausgegeben und gemerkt.
Der gemerkte Wert steht dann auch in der Version z.B." -7-"
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Zitat von: Ralf9 am 20 Juni 2020, 15:18:23
Habe nun eingebaut, daß in einigen Stellen verschiedene Werte ins Backupregister geschrieben werden 
Habe es compiliert und eingebaut, mal sehen was der Watchdog so von sich gibt.

Reinhard.M

Hallo Ralf,
ich kann bereits erste Ergebnisse liefern. Der Watchdog schlägt bislang immer mit "5" zu, also einem "print MC Nachricht". Ich habe mal meine alten Logs durchsucht und konnte bei fast allen Resets eine entsprechende Korrelation feststellen. Keine Ahnung ob es direkt dieser Printbefehl ist aber in diesem Umfeld macht es Sinn genauer hinzuschauen. Eine Sequenz stellt sich typischerweise im fhem.log so dar:
2020.06.22 07:06:01.479 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=492492;C=243;L=24;R=252;i;s6;b5;w;
2020.06.22 07:06:01.481 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=4924924;C=243;L=26;R=252;s108;b107;w;
2020.06.22 07:06:01.483 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=4924920;C=243;L=25;R=252;s105;b104;w;
2020.06.22 07:06:05.414 4: myMaple/keepalive ok, retry = 0
2020.06.22 07:06:22.259 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.06.22 07:06:24.314 3: Setting myMaple serial parameters to 115200,8,N,1
2020.06.22 07:06:24.317 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.22 07:06:24.317 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.22 07:06:24.317 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.06.22 07:06:24.330 4: myMaple/msg READ: BackupReg = 5
2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: BackupReg = 5
2020.06.22 07:06:24.330 4: myMaple/msg READ: Watchdog caused a reset
2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: Watchdog caused a reset
2020.06.22 07:06:24.331 4: myMaple/msg READ: Watchdog enabled
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: Watchdog enabled
2020.06.22 07:06:24.331 4: myMaple/msg READ: Reading values from eeprom
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: Reading values from eeprom
2020.06.22 07:06:24.331 4: myMaple/msg READ: CCInit
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: CCInit
2020.06.22 07:06:24.331 4: myMaple/msg READ: detect A: Partn=0 Ver=0x14
2020.06.22 07:06:24.332 3: myMaple/noMsg Parse: detect A: Partn=0 Ver=0x14
2020.06.22 07:06:24.333 4: myMaple/msg READ: detect B: Partn=0 Ver=0x18
2020.06.22 07:06:24.333 3: myMaple/noMsg Parse: detect B: Partn=0 Ver=0x18
2020.06.22 07:06:24.334 4: myMaple/msg READ: Starting timerjob
2020.06.22 07:06:24.334 3: myMaple/noMsg Parse: Starting timerjob
2020.06.22 07:06:24.388 4: myMaple/msg READ: rxA=1 rxB=1
2020.06.22 07:06:24.388 3: myMaple/noMsg Parse: rxA=1 rxB=1

Hoffe du kannst damit etwas anfangen. Sonst melde dich. Habe am Samstag endlich die Maple Platinen bekommen und lasse seit gestern auch einen Sduino mitlaufen. Da gab es aber noch keinen Ausfall dieser Art.

Gruß
Reinhard

Ralf9

Was ist das für ein Sensor von dem Du die MC Nachrichten empfängst?

Interessant wäre jetzt ob der Watchdog noch zuschlägt, wenn Du mit "set disableMessagetype MC.." die MC-Nachrichten deaktivierst.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

Sensor abschalten kann ich testen. Der Sensor ist eine Wetterstation mit Temp, Hum, Wind

Reinhard.M

Muss mich korrigieren, der Sduino ist ebenfalls schon über ein WR gegangen:
Line 103588: 2020.06.22 06:14:57.376 3: myMaple/noMsg Parse: BackupReg = 5
Line 104179: 2020.06.22 06:17:03.336 3: myMaple/noMsg Parse: BackupReg = 5
Line 116798: 2020.06.22 07:05:52.263 3: mySduino/noMsg Parse: BackupReg = 5
Line 116928: 2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: BackupReg = 5
Line 143555: 2020.06.22 08:49:54.252 3: myMaple/noMsg Parse: BackupReg = 5
Line 143834: 2020.06.22 08:50:57.077 3: mySduino/noMsg Parse: BackupReg = 5
Line 150697: 2020.06.22 09:19:19.621 3: myMaple/noMsg Parse: BackupReg = 5
Line 151044: 2020.06.22 09:20:53.755 3: mySduino/noMsg Parse: BackupReg = 5
Line 154719: 2020.06.22 09:36:39.601 3: myMaple/noMsg Parse: BackupReg = 5
Line 154884: 2020.06.22 09:37:10.702 3: mySduino/noMsg Parse: BackupReg = 5
Line 158342: 2020.06.22 09:51:53.302 3: mySduino/noMsg Parse: BackupReg = 5
Line 158560: 2020.06.22 09:52:56.288 3: mySduino/noMsg Parse: BackupReg = 5
Line 158696: 2020.06.22 09:53:28.653 3: myMaple/noMsg Parse: BackupReg = 5
Line 158849: 2020.06.22 09:53:59.822 3: mySduino/noMsg Parse: BackupReg = 5

Was mir hier auffällt, Beide machen einen WR fast zur gleichen Zeit. Nicht nur einmal, fast immer im Abstand von 30 bis 60 Sekunden. Schalte jetzt mal beim "myMaple" MC ab.

Ralf9

ZitatHoffe du kannst damit etwas anfangen. Sonst melde dich. Habe am Samstag endlich die Maple Platinen bekommen und lasse seit gestern auch einen Sduino mitlaufen. Da gab es aber noch keinen Ausfall dieser Art.
Empfängst Du bei Dir viele Sensoren, auch welche von Nachbarn?

Ich vermute, daß dies fehlerhafte MC-Nachrichten sind, die einen Absturz verursachen können. Sie können durch überlagerungen mit anderen Nachrichten entstehen.
Ohne zu wissen wie so eine fehlerhafte MC-Nachricht als MU-Nachricht ausieht wird es wahrscheinlicht recht schwierig diesen Bug zu finden. Anscheinend tritt dies nur bei Dir so massiv auf.
Ich hatte bis jetzt nur alle 2 - 5 Tage einen watchdog Reset. Ich habe bei der USB Version auch mal den MC-Decoder deaktiviert und bin jetzt bei einer uptime von 3 Tagen.

Es wäre hilfreich, wenn ich diese evtl absturz verursachenden MC-Nachrichten in der Form von MU-Nachrichten (DMC) hätte.

In der "signalDecoder4.h" gibt es ein auskommentiertes define
#define MCDEBUGDECODE 2    // debug mc-decoder

Dies sieht dann z.B. so aus:
2020.06.23 19:52:02.034 4: sduino/msg READ: DMC;P0=21872;P1=-5624;P2=921;P3=-1028;P4=-532;P5=433;D=01_232324545354542453245354545423245453235423235423545423542354545454245454545323545454245453545423232323542454535454545454545424545453545_4;e;
2020.06.23 19:52:02.045 4: sduino/msg READ: MC;LL=-1028;LH=921;SL=-532;SH=433;D=A8E4F45ADDBE0BC7558FF0E;C=485;L=91;R=245;s2;b2;s01_LlLlLsSsSlSsSsLsSlLsSlSsSsSsLl;


Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

ZitatEmpfängst Du bei Dir viele Sensoren, auch welche von Nachbarn?
Ich empfange bei mir einiges, auch aus der Nachbarschaft. Die meisten Protokolle habe ich aber über eine Whitelist ausgeschlossen. Als ich vorhin nochmals prüfen wollte welcher Sensor den Fehler hervorruft habe ich festgestellt, dass dieser zu den von der Whitelist ausgeschlossenen gehören muss. Ich habe genau einen OREGON (ID10) mit MC-Protokoll. Alle anderen MC sind nicht auf der Whitelist. Kannst du aus den folgenden Messages etwas ableiten?

2020.06.22 06:16:40.194 4: myMaple/msg READ: MC;LL=-487;LH=484;SL=-242;SH=248;D=49248;C=243;L=17;R=253;s15;b14;O;w;
2020.06.22 06:16:40.210 4: myMaple/msg READ: MC;LL=-476;LH=495;SL=-237;SH=255;D=49248;C=243;L=17;R=253;s255;b254;O;w;
2020.06.22 06:16:40.315 4: myMaple/msg READ: MC;LL=-489;LH=496;SL=-243;SH=241;D=49248;C=244;L=17;R=253;s117;b116;O;w;
2020.06.22 06:16:40.388 4: myMaple/msg READ: MC;LL=-485;LH=493;SL=-249;SH=241;D=49248;C=244;L=17;R=253;s255;b254;O;w;

LL ist bei einem Absturz bislang immer im -400/-500er Bereich gewesen. Der Maple läuft seit MC=0 durch, inzwischen mehr als 32Std. Der Sduino hatte bereits wieder ein Reset. Ich habe außerdem einen Nano (V 3.4.0-dev SIGNALduino) laufen der bislang noch nie über dieses Problem gestolpert ist. Ich werde mal die MU Nachrichten aktivieren und dir das Ergebnis schicken.