Forum: Mikrocontroller und Digitale Elektronik ESP8266 - SoftAP Stopps Working


von Johannes R. (johannes_r981)


Lesenswert?

Vielleicht kann mir hier jemand dazu helfen:

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":
1
void SSEWrapper::notFound(AsyncWebServerRequest *request){
2
unsigned long deltaT = millis();
3
if(SSEWrapper::captivePortal(request)) {
4
}else{
5
SERIAL.println("Not Found!");
6
request->send(404, "text/plain", "Not found");
7
SERIAL_INFORMATION.print("notFound [ms]: ");
8
SERIAL_INFORMATION.println(millis()-deltaT);
9
}
10
}
Within that i check if captivePortal is allowed/not allowed (reducing 
amount of redirections only to the necessary ones):
1
boolean SSEWrapper::captivePortal(AsyncWebServerRequest *request){
2
unsigned long deltaT = millis();
3
SERIAL.println("[SSE] captivePortal");
4
if (isCaptivePortalAllowed(request->host().c_str())) {
5
snprintf(SSEWrapperPuffer, sizeof(SSEWrapperPuffer), "%s", "8.8.8.8");
6
snprintf(CaptivePortalBuffer, sizeof(CaptivePortalBuffer), "http://%s/", SSEWrapperPuffer);
7
if (!isIp(request->host().c_str()) && strcmp(request->host().c_str(), CaptivePortalBuffer)!= 0) {
8
SERIAL.print("[CP] Request redirected: ");
9
SERIAL.println(CaptivePortalBuffer);
10
ESPDebuggingFunction();
11
request->redirect(CaptivePortalBuffer);
12
SERIAL_INFORMATION.print("captivePortal <OK> [ms]: ");
13
SERIAL_INFORMATION.println(millis()-deltaT);
14
return true;
15
}else{
16
SERIAL_INFORMATION.print("captivePortal <NOK>[ms]: ");
17
SERIAL_INFORMATION.println(millis()-deltaT);
18
return false;
19
}
20
}else{
21
SERIAL_INFORMATION.print("captivePortal <ELSE> [ms]: ");
22
SERIAL_INFORMATION.println(millis()-deltaT);
23
return false;
24
}
25
}
"Checking Function":
1
boolean SSEWrapper::isCaptivePortalAllowed(const char* host) {
2
unsigned long deltaT = millis();
3
SERIAL.print("[SSE] isCaptivePortalAllowed: ");
4
SERIAL.println(host);
5
ESPDebuggingFunction();
6
for(const char* validHost : validHosts) {
7
if(strcmp_P(host, validHost) == 0) {
8
SERIAL_INFORMATION.print("isCaptivePortalAllowed <OK>[ms]: ");
9
SERIAL_INFORMATION.println(millis()-deltaT);
10
return true;
11
}
12
}
13
SERIAL_INFORMATION.print("isCaptivePortalAllowed <NOK>[ms]: ");
14
SERIAL_INFORMATION.println(millis()-deltaT);
15
return false;
16
}
And the "Allowed Hosts:":
1
const char* SSEWrapper::validHosts[] = {
2
("captive.apple.com"),
3
("example.com"),
4
("captive.apple.com/hotspot-detect.html"),
5
("apple.com/library/test/success.html"),
6
("connectivitycheck.gstatic.com/generate_204"),
7
("connectivitycheck.gstatic.com"),
8
("www.google.com"),
9
("play.googleapis.com"),
10
("clients3.google.com/generate_204"),
11
("msftncsi.com/ncsi.txt"),
12
("nmcheck.gnome.org/check_network_status.txt"),
13
("www.msftconnecttest.com"),
14
("ipv6.msftconnecttest.com"),
15
("captiveportal.kabeldeutschland.de"), // German ISP
16
("wifi.sky.com"), // Sky WiFi Greatbritan
17
("detectportal.firefox.com"), // Mozilla Firefox Captive Portal testpage
18
("captive.v2ex.co")
19
};

