Nach Update von 0.8.93 auf 0.8.94 kein Empfang mehr von WR und Probleme mit W5500

[Edibo63]

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

external antenna

Power Stabilization

nothing

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.8.93

Github Hash

?

Build & Flash Method

AhoyDTU Webinstaller

Setup

Update von 0.8.93 ethernet auf 0.8.94 ethernet

Debug Serial Log output

No response

Error description

Nach dem Update funktionierte das nRF nicht mehr. Der W5500 hatte eine andere IP bekommen obwohl fixed im Router eingestellt ist. Zurück auf 0.8.93 eth war nur durch Neuinstallation möglich. 0.8.93 eth läuft problemlos

[hans341]

Ich hatte das Problem auch, insofern als dass Ahoy nicht mehr erreichbar war. Ob neue IP, habe ich leider nicht geprüft. Habe gleich 0.8.93 wieder aufgespielt.

[lumapu]

könnt ihr bitte euer Pinout bzgl. Ethernet posten. Die neue IP kann evtl. an einer anderen MAC Adresse liegen, es kann sein, dass diese neu berechnet wird.

[Edibo63]

Die MAC Adresse hatte sich geändert.

Pinout W5500:

GPIO04 INT GPIO12 MISO GPIO13 MOSI GPIO14 SCLK GPIO15 SCS

Beim nRF24 CE auf 17 statt 4

[hans341]

Ist bei mir wie in Issue 886 angegeben, wenn ich mich nicht irre....

[geronet1]

Vor dem Tausch des Webservers hatten alle mit W5500 die Mac-Adresse FE:ED:DE:AD:BE:EF Das funktionierte mit nur einem Ahoy im Subnetz, bei zwei gleichen ging das natürlich nicht. Jetzt holt er sich die richtige vom ESP:

// Configure MAC address uint8_t mac_addr[6]; ESP_ERROR_CHECK(esp_efuse_mac_get_default(mac_addr)); mac_addr[5] |= 0x03; // derive ethernet MAC address from base MAC address ESP_ERROR_CHECK(esp_eth_ioctl(eth_handle, ETH_CMD_S_MAC_ADDR, mac_addr));

[hans341]

Also ich habe heute noch mal etwas experimentiert und einen weiteren Test-Ahoy mit einem Lolin32-Board und W5500 gemacht. Dabei ist es so, daß ich alles nach 0.8.93 nicht zum Laufen bringe. Nachdem erst gar nichts ging, bin ich zurück auf die erste Version, die überhaupt mal ging: 0.8.21. Von da dann auf 0.8.93eth, was ging und per eth läuft. Dann auf 0.8.97 und dann geht nichts mehr. Der Lolin32 geht dann in einen Dauerreboot. Das Log sieht so aus:

