ESP32 - Kein WLan ohne Serial monitor

Zeig mal deinen Sketch/Code her.
Wahrscheinlich hängt der Controller in einer Schleife, weil er auf die 
serielle Schnittstelle wartet.

Hallo,

bevor ich den Test Code poste nochmal der Hinweis:

Das LED Pattern in loop() wird in beiden Fällen ausgeführt. Lediglich am 
Power Supply findet keine WLan Verbindung statt. Daher kann ich den Code 
ausschließen, da er in beiden Fällen die setup() erfolgreich durchläuft 
und in die loop() geht.

1

#include "WiFi.h"

2

3

const char* ssid = "";

4

const char* password =  "";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  Serial.begin(9600);

11

12

  WiFi.begin(ssid, password);

13

14

  while (WiFi.status() != WL_CONNECTED) {

15

    delay(500);

16

    Serial.println("Connecting to WiFi..");

17

  }

18

19

  Serial.println("Connected to the WiFi network");

20

21

  pinMode(LED_PIN, OUTPUT);

22

23

}

24

25

void loop() {

26

27

28

  for(int i=0;i<5;i++){

29

    digitalWrite(LED_PIN, HIGH);

30

    delay(200);

31

    digitalWrite(LED_PIN, LOW);

32

    if(i< (5-1)){

33

      delay(200);

34

    }

35

  }

36

37

  delay(3000);

38

}

while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.println("Connecting to WiFi..");
  }

-> Er könnte die Loop gar nicht abarbeiten wenn er keine Verbindung zu 
deinem WLAN Router hergestellt hätte.

Wahrscheinlich wird Dein Board über den 1x4 Pinheader mit Strom 
versorgt. Was hängt da dran?
Zeig mal das Board her.

Hallo,

danke für die Hinweise:

@Thomas R.: Das stimmt absolut... Er scheint auch auch einmal mit dem 
WLan zu verbinden, dann aber sofort die Verbindung zu verlieren... Wie 
gesagt in beiden Fällen geht er in die loop()

@Stefan ⛄ F.: interessanter Hinweis. Muss der 10uF zwischen Input-VCC 
und GND oder zwischen Output (3.3V) Vcc und GND? ich habe bereits einen 
zwischen 3.3v und GND aber vielleicht muss ja einer auch an den 
Eingang... ich teste das...

@Pete K.: An den Pin Header wird nur ein Temperatursensor angeschossen 
(i2c). In allen meiner Testfälle erfolgt die Stromversorgung über den 
USB-C Anschluss

