Logmeldungen nach Light-Sleep von ESP32 per USB-CDC erhalten

Ganz dumme Idee: wenn er aufwacht noch mal einen Reset machen?

Das meint Espressif in der Dokumentation zu Light-Sleep ESP32-H2 und USB:

1

Light-sleep

2

3

When entering Light-sleep, the APB and USB PHY clock are gated.

4

Thus, the USB Serial/JTAG controller is no longer able to

5

receive or respond to any USB transactions from the connected

6

host (including periodic CDC Data IN transactions).

7

8

As a result:

9

when entering Light-sleep, the USB Serial/JTAG device is 

10

unresponsive to the host/PC's USB CDC driver. 

11

The host/PC may then report the USB Serial/JTAG device as 

12

disconnected or erroneous (even if the USB cable is still 

13

physically connected).

14

15

when exiting Light-sleep, it is possible that the host/PC 

16

does not re-enumerate (i.e., reconnect) the USB Serial/JTAG 

17

device given that the USB PHY's D+ line remains pulled up state 

18

during Light-sleep. Users may need to physically disconnect 

19

and then reconnect the USB cable.

Jetzt könnte man auf die Idee kommen, den Pull-Up an D+ beim Einschlafen ab- und nach dem Wake-Up wieder anzuschalten, aber wenn das mehrfach in der Sekunde passiert, hat der PC da auch keinen Spaß dran.

Die Lösung von Espressif, wenn der sleep-Mode automatisch und nicht manuell gestartet wird: USB/JTAG verbunden => Kein Sleep.

Edit: Link https://docs.espressif.com/projects/esp-idf/en/stable/esp32h2/api-guides/usb-serial-jtag-console.html#light-sleep

Ich bin nicht ganz schlau aus den Infos geworden die ich sammeln konnte. Zum einen scheint es zwischen den Chips Unterschiede zu gebn, ein esp32-cX reagiert anders als ein esp32-hX oder esp32-sX, zum anderen spielt es wohl auch eine Rolle ob der Chip automatisch oder manuell in den sleep versetzt wurde?

Wenn der Chip in den Sleep geht bedient er einfach die USB PHY nicht mehr (vor allem wohl weil die Taktgeber angehalten werden?), der PC (Win11) erwartet aber regelmäßige Signale am USB sonst meldet er den Port ab. Es wird davon berichtet das man nach dem Wakeup den usb-cdc auf dem esp neu initialisieren soll und wenn die PC Software dasseble tut soll es angeblich funktionieren. Das habe ich nicht hinbekommen.

Was ich etwas befürchte ist das wenn mein Code weiterläuft und mit ESP_LOG*() Dinge ausgeben will, das das dann blockiert und meinen Codeablauf stört?

Da ich das nur für das Debugging brauche will ich nun mal ausprobieren ober das mit dem on-board UART auch so ist und einen FDTI oder CP2101/CH340 dran hängen.

Ich habe hier nun einen USB/UART Adapter (FTDI). Den kann ich nicht direkt an den ESP anschließen weil der ESP mit 3,3 V Logikpegel arbeitet und praktisch jeder UART-Chip mit 5 V TTL. Also habe ich noch einen Pegelwandler dazwischen geschaltet.

Verbunden habe ich das nun so:

1

FTDI      LVL-SHFT    ESP32-H2

2

-----     --------    --------

3

TXD          →        GPIO23 (U0RXD)

4

RXD          ←        GPIO24 (U0TXD)

5

GND          GND      GND

6

+5V          HV

7

             LV       +3.3V

In der sdkconfig habe ich dann noch folgendes eingestellt:

1

CONFIG_ESP_CONSOLE_UART=y

2

CONFIG_ESP_CONSOLE_UART_NUM=0

3

CONFIG_ESP_CONSOLE_ROM_SERIAL_PORT_NUM=0

4

CONFIG_ESP_CONSOLE_UART_BAUDRATE=115200

5

CONFIG_ESP_CONSOLE_UART_DEFAULT=y

Über die Console (idf_monitor.py -p COM12 -b 115200) bekomme ich auch wunderbar den Output.

Nur Flashen kann man über UART0 wohl nicht. Das geschieht weiter über USB-CDC. Dafür kann man in VS Code in der .vscode/settings.json aber getrennte Ports fürs Flashen und für den Monitor angeben, sodass man beides nutzen kann:

1

{

2

  ...

3

  "idf.portWin": "COM6",

4

  "idf.monitorPort": "COM12",

5

  ...

6

}

Olli Z. schrieb:

Den kann ich nicht direkt an den ESP anschließen weil ... praktisch jeder UART-Chip mit 5 V arbeitet

Ich halte das für einen Irrtum.

http://www.stefanfrings.de/usb-uart/index.html

Die Vbus Spannung braucht es nicht, nur RX TX und GND verbinden sollte reichen, Vbus ggf. extern versorgen.