ESP32S2: When WiFi is enabled, USB endpoints stop working (IDFGH-5683)

[cibomahto]

Environment

• Development Kit: ESP32-S2-Saola
• Kit version (for WroverKit/PicoKit/DevKitC): v1.2
• Module or chip used: ESP32-S2-WROVER
• IDF version (run git describe --tags to find it): v4.3 (
• Build System: idf.py
• Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
• Operating System: Linux
• Using an IDE?: No
• Power Supply: USB

Problem Description

Enabling WiFi on an ESP32-S2 causes the USB peripheral to stop working correctly. When a user firmware is loaded that enables WiFi, the idf.py 'dfu-flash', 'flash', and 'monitor' commands no longer function. Loading a firmware that does not enable WiFi allows all of the above commands to work correctly.

I'm able to repeat this with both ESP-IDF V4.3 and master (83956eb), on both the Saola board and a custom board I'm developing.

There is a related issue here that might be the same as this one, however the scope is larger than noted there: #6969

Expected Behavior

Running 'idf.py monitor' should show the debug console; running 'idf.py dfu-flash' should flash firmware into the device and restart it.

Actual Behavior

The device fails to program:

idf.py dfu-flash
Executing action: dfu-flash
Running make in directory /home/matt/esp/esp-idf-v4.3/examples/wifi/getting_started/station/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/esp/esp-idf-v4.3/examples/wifi/getting_started/station/build/dfu.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 303a:0002
Run-time device DFU version 0110
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Device will detach and reattach...
dfu-util: error detaching
dfu-util: Lost device after RESET?
CMake Error at /home/matt/esp/esp-idf-v4.3/tools/cmake/run_dfu_util.cmake:27 (message):
  dfu-util failed


make[3]: *** [CMakeFiles/dfu-flash.dir/build.make:57: CMakeFiles/dfu-flash] Error 1
make[2]: *** [CMakeFiles/Makefile2:1975: CMakeFiles/dfu-flash.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:1982: CMakeFiles/dfu-flash.dir/rule] Error 2
make: *** [Makefile:177: dfu-flash] Error 2
Please have a look at the "Device Firmware Upgrade through USB" chapter in API Guides of the ESP-IDF documentation for solving common dfu-util issues.
make failed with exit code 2

Dmesg reports this when the device is reset after a successful program:

Aug 11 00:24:07 huginn kernel: [1160504.078677] usb 1-1: USB disconnect, device number 58
Aug 11 00:24:12 huginn kernel: [1160508.453259] usb 1-1: new full-speed USB device number 59 using xhci_hcd
Aug 11 00:24:12 huginn kernel: [1160508.602737] usb 1-1: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 11 00:24:12 huginn kernel: [1160508.602742] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 11 00:24:12 huginn kernel: [1160508.602746] usb 1-1: Product: ESP32-S2
Aug 11 00:24:12 huginn kernel: [1160508.602748] usb 1-1: Manufacturer: Espressif
Aug 11 00:24:12 huginn kernel: [1160508.602751] usb 1-1: SerialNumber: 7c:df:a1:01:31:02
Aug 11 00:24:12 huginn kernel: [1160508.604443] cdc_acm 1-1:1.0: ttyACM0: USB ACM device

When starting the unsuccessful dfu-flash, the USB device starts by disconnecting and reconnecting correctly:

Aug 11 00:24:19 huginn kernel: [1160515.496143] usb 1-1: USB disconnect, device number 59
Aug 11 00:24:19 huginn kernel: [1160515.805216] usb 1-1: new full-speed USB device number 60 using xhci_hcd

But then hangs for a while (during which dfu-flash errors out). Eventually the USB operations fail:

Aug 11 00:24:28 huginn kernel: [1160524.401207] usb 1-1: device descriptor read/64, error -71
Aug 11 00:24:28 huginn kernel: [1160524.641115] usb 1-1: device descriptor read/64, error -71
Aug 11 00:24:28 huginn kernel: [1160524.877107] usb 1-1: new full-speed USB device number 61 using xhci_hcd
Aug 11 00:24:28 huginn kernel: [1160525.026574] usb 1-1: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 11 00:24:28 huginn kernel: [1160525.026580] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 11 00:24:28 huginn kernel: [1160525.026583] usb 1-1: Product: ESP32-S2
Aug 11 00:24:28 huginn kernel: [1160525.026586] usb 1-1: Manufacturer: Espressif
Aug 11 00:24:28 huginn kernel: [1160525.026589] usb 1-1: SerialNumber: 7c:df:a1:01:31:02
Aug 11 00:24:28 huginn kernel: [1160525.028351] cdc_acm 1-1:1.0: ttyACM0: USB ACM device

Steps to reproduce

Using the 'wifi/getting_started/station' example, I configure it by:

1. rm -rf build/ && rm sdkcconfig
2. idf.py set-target esp32s2
3. idf.py menuconfig (then close without saving to fill in default options)
4. idf.py menuconfig, then set USB_CDC in Component config->Common ESP-related->Channel for console output
5. idf.py dfu

// If possible, attach a picture of your setup/wiring here.

Wiring is identical to the description in: https://blog.espressif.com/dfu-using-the-native-usb-on-esp32-s2-for-flashing-the-firmware-b2c4af3335f1

Code to reproduce this issue

This example causes the usb to fail: https://github.com/espressif/esp-idf/tree/master/examples/wifi/getting_started/station

Using a different example (that doesn't initialize wifi), works correctly: https://github.com/espressif/esp-idf/tree/master/examples/get-started/hello_world

Debug Logs

(included above)

Other items if possible

dfu.bin.zip
sdkconfig.zip

[4ssHole]

Experiencing the same issue on a ESP32-S2-WROVER module on Windows 10 19042.870 Asus Sabertooth Z77, ESP-IDF 4.3.1

I added a 5 second delay before starting Wi-Fi on boot, this at least allows me to flash without holding the boot button, though I need to press flash 2-3 times in VSCode

[chegewara]

@cibomahto That included dfu.bin.zip file is odd. There is only 1 bin file inside, but should be few more files:

You should have all but ota_data_initial.bin, which is only when using partition scheme with OTA.

[cibomahto]

@chegewara Here's a new version. dfu.zip. Please note that this is a zip file containing dfu.bin. dfu.bin appears to be a CPIO archive that contains the files you mentioned above.

Edit: The original zip file seems fine, it is also just a .zip file that contains dfu.bin. dfu.bin, again, is then a cpio archive that contains all 4 files.

[Dazza0]

This might be the same issue as #8241, could you check if f82ab4c on master or bf523af on release/v4.4 resolves this issue?

[cibomahto]

@Dazza0 Thanks, I just tried it with the release/v4.4 branch. It looks like this isn't implemented for ESP32-S2.

I get a compilation error when I enable ESP_PHY_ENABLE_USB:

/home/matt/esp/esp-idf-v4.4-tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: esp-idf/esp_phy/libesp_phy.a(phy_init.c.obj):(.literal.esp_phy_load_cal_and_init+0x18): undefined reference to `phy_bbpll_en_usb'
/home/matt/esp/esp-idf-v4.4-tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: esp-idf/esp_phy/libesp_phy.a(phy_init.c.obj): in function `esp_phy_load_cal_and_init':

/home/matt/esp/esp-idf-v4.4/components/esp_phy/src/phy_init.c:649: undefined reference to `phy_bbpll_en_usb'

and the phy lib for esp32s2 doesn't seem to have the referenced symbol:

fgrep phy_bbpll_en_usb -r *
Binary file components/esp_phy/lib/esp32s3/libphy.a matches
Binary file components/esp_phy/lib/esp32c3/libphy.a matches
components/esp_phy/include/phy.h:void phy_bbpll_en_usb(bool en);
components/esp_phy/src/phy_init.c:    phy_bbpll_en_usb(true);

[chipweinberger]

I'm also hitting undefined reference to 'phy_bbpll_en_usb', with v4.4, though I'm using ESP32-S3

Is there a solution? I'm not sure what I enabled that is even causing this.

Edit: oddly I see /myApp/firmware/.espressif/tools/xtensa-esp32s2-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: which references S2 even though I have VSC set to S3. Not sure what is causing S2 compiler to be used?

Edit2: fixed it by updating Espressif VSC extension from 1.3.0 to 1.4.0, full clean, set-target using VSC UI, then rebuild.

[dchichkov]

@igrr I also get a compilation error when I enable ESP_PHY_ENABLE_USB. It seems that the S2 version of libraries don't have the right symbol, while S3 versions do.

Please, can this be fixed? It is very difficult to debug on S2 boards, as it is not possible to reset them via the USB when WiFi is active. And WiFi is the core functionality for ESP32. What is even more frustrating, the reset used to work in the first pre-release of ESP IDF for S2...

[igrr]

Hi @dchichkov,
This issue on S2 is not related to phy_bbpll_en_usb (or ESP_PHY_ENABLE_USB).

The issue which @Dazza0 has mentioned was specific to S3. It was related to the fact that when Wi-Fi got enabled, the Wi-Fi driver would reconfigure the PLL (which is shared between Wi-Fi part and USB) in a way which stopped USB from working.

This bug has a different cause. The issue occurs when reset (signaled by the host via DTR and RTS) is detected. USB console driver calls esp_restart function to reset the chip. However the issue is that when Wi-Fi is enabled, it registers a "shutdown handler" function which should be called before reset. This shutdown handler (esp_wifi_stop) can't be called from an ISR. However the USB console driver tries to call esp_restart from an ISR. This results in a crash (esp_wifi_stop called from an ISR, but it shouldn't be.)

We have a fix now, but unfortunately it's not quite straightforward, and requires several supporting changes to be merged first. I'm sorry it's taking so unacceptably long!

In the meantime you can probably work around the issue by replacing this line:

esp-idf/components/esp_system/port/soc/esp32s2/usb_console.c

Line 153 in 01d014c

esp_restart();

with

    esp_usb_console_before_restart();
    esp_restart_noos();

(the latter call requires an #include "esp_private/system_internal.h")
This is not a perfect solution, since the call to esp_wifi_stop() is skipped, which as far as I understand may result in a failure to connect to the access point after restart, for certain access points. The better fix is in progress, we will update this issue once the fix is merged.

[dchichkov]

@igrr Wow. Thank you very much. Reset over USB is now working even after WiFi is up.

For some reason ifd.py flash monitor still doesn't work for me, but I have another workaround: using ESPTOOLPY_AFTER_NORESET and then doing a reset via DFU: idf.py flash --port=/dev/ttyACM0 ; coproc bash -c "sleep 2; dfu-tool detach; sleep 1; dfu-tool attach" ; sleep 1; idf.py monitor --port=/dev/ttyACM0 load.

[stk84]

Hi!

Is this issue solved? Because i am having the same, or maybe a related issue:

Environment

• Development Kit: custom board
• Module or chip used: ESP32-WROOM-S2
• IDF version (run git describe --tags to find it):
  v4.4.1 - commit 1329b19
  from Sat Apr 16 09:43:14 2022 +0800
• Build System: idf.py
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 5.2.0
• Operating System: macOS
• Using an IDE?: VSCode
• Power Supply: USB C

Problem Description

When configuring the console output to USB CDC, my application crashes periodically. That is if the USB is connected to the Computer. With Power only it seems to work fine.

Additionally i can not open the monitor on the USB CDC Serial Port: ('OSError: [Errno 6] Device not configured')

When testing the ESP IDF Examples i can reproduce the Logging error e.g. by building and flashing the '/examples/wifi/getting_started/softAP' (with USB CDC).
Other examples, like '/examples/get-started/hello_world' behave normal, even when USB CDC is configured. Monitor can be used here normally.

[igrr]

@stk84 the issue isn't solved yet, but please try the workaround explained in #7404 (comment) and see if it helps in your case?

[stk84]

@igrr Thanks for the quick response.

The workaround unfortunately only helps for the ESP IDF examples in my case.

With my application, i still have the same issues.

I would rule out the custom board, since all other examples work fine.
Also my code works fine when it is flashed with Logging over UART0

Do you have any hints where i could check? Because i am currently stepping in the dark.

[igrr]

@stk84 Unfortunately I don't have other suggestions based on the information you have provided.

When configuring the console output to USB CDC, my application crashes periodically.

I suggest opening a new issue about this, and trying to find out more information about how the application crashes. For example, you can connect JTAG debugger and try to see where exactly the application crashes.

[cibomahto]

Thank you!

[4ssHole]

When I enable "Enable USB when phy init"

I'm getting phy_init.c:701: undefined reference to `phy_bbpll_en_usb' with IDF v5.0.1 and 4.4.4 with ESP32 S2.

Tried reinstalling IDF and it still happens even with the wifi/getting_started/station example

can this issue be opened?

[chipweinberger]

You should reopen a new issue :)

Make sure to include your compilation logs, and do a full clean prior.