@Stefan ⛄ F.: Ein 10uF am Eingang des LM1117 war es leider nicht :-(

Ok... Ich habe einen Screenshot eingefügt.
Sind aber 2-Layer. Schwer was zu erkennen.

Welche Infos willst du da heraus nehmen die man nicht im Schaltplan 
sieht?

@Stefan ⛄ F.: Ich habe deinen Vorschlag getestet mit einer anderen 
Stromversorgung:

Da ich leider kein ordentliches Netzteil habe das 3.3v liefert habe ich 
mal ein Breakoutboard rein gelötet, das auch ein LM1117 einsetzt. ich 
habe also meinen LM1117 mit einem Breakoutboard ersetzt

==> Es geht!

Aber was heißt das nun konkret? Es kann ja dann nur noch im Umfeld des 
LM1117 liegen.

Ich löte jetzt noch ein bisschen Schummeldraht ein, um deine Theorie zu 
testen. Wenn es nur daran liegt, wäre ich froh. Ich glaube aber ich habe 
den LM1117 falsch angeschlossen, also es fehlen vielleicht noch 
Kondensatoren. Könnt ihr da direkt was aus dem Schaltplan entnehmen was 
ich falsch gemacht habe?

@ Stefan ⛄ F.: Das war es leider nicht. Habe alles umgesetzt. War super 
fummelig hat aber leider nix geholfen.

>- Von allen GND Anschlüssen der USB Buchse zu GND vom Spannungsregler.
>- Vom Spannungsregler GND zu allen GND Anschlüssen des ESP Moduls.
>- Vom 3,3V Ausgang des Spannungsreglers zum VCC Eingang des ESP Moduls.
>- Zusätzlich 100µF an VCC/GND direkt am ESP Modul.

Ich werde jetzt aus dem Breakoutboard den LM1117 rauslöten und bei mir 
einsetzten. Auf meinem steht zwar LM1117 3.3 drauf... aber wer weiß

Ich habe aber auch kein Problem etwas mehr Geld auszugeben (ca 150€) ... 
Vorschläge?

Wolfgang schrieb:

> Der 100µF hat sowieso einen relativ hohen ESR und stützt bei
> niederfrequenten Verbrauchsspitzen. Für kurze Spitzen und steilen
> Flanken, bei denen es dann auch auf die Anbindung ankommt, ist ein
> direkt angebundener kleinerer Kondensator wesentlich wichtiger. Der
> 100µF muss Ladung nachliefern, wenn der kleine bereits den
> hochfrequenten Lastanteil gepuffert hat.

Was kann das konkret für mich bedeuten? ich habe ja bereit einem 100uF 
am ESP getestet. Soll ich nochmal einen anderen dran machen?

Was ich noch habe ist ein 100nF, 47uF, 10n

Ich habe jetzt nochmal das Breakout Board dran gelötet um sicher zu sein 
das das erste mal kein Zufall war... und es war keiner.

Das Breakoutboard habe ich jetzt mal mit angefügt.

Aber eines treibt mich da noch um. Bei diesem Breakoutboard verwende ich 
als In-VCC 7,5V = 4x AA Batterie. Aber das darf doch keinen unterschied 
machen oder?

==> Mir ist auch ein Fehler von mir aufgefallen... Ich schreibe immer 
von einem LM1117, dabei verwende ich einen AM1117!!!!

Habe ich für den AMS1117 dann doch falsche Kondensatoren verwendet??

Ich muss jetzt mal raus finden, welche Kondensatoren das Breakoutboard 
verwendet. Damit geht es ja schließlich

Stefan ⛄ F. schrieb:
> Manuel S. schrieb:
>> Ich schreibe immer von einem LM1117, dabei verwende ich einen AM1117
>
> AM oder AMS? Ich hake nach, weil es von diesen "1117" Spannungsreglern
> in der Tat ganz viele Varianten gibt. Hier wurde schon einmal
> diskutiert, dass deren Eigenschaften nicht gleich sind.
>

Das ist ein AMS1117. die Kondensatoren auf den Breakout sollten am 
Eingang und am Ausgang jeweils 100nF und 10uF sein. Das versuche ich 
jetzt mal dran zu basteln, direkt am AMS1117

Die Fehlerbeschreibung ist sehr komisch. Der ESP scheint in beiden 
Fällen zu laufen (LED Pattern), aber einmal geht WLAN, einmal nicht.

Man könnte vermuten, dass der ESP ständig rebootet und zwar das LED 
Pattern ausführt, aber keine Zeit hat, sich mit dem WLAN zu verbinden. 
Da wäre also die Frage, haben wir es mit einem ständigen Reboot zu tun?

Bitte einmal den ganzen Code posten, so wie das Fehlerbild auch 
entsteht.

Ich habe jetzt super viel Dinge probiert.

Aktuell habe ich zwei "starke Vermutungen":

 * Die Leiterbahnen zwischen USB und AMS1117 sind zu dünn.
     * Ich habe dafür das Breakoutboard direkt mit einem "dicken" 
Schummeldraht an eine separaten USB-C Stecker gemacht und das Breakout 
mit meinem Board verbunden. ==> Geht!
     * Wenn ich das Breakoutboard an meinem USB-C Anschluss anschließe 
geht es nicht. Ich habe hierfür meinen AMS1117 raus gelötet und das 
Breakoutboard dafür dran gemacht
     * Die separate USB Buchse mit dickem Schummeldraht an meinen 
AMS1117 zu machen brachte auch keinen Erfolg --> also muss im Vergleich 
zum BreakoutBoard noch was fehlen

 * AMS1117: Die Kondensatoren am Ausgang sind zu weit weg und es fehlen 
die Kondensatoren am Eingang
     * Das konnte ich leider nicht abschließend prüfen, weil meine 
Versuche die Kondensatoren direkt dran zu löten haben, dann doch kein 
positives Ergebnis gebracht haben
     * Die Kondensatoren und deren Anordnung ist der einzige Unterschied 
vom Breakoutboard zu meinem AMS1117 auf meinem Board

Da es aber mit dem Breakoutboard und einem dicken Schummeldraht+seperate 
USB Buchse gelappt hat, habe ich jetzt keine andere Idee mehr

Das möchte ich jetzt nochmal reproduzieren, und wenn das wieder klappt 
habe ich nur noch die Idee, mein Layout entsprechend anzupassen und ein 
neues PCB zu bestellen um zu testen.

PS: Sorry für die schlechte Formatierung. In der Preview wurden schöne 
Bullet-Points angezeigt.

Vielleicht doch noch mal das Designfile hochladen? Ist das n 
Eagle-Projekt oder KiCad?
Kann ja sein, dass sich das jemand mit bissl Erfahrung mal kurz 
ansieht...

Ich habe nix zu verstecken...
Gerne darf da jemand mal drüber schauen wenn's hilft.

Hab's angehängt

Ist ein Fusion 360 File. Keine Ahnung zu was das alles kompatibel ist.

Wenn ich nun mein Board überarbeite ....

Habt Ihr generelle Hinweise was ich anders Besser machen sollte beim 
Board-Design und der Platzierung der Bauteile.

Habe ihr generelle Tipps was ich vorsehen einbauen sollte aus eurer 
Erfahrung mit dem ESP32 heraus?

@Arno:

Danke für deine Anregungen. Ich werde das mitnehmen. Für mich sind 
solche Infos wichtig um in Zukunft besser auf ein besseres Design achten 
zu können.

Hallo zusammen,

ich habe nun das neue PDC Design testen können.
Da habe ich beim AMS1117 nun jeweils am Input und am Output 10nf und 
100uF Kondensatoren angefügt.

Leider ohne Erfolg :-(

Ich habe jetzt mal zum Test, den CH340C rausgelötet nachdem ich den 
ESP32 geflasht habe.

... Tatsächlich scheint es damit doch was zu tun zu haben. Aber ich sehe 
nicht was.  ==> Der ESP verbindet sich ohne den CH340C mit dem WLan, 
egal an welcher Energiequelle.

Wieder kann ich damit den Code ausschließen, denn wenn der Code auf die 
Serielle Verbindung wartet, dann müsste der ESP32 ja ohne den CH340C 
erst recht nichts tun. aber tatsächlich tut er etwas.

Leider finde ich im Internet keine Beispiele wie de CH340C angebunden 
sein muss. Ich habe nur raus gefunden das der V3 Anschluss mit einem 
Kondensator an GND verbunden sein muss, wenn die Versorgungsspannung 5V 
ist. <-- So ist das bei mir.

Folgende Pins sind gar nicht verbunden: RS232, CTS, DSR, RI, DCD

Habt ihr da Erfahrung mit dem CH340C?

Ich habe nun ein Beispiel gefunden:

https://pcbartists.com/wp-content/uploads/2020/12/esp32-ch340-programmer-schematic-for-espressif-esp32-esp8266.png

Ich habe meine Schaltung praktisch identisch dazu aufgebaut... Bis auf 
die Transistoren. Das Beispiel verwendet BC-817. Ich verwende BC-818-40

Könnte das ein Problem sein?

Hallo,

da der Code von mir ist, glaube ich ihn zu kennen.

Ich habe aber dennoch mal einen simplen Test Code ohne jeglichen 
Serielle Kommunikation drauf geladen:

1

#include "WiFi.h"

2

3

const char* ssid = "<<ssid>>";

4

const char* password =  "<<pwd>>";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  WiFi.begin(ssid, password);

11

12

  while (WiFi.status() != WL_CONNECTED) {

13

    delay(500);

14

  }

15

16

  pinMode(LED_PIN, OUTPUT);

17

18

}

19

20

void loop() {

21

22

  for(int i=0;i<5;i++){

23

    digitalWrite(LED_PIN, HIGH);

24

    delay(200);

25

    digitalWrite(LED_PIN, LOW);

26

    if(i < 4){

27

      delay(200);

28

    }

29

  }

30

31

  delay(3000);

32

}

Das Resultat:

 * Mit Seriellem Monitor: WLan wird aufgebaut und ich finde den ESP32 in 
meiner FritzBox --> Board blinkt

 * Ohne Seriellen Monitor: WLan wird NICHT aufgebaut und ich finde den 
ESP32 NICHT in meiner FritzBox --> Board blinkt NICHT. Das wird hängt 
hier wohl in der Dauerschlaufe im Versuch sich zu verbinden fest.

Manuel S. schrieb:
> Ohne Seriellen Monitor: WLan wird NICHT aufgebaut und ich finde den
> ESP32 NICHT in meiner FritzBox --> Board blinkt NICHT. Das wird hängt
> hier wohl in der Dauerschlaufe im Versuch sich zu verbinden fest.

ja mit Monitor kommen andere Wartezeiten rein, Problem ist alt bekannt

dein connect scheint falsch zu sein, versuchs mal mit längeren Zeiten 
und mache die LED Init output nach setup nicht nach connect

ich müsste jetzt erst mal suchen ich glaube mit 750 delay klappts besser

mein letzter

  while (WiFi.status() != WL_CONNECTED)
    delay(2000);

denn dein wait 500 ist zu kurz

1

#include "WiFi.h"

2

const char* ssid = "<<ssid>>";

3

const char* password =  "<<pwd>>";

4

#define LED_PIN 2

5

6

void setup() {

7

  pinMode(LED_PIN, OUTPUT);

8

  WiFi.begin(ssid, password);

9

  while (WiFi.status() != WL_CONNECTED)

10

    delay(2000);

11

}

12

13

void loop() {

14

  for(int i=0;i<5;i++){

15

    digitalWrite(LED_PIN, HIGH);

16

    delay(200);

17

    digitalWrite(LED_PIN, LOW);

18

    if(i < 4)

19

      delay(200);

20

  }

21

  delay(3000);

22

}

Hallo,

das war es leider nicht. Ich habe den Testcode mal so umgebaut:

1

#include "WiFi.h"

2

3

const char* ssid = "";

4

const char* password =  "";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  WiFi.begin(ssid, password);

11

  while (WiFi.status() != WL_CONNECTED) {

12

    delay(2000);

13

  }

14

}

