Forum: Mikrocontroller und Digitale Elektronik ESP.restart() feuert Daten in WS2812


von kv b (Gast)


Lesenswert?

Hi,

mein ESP32-Projekt benutzt die WPS-Funktion um sich mit einem WLAN zu 
verbinden. Nach erfolgreicher Aushandlung funktioniert der Connect mit 
dem Router nicht direkt. Nach einem Reset klappt es aber. Deswegen lasse 
ich den Controller nach dem WPS einfach mit
1
ESP.restart()
 durchstarten. Soweit tut's das.

Nur habe ich eine WS2812 Lichterkette an einem Pin hängen (über die 
FastLED library), die plötzlich kurz hell erstrahlt wenn er neu startet. 
Bei einem Hardwarereset passiert das nicht.

Hat jemand eine Idee, was das Problem ist und was ich tun kann?

Grüße
kv

von Stefan F. (Gast)


Lesenswert?

kv b schrieb:
> Hat jemand eine Idee, was das Problem ist und was ich tun kann?

Hmm, warte, lass mich mal in meine Glaskugel gucken 
.............................. nee sorry, die Glaskugel kann dein 
Programm auch nicht sehen.

von kv b (Gast)


Lesenswert?

Stefan F. schrieb:
> kv b schrieb:
>> Hat jemand eine Idee, was das Problem ist und was ich tun kann?
>
> Hmm, warte, lass mich mal in meine Glaskugel gucken
> .............................. nee sorry, die Glaskugel kann dein
> Programm auch nicht sehen.

das Programm hat mehrere 1000 Zeilen Code. Ich habe versucht, die beiden 
Aspekte des Programms hervorzuheben, die ich für relevant halte, viel 
gibt es da nicht zu sagen. Aber gerne:
1
// wifi-modul
2
// der callback der auf WPS success den restart macht
3
void onWiFiEvent(WiFiEvent_t event, arduino_event_info_t info)
4
{
5
  switch (event)
6
  {
7
 ...
8
  case ARDUINO_EVENT_WPS_ER_SUCCESS:
9
    log_i("WPS with %s Successfull, restarting ESP now.", WiFi.SSID().c_str());
10
11
    ESP.restart();
12
...
13
}
14
15
// display-modul
16
// 
17
// die einzige Stelle, an dem ich den Datenpin für die LEDs anspreche
18
void Display_init()
19
{
20
    FastLED.addLeds<WS2812B, LED_PIN, GBR>(leds, NUM_LEDS);
21
    ...
22
}

War davon ausgegangen, dass das nicht so aufschlussreich ist, das zu 
zeigen. Kann mich natürlich irren.

Ich war eher mit der Vermutung hier hergekommen, dass ESP.restart() 
irgendwelche erratischen Zustände an den Pins hervorruft, die die LEDs 
als Daten interpretieren und es vielleicht eine Möglichkeit gibt, das zu 
unterbinden, weniger, dass es direkt an meinem Code liegt.

Ich habe versucht den pinMode von LED_PIN auf was anderes zu setzen. 
Bringt nichts.

von Matze (Gast)


Lesenswert?

Ach komm schon...
Wenigstens die Definition der Pins..

Wahrscheinlich hast einen der strapping pins erwischt, Google mal 
dannach, einige Pins beim Esp32 blöden beim booten rum :-)

Versuch mal nen andern pin oder... Wenigstens nen Schaltplan oder das 
Programm. Wenn es halbwegs ordentlich kommentiert und Strukturiert ist 
werden wir des schon schaffen zu lesen.

von Matze (Gast)


Lesenswert?

Nur falls du dein google kaputt ist... 
https://randomnerdtutorials.com/esp32-pinout-reference-gpios/

von kv b (Gast)


Lesenswert?

verdammt, ja, hast Recht. Es ist GPIO12, scheint einer der Strapping 
Pins zu sein. Von denen wusste ich dummerweise nix (Anfänger, erstes 
ESP-Projekt). Was neues gelernt. Danke.

Leider zu spät für einen anderen Pin, da auf bereits gefertigter 
Platine. Das heißt neue Platinenrevision. Oder ich muss rausfinden, ob 
es eine Möglichkeit gibt nach WPS auch ohne restart mit dem Router zu 
connecten.