Rebooting... ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x17 (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:2 load:0x3fff0030,len:1184 load:0x40078000,len:13232 load:0x40080400,len:3028 entry 0x400805e4 I: Initializing FS .. I: .. done I: Config Version: 4 I: Settings valid: true I: Radio Config: SPI Frequency = 1 Mhz Channel = 76 (~ 2476 MHz) Model = nRF24L01+ RF Data Rate = 250 KBPS RF Power Amplifier = PA_LOW RF Low Noise Amplifier = Enabled CRC Length = 16 bits Address Length = 5 bytes Static Payload Length = 32 bytes Auto Retry Delay = 1000 microseconds Auto Retry Attempts = 15 maximum Packets lost on current channel = 0 Retry attempts made for last transmission = 0 Multicast = Disabled Custom ACK Payload = Disabled Dynamic Payloads = Enabled Auto Acknowledgment = Enabled Primary Mode = TX TX address = 0xe7e7e7e7e7 pipe 0 ( open ) bound = 0xe7e7e7e7e7 pipe 1 ( open ) bound = 0x7474748601 pipe 2 (closed) bound = 0xc3 pipe 3 (closed) bound = 0xc4 pipe 4 (closed) bound = 0xc5 pipe 5 (closed) bound = 0xc6 I: DTU_SN: 86747474 E (16469) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (16469) task_wdt: - loopTask (CPU 1) E (16469) task_wdt: Tasks currently running: E (16469) task_wdt: CPU 0: IDLE E (16469) task_wdt: CPU 1: ipc1 E (16469) task_wdt: Aborting.

abort() was called at PC 0x4010feb8 on core 0

Backtrace: 0x40083bbd:0x3ffbeccc |<-CORRUPTED

[geronet1]

Ich hab zwei mit W5500 laufen, Version 0.8.93 ab 0.8.94 ist anders:

• switched AsyncWebServer library
• Ethernet version now uses same AsyncWebServer library as Wifi version deshalb hab ich noch nicht geupdated :-D

[hans341]

Das ist mir auch klar. Ich habe mein Produktiv-Ahoy auch weiter auf 0.8.93 laufen. Ich habe mir jetzt nur ein zweites Test-System gebaut. Mit dem habe ich gestern Abend dann ein bisschen probiert. Und wenn ich mich nicht ganz irre, war es sogar so, daß eine Web-Install mit 0.8.83 > 0.8.97 > 0.8.97eth schon dafür gesorgt hat, dass Partitionen nicht (mehr) gemounted/gefunden hat. Daher war ich dann auf 0.8.21 zurückgegangen....

Ich nutze dafür einen Lolin32, W5500 + nRF24L01+

Hast Du (@geronet1 ) das auch so oder hast Du einen "echten" ESP32 dran? Mich würde da mal das Pinout interessieren. Das bekomme ich nämlich nicht zu Fliegen (für ein ESP32 38Pin anstatt Lolin32)...

[geronet1]

Was ist ein "echter" ESP32? Mein Konfigurationen je 1x: ESP32 W5500 LAN mit passivem POE und NRF24 ESP32 W5500 LAN mit passivem POE und CMT ESP32 Wifi und NRF24

Die ESP hab ich von https://www.berrybase.de/esp32-nodemcu-development-board?c=2473

Pinout:

Leider hab ich zur Zeit nur einen defekten W5500 hier rumliegen, sonst könnt ich die neue Version auch testen. Dazu bräuchte ich nur den IC selbst zum auflöten..

[hans341]

Danke für das Pinout - jetzt habe auch ich das W5500 mit dem ESP32-38Pin zum Laufen bekommen (mit v0.8.93). Irgendwie hatte ich ein Kabel falsch... Und das Pinout... jaaa, da war ich selbst nicht in der Lage das zu finden....

[kct-networx]

I'm changelog stand was von "new network routines". Hat jemand von euch probiert ob >0.8.100 jetzt wieder läuft? Hab leider keine Test Instanz hier.

[Edibo63]

Noch nicht. Baue in den nächsten Tagen eine DTU zum Testen.

[hans341]

Hab's grad mal getestet: Weder die 100 noch die 101 läuft bzgl. W5500. War aber auch nicht wirklich zu erwarten - hätte im ChangeLog dann sicher ein Bezug zu #886 oder #1506 gestanden....

[lumapu]

in neuen Versionen sollte per Standard die Ethernet Verbindung aus sein. Zudem gibt es jetzt einen WiFi AP, der nur zur Einrichtung dient. Verbindet man sich, so kann man die Pins des Ethernet einstellen und speichern, ab dann geht der AP aus sobald per Ethernet eine IP zugewiesen wurde. Bin gespannt ob es so funktioniert. Bei mir konnte ich es erfolgreich testen. Beim Fusion Board habe ich die Erstellung schon mit rein kompiliert, bei den anderen ESP32 nicht, da hier die Zuordnung willkürlich sein kann.

[Edibo63]

Um von 0.8.93 upzudaten muss dabei das Netzwerkkabel abgesteckt werden um den Wifi AP zu starten?

[hans341]

Also ich habe es jetzt mal mit der v102 auf einem ESP32 (Lolin32) probiert. Bin von Web-Install v0.8.83 auf wlan v0.8.102 und dann auf "v0.8.102eth". Der AP war dann in der Tat da und man konnte das Pinout einstellen (hat aber direkt gepasst). Hatte dann den Eindruck, daß der Reboot-Button nicht ging (oder es war so schnell, daß man es nicht merkt...) Irgendwann war der Lolin dann doch per eth verbunden. Mit der v102 kann man es also probieren !!!

Ich habe aktuell aber noch das Probem, daß der Lolin mein NRF24L01+ jetzt nicht (mehr) erkennt. Mit v.8.83 etv. lief er. Am Pinout habe ich (und auch die v102) nichts geändert. Hier ist mir aktuell noch nicht klar, wo der Fehler liegt.... Ansonsten sieht's super gut aus!

Ergänzung: Bin jetzt noch mal zurück auf v0.8.83wlan und v0.8.102wlan. Dann wird der NRF24L01+ erkannt und läuft. Spiele ich die 102eth auf ist er "weg", bei System steht "not connected" und "NRF24 Data Rate" = "undefinedbps". Alles gleiches Pinout. Müsste er nicht "250 kbps" automatisch erkennen oder kann ich da noch irgendwo was einstellen, was ich übersehe?

[kct-networx]

Kann ich genau so bestätigen. Kommunikation über NRF24+ ist nicht mehr möglich. Zusätzlich hat bei mir die Web GUI eine extrem langsame Reaktionszeit. So als würde irgendwas an der Performance nagen. Die ping Zeiten liegen konstant bei 2ms. Versucht man eine andere Firmware bin hochzuladen, geht der ping locker auf 400ms oder timeout. Dadurch kann ich von der 103 auch nicht mehr via Web update zurück auf die 93.

Ist das bei euch auch so?

[Edibo63]

War beim Update auf 0.8.94 so. Kam nur durch neu flashen wieder raus. Die anderen Updates habe ich noch nicht ausprobiert. Im Wizard kann man ein Reset einstellen. Das habe ich am W5500 gar nicht verkabelt.

[dtuuser]

Ich hatte mit der 101 das Problem, dass bei "Interrupt Pin working" False stand und somit keine Daten empfangen wurden. Dann habe ich ein anderes Netzteil genommen und aus False wurde True und die Daten kommen seit dem. Eventuell zieht der ESP32 mit Ethernet mehr Strom als mit WLan und die Spannung am NRF24+ bricht ein

[hans341]

Ich komme da auch nur per Flash wieder weg, also von 102eth auf 102wlan zum Beispiel. Vorhin ging aber das Update von 102eth auf 103eth. Ändert aber am nicht vorhandenen NRF nichts... Netzteil habe ich bisher noch nicht probiert, ESP hing bisher immer nur am USB von Laptop. Test durchgeführt: Es ändert m.E. aber nichts.

Das "Reset" im Wizard habe ich auch gesehen, ist auch im GUI einstellbar, hatte ich bisher aber auch nicht. Keine Ahnung, ob erforderllich und was es bewirken könnte?

[kct-networx]

Ich verstehe nicht was ein anderes Netzteil damit zu tun haben sollte. Wäre demzufolge ja eine Änderung per Software, die den Stromverbrauch dermaßen in die Höhe treibt, dass hier nun ordentlich Power und Watt notwendig sind. Und sobald wir wieder zurück sind auf 93, reichen wieder 500mA per USB? Sorry, kann ich nicht wirklich glauben.

[dtuuser]

Ich hatte meinen bis zur 101 an einem USB Port an einem Router, parallel zu einer Webcam. Da reichten knappe 250mA. Dann habe ich ein Netzteil mit 500mA getestet, auch False beim "Interrupt Pin working". Mit einem 1A Netzteil keine Probleme und keine Reboots. Aber manchmal ist die WebGui für Minuten nicht erreichbar.

[lumapu]

Um von 0.8.93 upzudaten muss dabei das Netzwerkkabel abgesteckt werden um den Wifi AP zu starten?

eigentlich nicht, da Ethernet standardmäßig aus ist. Ich muss gestehen, ein Update habe ich nicht getestet - beim entwickeln geht das step by step nebenbei

[lumapu]

War beim Update auf 0.8.94 so. Kam nur durch neu flashen wieder raus. Die anderen Updates habe ich noch nicht ausprobiert. Im Wizard kann man ein Reset einstellen. Das habe ich am W5500 gar nicht verkabelt.

der reset ist optional

[lumapu]

evtl. gibt es beim SPI Probleme, der wird evtl. von beiden genutzt. Ich schaue nochmal drauf und melde mich wieder

[lumapu]

heute wurde der Fehler gefunden, es gibt gleich eine 0.8.104

[kct-networx]

Das sieht sehr gut aus! Danke 👍 Kommunikation übe NRF und Ethernet funktionieren nun, die Uptime zählt kontinuierlich hoch, was wiederum auf Betrieb ohne Reboots schließen lässt.

Die Performance der We-GUI ist allerdings, verglichen mit 0.8.93, sehr träge. Irgendetwas frisst ordentlich Performance, ggf. sogar der Aufruf der Web-GUI selbst Das wiederum beeinträchtigt offensichtlich die WR Kommunikation: Dort sehe ich timeouts, wenn der ESP32 gerade "beschäftigt" ist. In 0.8.93 lief die WR Kommunikation unabhängig von der Nutzung der Web-GUI ohne timeout/loss bei mir.

PS: Bin per Web update auf die 104 (kein fresh Flash), dann im AP Mode die Ethernet settings, dann Neustart mit Ethernet

[hans341]

Hallo, habe eben auch die 104 getestet. Sie läuft und das NRF ist wieder da. Hatte erst ein Update von 103 versucht. Das scheitete aber. Muss an der 103 liegen, kam davon gar nicht mehr weg. Also 104 per Webinstall über 0.8.83.... Was bei mir immer schwierig ist, ist der AP-Modus für's eth-Aktivieren. Der taucht zwar zuverlässig auf, aber ich habe kein "Feedback" vom Reboot-Buttons. Ich habe immer den Eindruck, der reagiert nur sehr zufällig... Als 104 dann lief, habe ich zur Sicherheit alle Einstellungen neu vorgenommen und kein Backup eingespielt. Ist ja schon eine erhebliche Änderung von 93 zu 104, denke ich. Ob das nötig ist, weiss ich aber nicht?

Habe die 104 jetzt auf 2 ESPs aufgespielt: Einen ESP32 38Pin und einen Lolin32. Bei ESP32 per Update von 0.8.93. Beim Lolin32 über WebInstall wie oben geschrieben. Habe den Eindruck, daß der ESP32 sehr träge läuft, während der Lolin rennt.... Warum das so ist ..... keine Ahnung....