15

16

void loop() {

17

  pinMode(LED_PIN, OUTPUT);

18

19

  for(int i=0;i<5;i++){

20

    digitalWrite(LED_PIN, HIGH);

21

    delay(200);

22

    digitalWrite(LED_PIN, LOW);

23

    if(i < 4){

24

      delay(200);

25

    }

26

  }

27

28

  delay(3000);

29

}

Manuel S. schrieb:
> Ich habe den Testcode mal so umgebaut:
Manuel S. schrieb:
> pinMode(LED_PIN, OUTPUT);

warum im loop?
das ergibt doch keinen Sinn!

Programmieren ist nicht malen nach Zahlen oder C&P


Wenn der Pin out sein soll gehört das in setup

abgesehen davon, wenn er nicht connected muss er auch nicht in den loop!
Dann ist was faul und es sollte eine Meldung (stör LED ohne 
Serial.print) oder ein Reset kommen!

Wenn er aber noch aus dem vorigen Versuch verbunden war klappt 
neuerliches verbinden auch nicht dann fehlt der disconnect

1

  // Set WiFi to station mode and disconnect from an AP if it was previously connected

2

  WiFi.mode(WIFI_STA);

3

  WiFi.disconnect();

4

  delay(100);

Hallo

du scheinst ein Problem behandeln zu wollen das keines ist.

