Permanente Boot-Schleife

Hallo zusammen,

Ich komme nicht weiter.
Ich habe zwei Sensorkits bekommen und beide sind in einer Boot Schleife.
Ich kenne mich mit dem Fipy an sich nicht wirklich aus, habe aber grundsätzlich Python/Programmierkenntnisse.

Was bisher geschah.

Ich habe die Sensoren konfektioniert und angeschlossen an den BOB-HAT V5a.
Habe das Extension Board und den FiPy angeschlossen.

Bei ersten mal habe ich es auch hinbekommen, einen AP zu öffnen, das WLAN zu konfigurieren und konnte die Sensoren sehen.
Ich habe die Wage versucht zu kalibrieren. Die Werte auf dem Web frontend haben keinen Wirklichen Sinn ergeben. Aber egal.

Nach einer kurzen Unterbrechung wollte ich fortfahren, kam aber mehr auf die Seite.
Ich konnte sehen, dass FiPy immer nur für wenige Sekunden per Ping erreicht werden kann.
In diesen wenigen Sekunden, kann ich auch mal kurz die Webseite sehen.
Dann Resettet sich das FiPy und rebootet.

ets Jun  8 2016 00:22:57

rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2140
ho 0 tail 12 room 4
load:0x4009fa00,len:19740
entry 0x400a05bc
Starting boot process...
Boot finished.
Init -> CSV logger in directory /sd/hiverizelog
init sensors
init -> DS18B20
Found 6 DS1820.
Gain & initial value set
BME280 initialization failed. Is it connected properly?
in webserver.py
ssd1306.py:  esp32
Start -> logger
init -> DS18B20
Start -> Info: (sysname='FiPy', nodename='FiPy', release='1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig', version='v1.20.1.r2-122-gd82a6f43e-dirty on 2020-03-06', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1')
Using Antenna:  False
WiFi: Using internal antenna
Antenna set
*********
channel: 11
sec: 3
rssi: -71
ssid: *********
bssid: *********
Start -> 5 SSIDS found
Start -> AP SSID: Brombeere
Start -> Cause of restart: WDT
Start -> switching to ap mode is now possible
Start -> Starting measurement setup...
WLan is enabled, trying to connect.
Using Antenna:  False
WiFi: Using internal antenna
Antenna set
Called. Pin Pin('P16', mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).
WLan connect failed!
SSID: *********, Enc: 3, PSK: *********
WLan connection failed, retry...
Using Antenna:  False
WiFi: Using internal antenna
Antenna set
Pycom MicroPython 1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig [v1.20.1.r2-122-gd82a6f43e-dirty] on 2020-03-06; FiPy with ESP32
Type "help()" for more information.
>>> AP enabled
not yet started
threaded

Dann gehts wieder von Anfang los.

Leider finde ich weder auf dem GitHub Project irgendeine Readme.md oder ähnliches, wie man die Einstellungen zurücksetzen kann oder was man versuchen kann.

Wäre für eure Hilfe sehr dankbar.

Gruß
René

Moin René,

schaut nach Watchdog Problemen aus und deine Wlan Verbindung scheint nicht zu klappen.

Du könntest mal versuchen dein Wlan zu Netz zu deaktivieren bevor du den FiPy startest, dann müsste er auf alle fälle im AP-Mode starten. Falls er da auch nicht sauber hochfährt, würde ich versuchen ihn ohne angeschlossene Sensoren zu starten.
Im schlimmsten Fall musst Du die Firmware Neu aufspielen.
Ich entsinne mich aber, das es noch eine Art “save Boot” gibt. falls du es schaffst Dich in der kurzen Zeit mit der FiPy REPL zu verbinden. Kannst Du das laufende Programm mit STRG+F unterbrechen bevor der Watchdog auslöst. Dann kannst Du versuchen die [user_settings.json] zu löschen oder zu editieren.

Falls die Zeit zu kurz ist, wirst Du die Firmware neu aufspielen müssen.
Eine Anleitung dazu findest du hier:

Support-Doku gibt es hier [hier] (BOB-Anleitungen - Hiveeyes)kannst Du dich gerne mal reinlesen.

Gruß Micha

Danke für die Info.
Das checke ich mal.

Er meldet zwar im Terminal, dass er einen Fehler bei WLAN hat, jedoch verbindet er sich vollständig.
Ich kann ja den FiPy pingen und auch in den paar Sekunden in denen er verbunden ist das Web-Interface öffnen…
An den Sensoren liegt es nicht.
Habe auch schon den FiPy ausschließlich mit Expansionboard versucht zu starten. -> Selbes Verhalten.

Ich checke das und danke für die Links zu der Doku!
vielleicht sollte der Doku Link mal in eine Readme.md auf dem GitHub project gekippt werden :wink:

@MKO
Hallo Michael,

Sind euch “Probleme” bekannt, wenn ein WLAN die selber SSID für 5GHz und 2,4GHz verwendet?
Meine SSID ist in den available WLAN zwei mal vorhanden, wegen unterschiedlicher Frequenzen.

Ich konnte die user_settings.json editieren.
Mal ne blöde Frage: Ich hab das jetzt über die Python Console gemacht. ist also etwas umständlich.
Ist das der “einfache” weg?

Gruß

Es gab mal einige Probleme mit einigen Fritzboxen und den Connection Timeout (muß dann etwas höher gestellt werden) einige Router antworten irgendwie nicht schnell genug. findet man glaube ich unter General Settings.
Das 5 gHz Netzwerk bekommt der FiPy gar nicht mit.

Wenn er das Webinterface öffnet kann man immer noch Daten Ändern und speichern. Mann muß nur den Zeitpunkt Abpassen wenn gerade der FiPy eine neue Verbindung aufgebaut hat. :wink:

Der Einfache Weg, ist meiner Meinung nach über Atom oder Visual Studio Code mit PyMakr Plugin.
Da bekommst Du automatisch ein REPL und Zugriff aufs Dateisystem.

Du scheinst schon Recht gute Kenntnisse zu haben, wenn Du später Mal Lust auf mehr hast, solltest Du darüber nachdenken, zur alternativen Terkin Firmware zu wechseln.

Gruß Micha

1 Like

Danke.

Ja ich bin Entwickler und auch recht viel mit Python unterwegs. Aber bis jetzt nicht mit der pycom architektur oder mit MicroPython gearbeitet.
Und auf Grund der - sagen wir verstreuten doku - ist das finden der infos schwer, wenn man nicht genau weiß wonach man sucht ;-)

