Cannot connect to target. Error: 1 (ESF-157)

[versamodule]

Port

ESP

Target chip

ESP32-S3

Hardware Configuration

ESP32-S3-Devkitc-1 v1.0 to ESP32-S3-Devkitc-1 v1.0 via USB cable attached from one USB port to the other USB port.
Along with USB cable to PC from both units attached to UART port.

Log output

When I enable this the units connect and it uploads firmware every time. 
When I disable this i get Cannot connect to target. Error: 1

More Information

I am using an ESP32-S3 for both the Master and Slave(device to be programmed) via USB between both units.
The issue is I get "Cannot connect to target. Error: 1" in the terminal when I plug them together with the USB cable.
Pressing reset several times on both units I was able to get it to connect and update the slave unit just once.

In menuconfig under ESP serial flasher I have selected "USB (Experimental)" for the Hardware Interface.

On the Master terminal:
I (1510) usb_flasher: Installing USB Host
I (1540) usb_flasher: Installing the USB CDC-ACM driver
I (1540) usb_flasher: Opening CDC ACM device 0x303A:0x1001...
Cannot connect to target. Error: 1

On the slave Terminal:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x22 (DOWNLOAD(USB/UART0))
Saved PC:0x4037b326
waiting for download

Any ideas why it cannot connect to target ?

[Dzarda7]

Hello @versamodule, thank you for using this project. May I ask you what do you mean by:

When I enable this the units connect and it uploads firmware every time.

You mean "USB (Experimental)" option? With that enabled it works every time?
This option needs to be enabled for USB port.

If this does not work, try to use dupont wires to connect pin master's pin 19 and 20 to slave's pin 19 and 20 (image for reference), to be sure you can also try just the esp32_usb_cdc_acm_example.

[versamodule]

Thank you for responding so quickly!

You mean "USB (Experimental)" option? With that enabled it works every time?

No, When I am in menuconfig, there is an option for SERIAL_FLASHER_DEBUG_TRACE. When I enable that option it connects all the time. It's much slower of course cuz it prints everything out. When I disable it I get "Cannot connect to target. Error: 1" 99.9% of the time. With enabled it connects all the time and uploads the firmware.

The esp32_usb_cdc_acm_example is the one I am working with.
Other things to note. I am using ESP-IDF Release v5.3.1,

[Dzarda7]

Thanks, that's strange. Can you please test it with the dupont wires instead of the cable? Meanwhile I will try to test it by myself.

[versamodule]

Already did that and same behavior.
I found what makes it work 100% of the time.
In the esp32_usb_cdc_acm_example, in main I added "vTaskDelay(1000 / portTICK_PERIOD_MS); "

So it looks like this.

        device_disconnected_sem = xSemaphoreCreateBinary();
        assert(device_disconnected_sem);

        vTaskDelay(1000 / portTICK_PERIOD_MS);

        // If Connection Made Then Flash it
        if (connect_to_target(0) == ESP_LOADER_SUCCESS)

I don't have to even have SERIAL_FLASHER_DEBUG_TRACE enabled anymore.

I added tusb_msc example to my code project.

I give a short delay when it boots and flash the led to let the user know when to press the GPIO0 button.
If its pressed it turns into USB device so when I plug it into my PC it shows up as a hard drive. I then copy the
bootloader.bin, partition-table.bin, app.bin files to it. Then disconnect.

If not pressed within 3 seconds it goes to the esp32_usb_cdc_acm_example to flash the device.
I tweaked flash_binary(); So that I reads the stored files from internal flash, and flashes the device.

So, thank you for all your time, working flawless now.

[Dzarda7]

That is awesome project you have. Happy you found the solution. I will still keep this issue open for a while and try to investigate it a bit more. Least we can do is add the delay to the example. Thanks for finding this.

[DNedic]

Interesting, this looks like the target is not ready to receive data, and the USB CDC ACM driver returns something other than a timeout error. The reason it works with tracing is most probably because the tracing slows down the transfer enough for the target to be ready.

We will investigate this further and find a fix that doesn't require a manually added delay.