Damit du beruhigt bist habe ich mal den Code, so umgebaut:

1

#include "WiFi.h"

2

3

const char* ssid = "";

4

const char* password =  "";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  pinMode(LED_PIN, OUTPUT);

11

12

  WiFi.begin(ssid, password);

13

  while (WiFi.status() != WL_CONNECTED) {

14

    delay(2000);

15

  }

16

}

17

18

void loop() {

19

20

  for(int i=0;i<5;i++){

21

    digitalWrite(LED_PIN, HIGH);

22

    delay(200);

23

    digitalWrite(LED_PIN, LOW);

24

    if(i < 4){

25

      delay(200);

26

    }

27

  }

28

29

  delay(3000);

30

}

Übrigens: Das der "pinMode(LED_PIN, OUTPUT);" im loop war, ist 
selbstverständlich Unsinn und wahr schon behoben bevor der unnötige 
"Mahlen nach Zahlen" Kommentar abgesetzt wurde.

Tu mir doch nun schnell den Gefallen und sage mir was aus deiner Sicht 
an diesem Code falsch sein soll und warum deswegen der Code sich nur mit 
einem Seriellen Monitor aber nicht ohne verbindet.


P.S.: Ich empfinde es als ein respektloses Miteinander, wenn "Mahlen 
nach Zahlen" Kommentar abgesetzt werden. Diese helfen niemanden, und 
wenn du das für dein Ego brauchst mache das doch bitte nicht in Foren in 
denen man eigentlich ein höfliches miteinander einhält.