ich such mal im Forum was Terkin ist ;-)

Hi René,

Das ist leider wahr ;]. Wir müssen hier endlich mal mehr Struktur reinbringen. Ich hoffe Du findest Dich trotzdem zurecht, die richtigen Juwelen auszugraben.

Auch dort wirst Du direkt fündig:

Terkin ist ein MicroPython-Datenlogger, der gemeinsam mit @einsiedlerkrebs, @poesel, @Thias, @clemens, @MKO, @tonke, @weef, @wtf und @roh entwickelt wurde. Diese Gerätschaft erschließt die Hardware des FiPy etwas mehr, unterstützt z.B. auch LoRa und Cat-M1 über das Sequans Modem und läuft sogar auch auf CPython. Terkin wurde primär zur Datenübertragung an Kotori ausgelegt, kann aber auch zur BEEP Software funken.

Einige aus unserer Runde betreiben ihre Meßknoten auch damit im Feld. Das einzige Manko ist, dass es hier bisher noch keine grafische Benutzeroberfläche zur Einrichtung gibt. Die Konfiguration erfolgt stattdessen über eine Konfigurationsdatei, siehe z.B. terkin-datalogger/src/settings.example-bob.py at main · hiveeyes/terkin-datalogger · GitHub.

@Jan hat bei Lopy4 + Pytrack: hoher Stromverbrauch im Deepsleep ebenfalls Interesse an der Weiterentwicklung signalisiert.

Viele Grüße,
Andreas.

2 Likes

Nur mal ne kleine Wasserstandsmeldung.

Tatsächlich konnte ich bisher keine Problemlösung finden.
Ich habe zwei Unifi AccessPoints für mein WLAN hier, welche die selbe SSID für 2,4 und 5 GHZ verwenden. Beide haben natürlich die selbe SSID.
Ich vermutete, dass die beiden Netze oder die beiden AccessPoints ggf. das “Problem” sein könnten. Könnte immer noch am WLAN liegen, aber ich glaube es nicht.
Auch bei nur einem aktiven AP schlägt vermutlich der WatchDog zu.