von Stefan F. (Gast)


Lesenswert?

kv b schrieb:
> das Programm hat mehrere 1000 Zeilen Code. Ich habe versucht, die beiden
> Aspekte des Programms hervorzuheben, die ich für relevant halte, viel
> gibt es da nicht zu sagen. Aber gerne:

So wird das nichts.

Wenn du nicht das ganze Programm zeigen willst, dann reduziere es 
Schrittweise auf die kleinste mögliche Version, bei der dein Fehler noch 
auftritt. Die schauen wir uns dann an.

kv b schrieb:
> Ich war eher mit der Vermutung hier hergekommen, dass ESP.restart()
> irgendwelche erratischen Zustände an den Pins hervorruft, die die LEDs
> als Daten interpretieren und es vielleicht eine Möglichkeit gibt, das zu
> unterbinden, weniger, dass es direkt an meinem Code liegt.

Guter Gedanke. Aber dazu können wir nichts sage, solange nicht einmal 
klar ist, welchen GPIO Pin du verwendet hast.

kv b schrieb:
> Es ist GPIO12, scheint einer der Strapping Pins zu sein.

Acha, na da hast du es.

von Schlafloser (Gast)


Lesenswert?

Hmm, der 12er ist aber erstmal "nur" ein Boot selector. Aktive PWM gibt 
er nicht aus. Vllt mal nen pull down an den pin?

von kv b (Gast)


Lesenswert?

Stefan F. schrieb:
> kv b schrieb:

> Guter Gedanke. Aber dazu können wir nichts sage, solange nicht einmal
> klar ist, welchen GPIO Pin du verwendet hast.

Hab ich in der Tat versäumt. Auch zum Fragenstellen was dazugelernt :)

von W.A. (Gast)


Lesenswert?

kv b schrieb:
> Leider zu spät für einen anderen Pin, da auf bereits gefertigter
> Platine. Das heißt neue Platinenrevision.

Es ist nie zu spät - nennt sich "Entwicklungsschleife" ...

Früher (tm) hätte man das erstmal mit einem Skalpell und etwas 
Cu-Lackdraht behoben, falls es sich nicht um eine "Großserie" handelt.

von Stefan F. (Gast)


Lesenswert?

kv b schrieb:
> Auch zum Fragenstellen was dazugelernt :)

Gut.

Bei mir auf der Arbeit sollen Programme/Geräte nicht final von den 
Entwicklern getestet werden, sondern von anderen Personen. Je weniger 
die Tester an der Entwicklung beteiligt waren, umso besser. Die 
Entwickler sollten auch nicht die Testprozeduren erfinden. Denn dabei 
ist die Gefahr ist viel zu hoch, dass man sich zu sehr auf gut 
durchdachte Sachen beschränkt, und dabei die Punkte vergisst, die man 
schon während der Entwicklung die ganze Zeit nicht auf dem Schirm hatte.

von kv b (Gast)


Lesenswert?

Schlafloser schrieb:
> Hmm, der 12er ist aber erstmal "nur" ein Boot selector. Aktive PWM gibt
> er nicht aus. Vllt mal nen pull down an den pin?

Habe doch eine Lösung gefunden und war scheint's ein Problem mit 
Nebenläufigkeit. Der event callback, den ich an die Wifi library 
übergebe macht den Restart, währenddessen aber meine main loop 
möglicherweise noch irgendetwas tut. Ich setze jetzt stattdessen ein 
Flag aus dem Callback herausm, auf das die main loop prüft und dann dort 
den restart macht. Was genau jetzt die Ursache ist, weiß ich zwar immer 
noch nicht, aber das Problem scheint weg zu sein.

Danke an alle für die Hilfe und beim nächsten Mal versuche ich etwas 
mehr Informationen gleich mitzugeben :)

von Stefan F. (Gast)


Lesenswert?

kv b schrieb:
> Habe doch eine Lösung gefunden und war scheint's ein Problem mit
> Nebenläufigkeit. Der event callback, den ich an die Wifi library
> übergebe macht den Restart, währenddessen aber meine main loop
> möglicherweise noch irgendetwas tut.

Ohne Quelltext kann ich dir nicht folgen. Aber schön, dass du den Fehler 
beheben konntest.

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.