Manuel S. schrieb:
> Übrigens: Das der "pinMode(LED_PIN, OUTPUT);" im loop war, ist
> selbstverständlich Unsinn und wahr schon behoben

nicht als ich den lesen konnte, ich lüge ja nicht!

Manuel S. schrieb:
> das war es leider nicht. Ich habe den Testcode mal so umgebaut:#include
> void setup() {
>   WiFi.begin(ssid, password);
>   while (WiFi.status() != WL_CONNECTED) {
>     delay(2000);
>   }
> }
>
> void loop() {
>   pinMode(LED_PIN, OUTPUT);

so steht das hier!

Manuel S. schrieb:
> höfliches miteinander

ist wenn man nicht belogen wird, von wegen umgebauter Code

Manuel S. schrieb:
> Tu mir doch nun schnell den Gefallen und sage mir was aus deiner Sicht
> an diesem Code falsch sein soll

tat ich bereits!

Joachim B. schrieb:
> Wenn er aber noch aus dem vorigen Versuch verbunden war klappt
> neuerliches verbinden auch nicht dann fehlt der disconnect
>   // Set WiFi to station mode and disconnect from an AP if it was
> previously connected
>   WiFi.mode(WIFI_STA);
>   WiFi.disconnect();
>   delay(100);

> tat ich bereits!

Sorry aber ich kann dir nicht folgen. Ich habe den Code nach deinen 
Vorgaben unbebaut (siehe letzter Post von mir). Er tut aber dennoch 
nicht ohne Seriellen Monitor.

Folgendes habe ich zuerst noch raus gelassen, weil ich den ESP immer von 
der Stromversorgung trenne. Er kann also nicht vorher schon verbunden 
gewesen sein.

>   // Set WiFi to station mode and disconnect from an AP if it was
> previously connected
>   WiFi.mode(WIFI_STA);
>   WiFi.disconnect();
>   delay(100);

ABER.... der Vollständigkeit halber, habe den Code folgendermaßen 
umgebaut:

1

#include "WiFi.h"

2

3

const char* ssid = "";

4

const char* password =  "";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  pinMode(LED_PIN, OUTPUT);

11

12

  WiFi.mode(WIFI_STA);

13

  if(WiFi.status() == WL_CONNECTED){

14

    WiFi.disconnect();

15

    delay(100);

16

  }

17

18

  WiFi.begin(ssid, password);

19

  while (WiFi.status() != WL_CONNECTED) {

20

    delay(2000);

21

  }

22

}