Basierend auf dem Souce Code würde ich sagen, dass der FiPy das erste mal sich nicht verbinden kann und deswegen einmal WLan connection failed, retry... in die Console schreibt, aber es bei zweiten Versuch schafft, sonst würde das bis zu 3 mal schreiben.

Nun wäre die Frage, oder meine nächsten Schritte beim Reversen, wann und warum der WatchDog einen Reset auslößt.

Da ja derzeit der Server von Bee-Observer nicht funktioniert konnte ich auch noch kein gültiges Konto einrichten auf dem FiPy.
Jetzt wollte ich mal schauen, ob bei nicht richtiger Anmeldung der Watchdog ggf. auch auslöst. Das wäre dann ein recht “dummer” Fehler von mir ;-)

Schön wäre es auch, wenn der WatchDog erstmal was in die Console feuert, bevor der Reset gemacht wird.

@Diren @MKO

Hi,

Ich habe das Problem mit der Bootschleife gefunden.
Der SW1 ist entweder falsch vertratet oder falsch programmiert.
Sobald in der user_settings.json die Einträge zu den WLANs und Co enthalten sind, startet der FiPy ja normalerweise in seinen “Messmodus”.

Mit den aktuellen boards ist es aber so, dass diese dann nach dem Boot in the AP modus wechseln, jedoch nach initialer Aktivierung des WatchDogs. Dieser Zustand führt dann, da im AP Modus der Watchdog nicht länger gefüttert wird, dazu, dass der FiPy nach ca. 10 Sekunden reseted wird.

kann man an dieser Meldung sehen:
Called. Pin Pin('P16', mode=Pin.IN, pull=Pin.PULL_UP, alt=-1).

Ich würde sagen, dass hier das “PULL_UP” falsch ist. dadurch funktioniert der FiPy entweder, wenn der PIN auf "button_ap_pin": "P2" geändert wird in den settings, oder man ihn gedrückt hält.
Mit der Änderung auf P2 muss man dann natürlich wieder den Flash Knopf Brücken um in den AP-Modus zu kommen, wie im letzten Datentreffen erwähnt.

Ich schau mal ob ich die Stellen im Code finde und fixen kann.
Ich würde dann einen PullRequest nach GitHub machen.

Ist einer der Maintainer der FiPy Firmware hier im Forum anwesend?

LG
René

@Diren hat Zugriff aufs Repo, wenn es da was anzupassen gäbe.

Vielleicht sind aber auch nur die initialen Settings falsch, siehe BOB-HAT Platine selbst löten - #2 by clemens

Auf der Platine ist SW1 bestück und der R4 daneben, oder?

Nur der Pin der mit dem Flash-Button verbunden ist hat einen aktivierbaren pull up, der P16 hat gar keinen internen pull up, den man aktivieren könnte, daher müssen wir den mit dem R4 extern bestücken.

Ja ich hab mich geirrt. Das PULL_UP war nicht das Problem.

Das Problem war, dass die CallBack zu früh im Process registriert wurde und dadurch während der “Startphase” schon ausgelöst wurde.

Ich habe das registrieren der CallBack an den Start der start_measurement() Funktion verschoben.

Dann funktioniert es wie es soll.

Ich hab einen PullRequest auf GitHub erstellt.
Ich hätte auch Interesse den Code mal ein wenig… aufzuräumen.
Ist etwas inconsistent und die Python Pep8 werden auch nicht wirklich befolgt.
Falls etwas “Refactoring” gewünscht ist, hätte ich da lust drauf.

2 Likes

Da würden wir uns sehr freuen!

Mir fällt gerade noch ein, dass wir zu Projektstart im Hamburger Workshop Platinen komplett ohne AP-Button hatten und @MKO den code so angepasst hat, dass nach einem Reset? / Neustart (?? ich weiß nicht mehr, ob power cycle oder reset gereicht hat) den AP-Mode gestartet hat und der dann nach einer Zeit auch automatisch verlassen wurde. Vielleicht magst du @MKO nochmal schauen, ob der fix von @snooz bzw. der bug was damit zu tun hat.

