Wenn ein ESP32 (insbesondere in Kombination mit MicroPython) über die serielle Schnittstelle (typischerweise UART0, der auch an den USB-Konverter angeschlossen ist) Daten sendet, kann ein Neustart auftreten, wenn die Gegenstelle (z.B. ein PC-Terminal oder ein anderes Gerät) die serielle Verbindung neu aufbaut oder sich neu verbindet. Dies hängt oft mit dem Verhalten der Signalleitungen DTR/RTS zusammen, die vom USB-Seriell-Konverter gesteuert werden und auf dem ESP32-Board standardmäßig mit Reset-/Boot-Pins verbunden sind.

**Hintergrund:**
- Viele ESP32-Entwicklungsboards (z.B. DevKitC) verwenden eine USB-UART-Brücke (z.B. CP2102, CH340, FTDI), deren DTR- und RTS-Signale über ein Autoprogrammierungsschaltkreis an die Reset- (EN) und IO0-Pins des ESP32 angeschlossen sind.  
- Wird die serielle Verbindung vom Host neu gestartet, können sich diese Signale ändern und damit den ESP32 ungewollt in einen Reset oder Bootloader-Modus versetzen.  
- Wenn das Endgerät also "die Verbindung neu startet" (z.B. seriellen Port schließt und wieder öffnet), werden in vielen Terminalprogrammen standardmäßig DTR und RTS getoggelt. Dies resultiert in einem Reset des ESP32.

**Mögliche Lösungsansätze:**
1. **Terminal-Einstellungen anpassen:**  
   In vielen Terminal- oder seriellen Programmen (PuTTY, screen, miniterm, etc.) lassen sich DTR und RTS deaktivieren, so dass sie beim Öffnen/Schließen des Ports nicht geändert werden. Das verhindert den unbeabsichtigten Reset.

2. **Alternative UARTs verwenden:**  
   Statt UART0 (welcher oft an den USB-Seriell-Konverter gebunden ist) kann man einen anderen UART des ESP32 nutzen (UART1 oder UART2), dessen Pins nicht mit dem automatischen Reset-Schaltkreis verbunden sind. Dann kann ein Verbindungsabbruch auf dem Terminal keinen Reset auslösen, da DTR/RTS diese Pins nicht beeinflussen.

3. **Hardware-Modifikationen:**  
   - Einige Boards erlauben es, durch Entfernen von Jumpern oder Widerständen den automatischen Reset-Beschaltungsweg zu unterbrechen, sodass DTR/RTS nicht mehr auf EN/IO0 wirken.  
   - Man kann die Schaltung anpassen, sodass die Reset- und Boot-Pins nicht mehr von den DTR/RTS-Linien beeinflusst werden.

4. **Softwareseitige Behandlung (eingeschränkt):**  
   Rein softwareseitig ist es schwierig, das Problem zu umgehen, da der Reset durch eine externe Signalleitung ausgelöst wird. Allerdings kann man versuchen, den UART-Zugriff robuster zu gestalten, um Fehler beim "Verbindung-Verlust" abzufangen. Das allein verhindert jedoch den Hardware-Reset meist nicht.

**Fazit:**  
Der beschriebene Neustart ist häufig auf das standardmäßige Autoreset-Feature zurückzuführen, das durch den USB-UART-Chip und dessen Handshake-Leitungen (DTR/RTS) verursacht wird. Um das Problem zu lösen, muss man entweder auf die Nutzung dieser Leitungen verzichten, sie in der Terminal-Software deaktivieren, oder einen alternativen UART nutzen, der nicht an diese Reset-Mechanismen gekoppelt ist.