23

24

void loop() {

25

26

  for(int i=0;i<5;i++){

27

    digitalWrite(LED_PIN, HIGH);

28

    delay(200);

29

    digitalWrite(LED_PIN, LOW);

30

    if(i < 4){

31

      delay(200);

32

    }

33

  }

34

35

  delay(3000);

36

}

.... und: Naja.... geht immer noch nicht.

Könntest du mir den Gefallen tun und den Code so umbauen, wie du sagst 
so muss es gehen und damit sind alle Probleme gelöst und den dann 
einfach mal vollständig hier posten? Ich denke da würde ab schnellsten 
gehen um diese Diskussion zu einem vernünftigen ende zu führen.

Johannes S. schrieb:
> den pinMode mehrfach zu setzen oder auch zu ändern ist erlaubt, der
> Aufruf alle paar Sekunden muss nicht sein, ist aber auch kein Fehler.
>
> TL;DR,
> Wie ist der Pegel am Reset Pin mit/ohne serial Monitor? Sind die
> Verbindungen zwischen CH340 und WROOM32 sauber, also keine Kurzschlüsse
> zu anderen ESP Pins die dann evtl. das booten behindern?

Habe jetzt nochmal alle Pins am CH340C durchgemessen: Keine 
Kurzschlüsse.

Da aber der Code (reproduzierbar) an jeder Anschlussart (mit und Ohne 
Seriellem Monitor) läuft wenn der CH340C raus gelötet ist, muss der 
Fehler immer noch da irgendwo liegen.

Mitleerweile habe ich auch diesen "Datenblatt" aufgetan:
https://www.mpja.com/download/35227cpdata.pdf

Auch die Beschreibung dort deutet drauf hin das meine Schaltung richtig 
ist.

Kann es den sein das der CH340C Störsignale aussendet, wenn er nicht 
verbunden ist und daher der ESP32 nicht ins WLan kommt?

Wenn ja: Was bedeutet das konkret für eine mögliche Fehlerbehebung?

> TL;DR,
> Wie ist der Pegel am Reset Pin mit/ohne serial Monitor? Sind die
> Verbindungen zwischen CH340 und WROOM32 sauber, also keine Kurzschlüsse
> zu anderen ESP Pins die dann evtl. das booten behindern?

Das habe ich jetzt auch noch gemessen.... und siehe da:

Mit Seriellem Monitor 3.3V --> Top!

Aber OHNE sind es 4,7V !!! Wie kann sowas kommen?
Ich finde hier keinen Fehler in meiner Schaltung. Der EN Pin mit einem 
10k Pullup an 3.3V (Ausgang des AMS 1117) angeschlossen.

Ich habe die Schaltung nochmal angefügt.

Manuel S. schrieb:
> Folgendes habe ich zuerst noch raus gelassen, weil ich den ESP immer von
> der Stromversorgung trenne. Er kann also nicht vorher schon verbunden
> gewesen sein.

da irrst du leider!

für den ESP stimmt das JA!

aber wo er sich anmeldet, bei mir Fritzbox ist er lange nicht getrennt!

Damit auch dein wlan router weiss das der getrennt ist braucht es 
manchmal (oder immer?) ein disconnect!

Manuel S. schrieb:
> Könntest du mir den Gefallen tun