Ich kann sicher so etwas implementieren.

Ich denke grundsätzlich wäre es eine gute Idee, dass der FiPy, falls er sich nicht in ein WLAN einloggen kann, den Access Point öffnet.

Und, wenn der FiPy mit dem WLAN verbunden ist und der Button gedrückt wird, der Webserver startet. So, dass man aus dem eigenen Netz auf die Konfig kommt.

Zum Access Point könnte man dan lange drücken.

Auch finde ich, dass die LED zu wenig infos zeigt.
Keine “Blinkcodes” und der eigentliche Status ist auch nicht so wirklich zu sehen.

Wäre da Interesse an einer Weiterentwicklung?

Ich habe zwar seit 2 Monaten nichts mehr gemacht, aber hier sind meine bisherigen Programme.
Überarbeitet habe ich die Sensoren wie DS18B20, BME280, HX711, die RTC DS3231 und den Stromsensor INA219.
Noch nicht angefasst habe ich den WLAN-Manager mit der Umschaltung von Client zu AP und die ganze Konfiguration
WiPy1-Strom-V2b.zip (55,9 KB)
WiPy2-Mess-V2.zip (137,3 KB)

1 Like

Super vielen Dank für deinen Bug-Fix! Ich konnte es gerade testen auf einem FiPy der mit dem gleichen Problem zu mir zurück gesendet wurde. Ich werde den Pull-Request heute noch bestätigen.

Wir würden uns sehr freuen, wenn Du am Code weiterarbeiten möchtest!
Ich denke es ist gut, neuen Code immer ausführlich zu testen (siehe das Boot-Loop Problem, da haben wir eindeutig nicht genug getestet, als wir die Positions des Buttons geändert haben). Vielleicht finden sich hier aber auch noch ein paar weitere Leute, die testen würden. Wenn du nur ein bisschen Refactorings machst, ist das sicherlich keine Problem, aber bei größeren Änderungen wäre das besser.

Moin @snooz soweit ich mich entsinne gibt es da ein Problem mit der Pinbelegung und Der RGB. P2 wird bei zumindest bei Der Weißen Platine noch für den AB Modus genutzt und sobald der interupt eingerichtet wird ist die LED außer Funktion und kann nicht mehr genutzt werden. Ich hatte mal versucht die LED und interupt nach dem Startvorgang wieder zurückzuseten, aber ohne Erfolg.

Etwas hatte ich da im Kamerun Branch schon gemacht allerdings entsinne ich mich nicht mehr genau was. Und mir fehlt aktuell die Zeit mich darum zu kümmern.

@MKO
Ja mit P2 geht die LED nicht, daher wurde jetzt ja auch P16 umgestellt.
Ich würde mich jetzt auch zum Thema LED eher auf P16 konzentrieren.

Das mit dem Testen ist natürlich so eine Sache.
Ich hab jetzt meine beiden FiPy in Betrieb genommen und will diese Daten nicht mit Tests versauen.
Ich habe jetzt mal zwei WiPy bestellt, aber die wollte ich auch an weiteren Völkern mit selbst gekauften Waagen montieren.

Wenn ich ein Kit zum Testen hier hätte, könnte ich das damit natürlich machen.
@Diren

Wenn die beiden WiPy hier sind, wollte ich mich nochmal dran setzen.
Gruß

Für die “weiße” Platine muß allerdings auch die zweite Option erhalten bleiben, siehe Wie komme ich in den AP-Modus bei der weißen Platine?.

Beim Booten wird der Startgrund ermittelt. Wenn es ein kompletter Neustart (stromlos) ist, muß er ebenfalls im AP Modus starten, da diese Variante keine Buttons hat.

Alles klar.
Hab ich verstanden.

Es gibt also quasi zwei relevante Platinenvarianten, die “offiziell” von der Firmware unterstützt werden soll?

  1. Weiße Platine [FiPy Solar?!] (Ohne Buttons)
  2. Bob-HAT mit Buttons
    2.1 Btn auf PIN2 (ohne LED Nutzung)
    2.2 Btn auf PIN16 (mit LED Nutzung)

gibt es noch weitere Besonderheiten, die in der aktuellen Firmware vielleicht nicht offensichtlich sind?