Does ESP32-S2 DFU support automatic detach / reset?

[cibomahto]

I'm bringing up a new board with an ESP32-S2F4. I'm able to program the board successfully with DFU if I manually enter the bootloader by holding GPIO0 low during reset, however:

1. After DFU programming, the part seems to stick in bootloader mode, and doesn't run the newly flashed application firmware. Manually resetting the board starts the firmware as expected. Is automatic reset supposed to work?

Code: Select all

matt@huginn:~/Blinkinlabs-Repos/iced_espresso/examples/CM-2$ idf.py dfu-flash
Executing action: dfu-flash
Running make in directory /home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/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
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [=========================] 100%       860160 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Built target dfu-flash
Done

Manually invoking dfu-util with the -R flag doesn't work either:

Code: Select all

matt@huginn:~/Blinkinlabs-Repos/iced_espresso/examples/CM-2$ dfu-util -d 303a:2 -R -D /home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/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 Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [=========================] 100%       860160 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
dfu-util: can't detach
Resetting USB to switch back to runtime mode

2. If I configure the application firmware to use ESP_CONSOLE_USB_CDC, dfu-util is able to see the DFU runtime descriptor, however it fails to automatically get it into rom bootloader mode. Is the DFU runtime supposed to be able to transition automatically to full bootloader mode?

Code: Select all