siehst du es geht auch höflich!

Manuel S. schrieb:
> und den Code so umbauen

leider kenne ich deinen wlan router nicht und seine Besonderheiten!

Das müsstest du schon selber rausfinden

optimal
if connect -> disconnect
kleines delay
while not connected ......

usw.

Stefan ⛄ F. schrieb:
> Manuel S. schrieb:
>> Wie kann sowas kommen?
>
> Der Enable Pin ist doch mit dem 12kΩ Widerstand direkt neben der Antenne
> verbunden, oder irre ich mich da?

Der ist mittlerweile umgezogen. Ich habe die neue PCB mal angehängt.
Der Pull-Up ist gelb markiert.

Ist deine Vermutung, dass a irgendwas abstrahlt/induziert?
Das müsste ja dann auch vom CH340C kommen, wenn er nicht verbunden ist 
(ohne Serial Monitor)

Stefan ⛄ F. schrieb:
> Manuel S. schrieb:
>> Ist deine Vermutung, dass a irgendwas abstrahlt/induziert?
>
> Ja, Ich meinte dass es vielleicht nur so gerade eben mit Glück
> funktioniert

wenn wir keinem Troll aufgesessen sind,
warum müssen wir uns alles zusammen suchen?
warum ist Board und Schaltplan nicht in einem Post?
warum ist der Schaltplan so schlecht lesbar?
warum zu dünne Strippen zu klein eingestellt?

der CH340 hängt ja an 5V und ohne Init von dem wundert mich 5V Ruhepegel 
nicht, wo soll ein init herkommen ohne Serial. init open print?

Nun wirds verrückt!
Der Schaltplan sagt CH340C!

https://www.mpja.com/download/35227cpdata.pdf
Aber das Datenblatt weisst für den Typ
CH340C/E/B
Vcc min 3.0V
Vcc typ 3.3V
Vcc max 3.6V

aber er ist an +5V angeschlossen!

Johannes S. schrieb:
> Einstrahlungen können sicher auch Fehler verursachen, aber da würde ich
> eher sporadische Effekte vermuten und nicht so einen hartnäckigen Boot
> Fehler.

Das ist auch das was mich wundert. Aber ein Boot Fehler ist es aus meine 
Sicht nicht.
Der ESP durchläuft die setup(). Ich habe zum Test die Anzahl an Delays 
bei "WiFi.status() != WL_CONNECTED" auf 5 begrenzt und die LED auf Dauer 
HIGH gestellt, wenn nach den 5 mal warten (= 10 Sekunden) immer noch 
keine Verbindung da ist.
Die loop() wurde so umgebaut das Sie nur noch bei verbundenem WLan 
blinkt.

Ergebnis:
* Mit Serial Monitor: ESP32 blinkt
* Ohne Serial Monitor: ESP32 LED geht nach 10 Sekunden an und bleibt es 
auch.

> Die Spannungsregler gibt es mit verschiedenen Pin Belegungen, passt
> dieser wirklich zum Layout? Auch hier nachmessen ob die 3V3 richtig
> anliegen und die 4,7 V nicht noch irgendwo anders.

Den AMS1117 habe ich jetzt nochmal durchgemessen. Die Spannungen sind So 
wie sie sein sollen. Es ist ein AMS1117 3.3 und benötigt daher auch 
keine zusätzlichen Widerstände für die Regulierung. Auch die Spannung am 
ESP32 ist saubere 3.33V und am CH340C sind es 5V. Dass ist ok.

Die 4,7v am EN Pin scheinen das booten nicht zu verhindern aber 
zumindest die WLan Verbindung. Daher nochmal kurz meiner Frage von 
gestern:

Kann es sein das der verwendete BC-818-40 hier nicht der richtige ist, 
den ich für den Auto-Reset eingesetzt habe?

Hier auch nochmal mein neuer Testcode:

1

#include "WiFi.h"

2

3

const char* ssid = "";