If i Run this i got wihtin the serial output:
1
mode : softAP(4a:55:19:16:55:e7)
2
3
add if1
4
5
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
6
7
bcn 100
8
9
bcn 0
10
11
del if1
12
13
usl
14
15
add if1
16
17
dhcp server start:(ip:8.8.8.8,mask:255.255.255.0,gw:8.8.8.8
18
19
bcn 100
20
21
---------[WiFi Info]-----
22
23
[WiFi] IP Address: 8.8.8.8
24
THIS IS MY SSID AND MY PASSWORD TO SOFTAP
25
Channel: 1       Physical Mode: 3
26
--------
27
[WiFi] Services restarted
28
Free heap: 22824        Fragmentation Metric [%]: 2     Max free Block Size in RAM: 22528
29
---END-SETUP---
30
add 1
31
aid 1
32
station: 08:11:96:3b:17:38 join, AID = 1 //Here my PC joined
33
:urn 28
34
:urd 28, 28, 0
35
:urn 28
36
:urch 56, 28
37
:urch 112, 28
38
:urch 168, 28
39
:urch 224, 28
40
:udr
41
:urd 28, 28, 0
42
:urd 28, 28, 0
43
:ust rc=-13
44
:urd 28, 28, 0
45
:urd 28, 28, 0
46
:ust rc=-13
47
:urd 28, 28, 0
48
:ust rc=-13
49
:urn 41
50
:urd 41, 41, 0
51
[SSE] captivePortal
52
[SSE] isCaptivePortalAllowed: www.msftconnecttest.com
53
Free heap: 20464        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 20296
54
isCaptivePortalAllowed <OK>[ms]: 5
55
isIP: www.msftconnecttest.com
56
[CP] Request redirected: http://8.8.8.8/
57
Free heap: 20464        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 20296
58
captivePortal <OK> [ms]: 21
59
:urn 42
60
:urd 42, 42, 0
61
:urch 70, 42
62
:urch 140, 34
63
:urch 202, 34
64
:urd 42, 42, 0
65
:urd 34, 34, 0
66
:urd 34, 34, 0
67
[SSE] captivePortal
68
[SSE] isCaptivePortalAllowed: ipv6.msftconnecttest.com
69
Free heap: 19400        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19208
70
isCaptivePortalAllowed <OK>[ms]: 5
71
isIP: ipv6.msftconnecttest.com
72
[CP] Request redirected: http://8.8.8.8/
73
Free heap: 19400        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19208
74
captivePortal <OK> [ms]: 21
75
[SSE] captivePortal
76
[SSE] isCaptivePortalAllowed: www.msftconnecttest.com
77
Free heap: 20064        Fragmentation Metric [%]: 6     Max free Block Size in RAM: 18984
78
isCaptivePortalAllowed <OK>[ms]: 5
79
isIP: www.msftconnecttest.com
80
[CP] Request redirected: http://8.8.8.8/
81
Free heap: 20064        Fragmentation Metric [%]: 6     Max free Block Size in RAM: 18984
82
captivePortal <OK> [ms]: 21
83
[SSE] captivePortal
84
[SSE] isCaptivePortalAllowed: www.msftconnecttest.com
85
Free heap: 20464        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 20288
86
isCaptivePortalAllowed <OK>[ms]: 5
87
isIP: www.msftconnecttest.com
88
[CP] Request redirected: http://8.8.8.8/
89
Free heap: 20464        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 20288
90
captivePortal <OK> [ms]: 21
91
:urn 28
92
:urch 56, 28
93
:urd 28, 28, 0
94
:urd 28, 28, 0
95
:urn 28
96
:urch 56, 28
97
:urch 112, 28
98
:urch 168, 28
99
:urch 224, 28
100
:udr
101
:urd 28, 28, 0
102
:urd 28, 28, 0
103
:urd 28, 28, 0
104
:urd 28, 28, 0
105
:urd 28, 28, 0
106
:urch 56, 28
107
:urch 112, 28
108
:urd 28, 28, 0
109
:urd 28, 28, 0
110
:urn 28
111
:urch 56, 28
112
:urd 28, 28, 0
113
:urd 28, 28, 0
114
:urn 28
115
:urch 56, 28
116
:urch 112, 28
117
:urch 168, 28
118
:urch 224, 28
119
:urd 28, 28, 0
120
:urd 28, 28, 0
121
:urd 28, 28, 0
122
:urd 28, 28, 0
123
:urd 28, 28, 0
124
:urn 28
125
:urch 56, 28
126
:urch 112, 28
127
:urch 168, 28
128
:urd 28, 28, 0
129
:urd 28, 28, 0
130
:urd 28, 28, 0
131
:urd 28, 28, 0
132
:urch 56, 28
133
:urch 112, 28
134
:urd 28, 28, 0
135
:urd 28, 28, 0
136
[SSE] captivePortal
137
[SSE] isCaptivePortalAllowed: ipv6.msftconnecttest.com
138
Free heap: 19704        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19528
139
isCaptivePortalAllowed <OK>[ms]: 5
140
isIP: ipv6.msftconnecttest.com
141
[CP] Request redirected: http://8.8.8.8/
142
Free heap: 19704        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19528
143
captivePortal <OK> [ms]: 21
144
:urn 28
145
:urch 56, 28
146
:urch 112, 28
147
:urch 168, 28
148
:urd 28, 28, 0
149
[SSE] captivePortal
150
[SSE] isCaptivePortalAllowed: www.msftconnecttest.com
151
Free heap: 19688        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19512
152
isCaptivePortalAllowed <OK>[ms]: 5
153
isIP: www.msftconnecttest.com
154
[CP] Request redirected: http://8.8.8.8/
155
Free heap: 19688        Fragmentation Metric [%]: 1     Max free Block Size in RAM: 19512
156
captivePortal <OK> [ms]: 21
157
:urd 28, 28, 0
158
:urd 28, 28, 0
159
:urd 28, 28, 0
160
:urn 35
161
:urd 35, 35, 0
162
:ust rc=-13
163
:urn 35
164
:urd 35, 35, 0
165
:ust rc=-13
166
:urn 41
167
:urd 41, 41, 0
168
:ust rc=-13
169
:urn 41
170
:urd 41, 41, 0
171
:ust rc=-13
172
:urn 28
173
:urch 56, 28
174
:urch 112, 28
175
:urch 168, 28
176
:urd 28, 28, 0
177
:ust rc=-13
178
~~~ LOT MORE BUT canceld due commentar limit~~~~
179
:ust rc=-13
180
:urn 46
181
:urd 46, 46, 0
182
:ust rc=-13
183
:urn 55
184
:urch 83, 43
185
:urd 55, 55, 0
186
:ust rc=-13
187
:urch 154, 34
188
:urd 43, 43, 0
189
:ust rc=-13
190
:urd 34, 34, 0
191
:ust rc=-13
192
:urn 34
193
:urd 34, 34, 0
194
:ust rc=-13
195
:urn 48
196
:urd 48, 48, 0
197
:ust rc=-13
198
station: 08:11:96:3b:17:38 leave, AID = 1
199
rm 1
200
$T0b#e6
AP is dead....

von Wastl (hartundweichware)


Angehängte Dateien:

Lesenswert?

Johannes R. schrieb:
> Vielleicht kann mir hier jemand dazu helfen:

Fuck!

von Johannes R. (johannes_r981)


Lesenswert?

Wastl schrieb:
> Fuck!

Serieller Output ist ja jetzt kein Sourcecode....

Und wenn diese 3 Funktionen als "zu-lange" Empfunden werden entschuldige 
ich mich höchstpersönlich bei dir...

von Wastl (hartundweichware)


Lesenswert?

Johannes R. schrieb:
> Serieller Output ist ja jetzt kein Sourcecode....

Das heisst also diesen seriellen Output kann man nicht in eine
Textdatei packen und als Anhang posten?

Dein gesamter Post umfasst mehr als 500 Zeilen. Soll man diesen
Scheiss im Browser-Fenster lesen?

von Gerald K. (geku)


Lesenswert?

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:

1. **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.

2. **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.

3. **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.

4. **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:

1. **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.

2. **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.

3. **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.

4. **Check for Memory Leaks**: Make sure there are no memory leaks in 
your code. Ensure that all dynamically allocated memory is properly 
deallocated.

5. **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.

6. **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.

7. **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.

von Steve van de Grens (roehrmond)


Lesenswert?

Gerald K. schrieb:
> **Update SDK/Toolchain**

Or downgrade!

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.

: Bearbeitet durch User
von Johannes R. (johannes_r981)


Lesenswert?

Ich habe das jetzt weiter runter gebrochen.

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().

mfg

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

Ben B. schrieb:
> 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.

von Johannes R. (johannes_r981)


Lesenswert?

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
    case 20:
2
      // Fill along the length of the strip in various colors... -->> here GREEN
3
      yield();
4
      animationRunning = colorWipe(pixels.Color(0, 255,0), 100 * systemParameters.speed, &pixels);
5
      incrementStep(&step, &animationRunning);
6
      break;

Ich werde im nächsten Zuge das mal umbauen auf die FastLED.h Libary - 
diese sollte diesbezüglich eher geeignet sein (hoffe ich mal :) )

LG

von Steve van de Grens (roehrmond)


Lesenswert?

Denke daran, dass yield() den Stack Bedarf erheblich in die Höhe treiben 
kann, je nach dem, wo man es einbaut.

Das Framework ruft die loop() etwa so auf:
1
main() {
2
   init_firmware();
3
   setup();
4
   while (1) {
5
     loop();
6
     process_wlan_events();
7
   }
8
}
9
10
yield() {
11
    process_wlan_events();
12
}

Du kannst auf das "manuelle" Aufrufen von yield() verzichten, wenn deine 
Loop bei jeden Durchlauf maximal 20ms braucht.

: Bearbeitet durch User
von Johannes R. (johannes_r981)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.