idf.py dfu-flash
Executing action: dfu-flash
Running make in directory /home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/Blinkinlabs-Repos/iced_espresso/examples/CM-2/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...
dfu-util: error detaching
Device will detach and reattach...
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:2419: CMakeFiles/dfu-flash.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:2426: CMakeFiles/dfu-flash.dir/rule] Error 2
make: *** [Makefile:359: 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

I'm testing this on an x86 laptop running Ubuntu, and get the same behavior with ESP-IDF versions v4.3 and master, using the 'hello world' example. edit: using the 'wifi/getting_started/station' example, 'hello world' works after retesting.

The USB traces on my board are routed as a 90 ohm differential pair, however I don't have filter caps or resistors on them.

[ESP_Sprite]

The S2 staying in download mode when started with GPIO0 pulled down is to be expected; there's no way to get it to start up in 'normal' mode when it's booted in download mode (something with security issues, iirc). The device disappearing after detach certainly is not. When dfu-utils crashes out like that and you try to start it a second time, does it work then? Also, when you try to do the flash as root, does that work? It might be a permissions issue.

[cibomahto]

The S2 staying in download mode when started with GPIO0 pulled down is to be expected; there's no way to get it to start up in 'normal' mode when it's booted in download mode (something with security issues, iirc).

Thanks! It might be helpful for the documentation to mention this, since it's different than how most DFU devices work.

I do see the explicit 'reset' step mentioned in the tutorial video

As a follow on to this question, is it expected that the device will need to be reset after DFU programming initiated while the device is running application firmware w/the USB_CDC console option?

The device disappearing after detach certainly is not. When dfu-utils crashes out like that and you try to start it a second time, does it work then?

Repeating attempts give the same result.

Also, when you try to do the flash as root, does that work? It might be a permissions issue.

It seems to work the same as both an unprivileged user and as root.

I think I've narrowed it down to enabling WiFi (which my application is using):

I tried the 'hello world' example again on my board, and after doing a reset after the initial DFU programming, I can reprogram the board using 'idf.py flash' and 'idf.py dfu-flash':

Code: Select all

root@huginn:/home/matt/esp/esp-idf-master/examples/get-started/hello_world# idf.py dfu-flash
Executing action: dfu-flash
Running make in directory /home/matt/esp/esp-idf-master/examples/get-started/hello_world/build
Executing "make -j 6 dfu-flash"...
Command list: dfu-util;-d;303a:2;-D;/home/matt/esp/esp-idf-master/examples/get-started/hello_world/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...
dfu-util: error detaching
Device will detach and reattach...
Opening DFU USB Device...
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 64
Copying data from PC to DFU device
Download        [=========================] 100%       174080 bytes
Download done.
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Built target dfu-flash
Done

looking at the kernel log, the USB device enumerated once when plugged in, then a second time when DFU was initiated:

Code: Select all

Aug 10 17:39:11 huginn kernel: [1136207.561438] usb 1-2: new full-speed USB device number 124 using xhci_hcd
Aug 10 17:39:11 huginn kernel: [1136207.710807] usb 1-2: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 10 17:39:11 huginn kernel: [1136207.710812] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 10 17:39:11 huginn kernel: [1136207.710816] usb 1-2: Product: ESP32-S2
Aug 10 17:39:11 huginn kernel: [1136207.710819] usb 1-2: Manufacturer: Espressif
Aug 10 17:39:11 huginn kernel: [1136207.710822] usb 1-2: SerialNumber: 7c:df:a1:01:31:02
Aug 10 17:39:11 huginn kernel: [1136207.712612] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Aug 10 17:39:15 huginn kernel: [1136211.626478] usb 1-2: USB disconnect, device number 124
Aug 10 17:39:15 huginn kernel: [1136211.933460] usb 1-2: new full-speed USB device number 125 using xhci_hcd
Aug 10 17:39:15 huginn kernel: [1136212.083508] usb 1-2: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 10 17:39:15 huginn kernel: [1136212.083515] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 10 17:39:15 huginn kernel: [1136212.083518] usb 1-2: Product: ESP32-S2
Aug 10 17:39:15 huginn kernel: [1136212.083521] usb 1-2: Manufacturer: Espressif
Aug 10 17:39:15 huginn kernel: [1136212.083524] usb 1-2: SerialNumber: 0
Aug 10 17:39:15 huginn kernel: [1136212.085615] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

If I instead load the 'wifi/getting_started/station' example, the USB appears to enumerate correctly at startup, but both 'idf.py dfu-load' and 'idf.py load' fail:

Code: Select all

root@huginn:/home/matt/esp/esp-idf-master/examples/wifi/getting_started/station# idf.py dfu-flash
Executing action: dfu-flash
Running make in directory /home/matt/esp/esp-idf-master/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-master/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-master/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:2081: CMakeFiles/dfu-flash.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:2088: 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

And the kernel log shows errors trying to talk to the re-enumerated USB device:

Code: Select all

Aug 10 17:43:13 huginn kernel: [1136449.940857] usb 1-2: new full-speed USB device number 10 using xhci_hcd
Aug 10 17:43:13 huginn kernel: [1136450.090824] usb 1-2: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 10 17:43:13 huginn kernel: [1136450.090830] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 10 17:43:13 huginn kernel: [1136450.090833] usb 1-2: Product: ESP32-S2
Aug 10 17:43:13 huginn kernel: [1136450.090837] usb 1-2: Manufacturer: Espressif
Aug 10 17:43:13 huginn kernel: [1136450.090839] usb 1-2: SerialNumber: 7c:df:a1:01:31:02
Aug 10 17:43:13 huginn kernel: [1136450.092684] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
Aug 10 17:43:18 huginn kernel: [1136455.036462] usb 1-2: USB disconnect, device number 10
Aug 10 17:43:18 huginn kernel: [1136455.344858] usb 1-2: new full-speed USB device number 11 using xhci_hcd
Aug 10 17:43:27 huginn kernel: [1136463.908764] usb 1-2: device descriptor read/64, error -71
Aug 10 17:43:27 huginn kernel: [1136464.144817] usb 1-2: device descriptor read/64, error -71
Aug 10 17:43:28 huginn kernel: [1136464.380729] usb 1-2: new full-speed USB device number 12 using xhci_hcd
Aug 10 17:43:28 huginn kernel: [1136464.530445] usb 1-2: New USB device found, idVendor=303a, idProduct=0002, bcdDevice= 7.23
Aug 10 17:43:28 huginn kernel: [1136464.530451] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 10 17:43:28 huginn kernel: [1136464.530455] usb 1-2: Product: ESP32-S2
Aug 10 17:43:28 huginn kernel: [1136464.530458] usb 1-2: Manufacturer: Espressif
Aug 10 17:43:28 huginn kernel: [1136464.530461] usb 1-2: SerialNumber: 7c:df:a1:01:31:02
Aug 10 17:43:28 huginn kernel: [1136464.532406] cdc_acm 1-2:1.0: ttyACM0: USB ACM device

I'm able to repeat the above steps using an ESP32-S2-Saola-1 dev board (wired in the same way as the example video). I'd be happy to post this as a bug report now, it seems clear that it should be working

[cibomahto]

Posted a bug report here: https://github.com/espressif/esp-idf/issues/7404 , it's possibly the same issue that was reported here: https://github.com/espressif/esp-idf/issues/6969

[rogerturcotte]

It is to be expected that restarting the S2 with GPIO0 pulled down will keep it in download mode, as there is no known mechanism to force the device out of download mode and into 'regular' mode (perhaps due to security concerns). The disappearance of the gadget after disconnect is most definitely not. Does it work if you try to restart dfu-utils after it has crashed in this way? Does it work if you try to run the flash as root? It could be due to a difficulty with access.