4

const char* password =  "";

5

6

#define LED_PIN 2

7

8

void setup() {

9

10

  pinMode(LED_PIN, OUTPUT);

11

12

  WiFi.mode(WIFI_STA);

13

  if(WiFi.status() == WL_CONNECTED){

14

    WiFi.disconnect();

15

    delay(100);

16

  }

17

18

  WiFi.begin(ssid, password);

19

  for(int i = 0; (i<5) && (WiFi.status() != WL_CONNECTED) ;i++){

20

    delay(2000);

21

  }

22

23

  if(WiFi.status() != WL_CONNECTED){

24

    digitalWrite(LED_PIN, HIGH);

25

  }

26

}

27

28

void loop() {

29

30

  if(WiFi.status() == WL_CONNECTED){

31

    for(int i=0;i<5;i++){

32

      digitalWrite(LED_PIN, HIGH);

33

      delay(200);

34

      digitalWrite(LED_PIN, LOW);

35

      if(i < 4){

36

        delay(200);

37

      }

38

    }

39

  }

40

41

  delay(3000);

42

}

Joachim B. schrieb:

> der CH340 hängt ja an 5V und ohne Init von dem wundert mich 5V Ruhepegel
> nicht, wo soll ein init herkommen ohne Serial. init open print?

Wie kommst du darauf, dass der CH340C initialisiert werden muss? Klar 
hat der 5V das ist bei dem so vorgesehen. Auch hier bitte genauer lesen:
Die 4,7V lagen am EN Pin an. Dort ist das nicht gewünscht. Am CH340C 
völlig in Ordnung.

> Nun wirds verrückt!
> Der Schaltplan sagt CH340C!
>
> https://www.mpja.com/download/35227cpdata.pdf
> Aber das Datenblatt weisst für den Typ
> CH340C/E/B
> Vcc min 3.0V
> Vcc typ 3.3V
> Vcc max 3.6V
>
> aber er ist an +5V angeschlossen!

Bitte das Datenblatt genau lesen.... 3.0V bis 3.6v nur, wenn der v3 Pin 
mit VCC verbunden ist. Sonst sind es 4.0V bis 5.3V. Ich habe den Teil 
nochmal als Bild angehängt. Ist aber auch auf Seite 6 klar erkennbar.

Kann denn das WLan Problem überhaupt vom 4.7V Pegel am EN Pin ausgelöst 
werden?

Oder ist das nur eine Erscheinung der man nachgehen sollte, aber das 
eigentliche Problem nicht verursachen kann?

Johannes S. schrieb:
> Nur wenn der CH340 mit 5V versorgt wird, dann kommen an den
> Signalleitungen auch 5V - 0,5 V raus, das scheint dann über deine T an
> den EN zu gehen. Auch über die UART Leitung. Den ESP8266 konnte man
> afaik mit 5 V Pegeln zuverlässig killen.

Nicht zu fassen..... Das war es wohl!!!

Herzlichen Dank!!!!

Ich habe den CH340C jetzt mit 3.3v angeschlossen.
Der Versuch hat mich jetzt zwar einen CH340C gekostet aber jetzt 
verbindet er sich auch sauber ohne Serial Monitor

Zusammenfassung:

Der CH340C muss mit 3.3V betrieben werden, wenn das Logik-Level des 
Controllers auch 3.3v ist. (Wenn ich da lese, schäme ich mich fast das 
mir das nicht selbst aufgefallen ist)

Leider sind wohl einige Beispiele die man im Internet findet, wie man 
den CH340c mit dem ESP32 oder ESP8266 verbindet: total falsch:
https://pcbartists.com/wp-content/uploads/2020/12/esp32-ch340-programmer-schematic-for-espressif-esp32-esp8266.png


==> Danke an alle die hier durchgängig konstruktiv mitgeholfen haben!!! 
(aber auch nur an diese)
Ich war schon kurz davor aufzugeben!