Does somebody know what causes Error Message rc=-13 on esp8266 during softap Mode? Soft ap chrashes then and wifi connection closes....
I am serving all my not specified Requests through a "notFound Handler":
In the context of ESP8266, an Error Message rc=-13 typically indicates an issue related to memory allocation. Specifically, rc=-13 means that the ESP8266 core is encountering a "Out of Memory" error.
This error can occur for various reasons:
Insufficient Free Heap: If your code uses too much memory, or if there are memory leaks, it can result in insufficient free heap space. This can cause errors during operations that require dynamic memory allocation, such as connecting to a network in SoftAP mode.
Memory Fragmentation: The heap can become fragmented, meaning that there may be enough free memory, but it's not contiguous. This can also cause allocation failures.
Stack Overflow: If your code uses a lot of stack space (due to deeply nested function calls or large local variables), it can cause this error.
Hardware or Platform Limitations: Depending on the exact model and configuration of your ESP8266 board, there might be specific constraints on memory usage.
Here are some steps you can take to address this issue:
Check Your Code: Review your code to ensure that you're managing memory properly. Look for places where you allocate memory (using malloc, new, etc.) and make sure you free it when you're done.
Avoid Dynamic Memory Allocation: Minimize dynamic memory allocation in critical sections of your code. Instead, try to use statically allocated memory or pre-allocated buffers.
Optimize Code: Consider optimizing your code to reduce memory usage. This might involve using smaller data types, minimizing unnecessary variables, and avoiding large libraries if they're not needed.
Check for Memory Leaks: Make sure there are no memory leaks in your code. Ensure that all dynamically allocated memory is properly deallocated.
Monitor Heap Usage: You can use the ESP.getFreeHeap() function to monitor the free heap space at different points in your code. This can help identify where memory is being consumed.
Consider Hardware Limitations: Depending on your specific ESP8266 module, it might have different memory constraints. Make sure you're aware of the limitations of your particular hardware.
Update SDK/Toolchain: Ensure you're using an up-to-date version of the ESP8266 SDK and toolchain.
If you're still experiencing issues after taking these steps, it might be helpful to provide more context or specific code snippets so that I can offer more targeted advice.
My personal opinion: The first stable SDK was 1.5.3 quickly followed by 1.5.4 which runs also fine. New features and refactoring introduced lots of new problems in the 2.x releases for several years, therefore I stopped trying newer versions. So I do not know how the quality of recent versions is, but I think a downgrade to some few previous versions is worth a try.
Ich nutze die adafruit_neopixel.h libary um WS2812b LED's anzusteuern. Wenn ich in der Loop die Animationsfunktionen aufrufe kommt es zu diesen verhalten mit rc=-13!
Im Internet konnte ich irgendwo lesen, dass diese Libary mit Interrupts arbeitet und z.B. millis() nicht mehr richtig funktioniert. Wäre das des Rätsels Lösung, dass die Libary mir diese Probleme verursacht?
Zu den Animationsfunktionen: Dies habe ich komplett asynchron aufgebaut! In der ganzen Loop() funktion gibt es kein Delay(), kein memset(), keine Strings und es werden auch keine "riesigen" Arrays instanziert oder sonst was! Nur Basic neopixel funktionen wie show(), setpixelcolor() oder clear().
Bestimmt wieder ein Problem mit der Firmware... Ich hatte vom ESP8266 eigentlich genug als ich gelesen habe, daß der alle paar Millisekunden einen Rücksprung zur Firmware braucht (im einfachsten Fall ein kurzes Delay) damit er nicht crasht. Dann lieber ESP32, auch wenn der leider deutlich mehr Strom braucht.
Ich hatte vom ESP8266
eigentlich genug als ich gelesen habe, daß der alle paar Millisekunden
einen Rücksprung zur Firmware braucht (im einfachsten Fall ein kurzes
Delay) damit er nicht crasht.
Ich verstehe, dass das lästig ist. Andererseits ist das ein sehr gängiges Pattern auf Mikrocontrollern ohne Betriebssystem (RTOS oder so). Früher oder später muss man sich damit anfreunden.
Ja ich nutze in der loop am ende immer yield() und in den switch/cases immer das gleiche schema am Begin auch mal yield() und dann die Animation, wobei innerhalb der Animation funktion ein durchlauf herscht OHNE delay(), oder for() oder sonst irgendwas!
1
case20:
2
// Fill along the length of the strip in various colors... -->> here GREEN
Sollte mal jemand wieder über dieses Thema stoßen:
Es ist tatsächlich die Kombination der User-Freundlichen Adafruit_Neopixel.h Libary und die Verwendung der ESP-basierten WiFi Funktionen problematisch hinsichtlich der Stabilität!
Habe den ganzen Code nun auf die NeoPixelBus.h Libay umgeschrieben was die Ansteuerung der LED's betrifft - und meinen bisherigen Problembehafteten WiFi Teil Bestand gelassen - Das Projekt läuft nun wunderbar und es kommt zu keinen WiFi Abstürzen mehr!
Die Adafruit_Neopixel.h Libary ist sehr schnell und einfach anzuwenden wenn man LED's leuchten lassen möchte. Wenn man weitere Features hinzufügen will empfiehlt es sich ganz klar eine andere Libary zu verwenden.
