How to use with ftdi FT232-ttl adapter (esp32s3 board)? Able to monitor but not able to flash...

[cmorganBE]

esp323s3 here, I'm able to boot into bootrom mode via BOOT0 and reset and can confirm if I open the device up with picocom (at the bottom).

But when the chip is in this mode I'm not able to program, I get timeouts:

$ espflash flash build/firmware.elf -p /dev/ttyUSB0 -c esp32s3 -b no-reset-no-sync
[2024-06-07T19:18:10Z WARN ] Pre-connection option 'NoResetNoSync' was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
[2024-06-07T19:18:10Z INFO ] Serial port: '/dev/ttyUSB0'
[2024-06-07T19:18:10Z INFO ] Connecting...
Error: espflash::timeout

  × Error while connecting to device
  ╰─▶ Timeout while running ReadReg command

Am I missing something?

I'm able to monitor as well btw:

$ espflash monitor -p /dev/ttyUSB0 --chip esp32s3 -b no-reset-no-sync
[2024-06-07T19:21:23Z WARN ] Pre-connection option 'NoResetNoSync' was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
[2024-06-07T19:21:23Z INFO ] Serial port: '/dev/ttyUSB0'
[2024-06-07T19:21:23Z INFO ] Connecting...
Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x33 (DOWNLOAD(USB/UART0))
waiting for download

$ picocom -b 115200 /dev/ttyUSB0
picocom v3.1

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x33 (DOWNLOAD(USB/UART0))
waiting for download

[SergioGasquez]

A few things to try/questions:

• Have you tried without the -b no-reset-no-sync argument?
• Could you also try to use --no-stub?
• Which version of espflash are you using?
• Can you post the debug logs RUST_LOG=debug espflash ...

[cmorganBE]

Hi @SergioGasquez

I was using -b no-reset-no-sync already as I'm only connecting to RX/TX lines and manually putting it into bootrom codeload mode via BOOT0 and reset (and this system only has RX/TX lines available on the connector).

$ espflash --version
espflash 3.1.0

RUST_LOG=debug output, with --no-stub,

$ RUST_LOG=debug espflash flash build/firmware.elf -p /dev/ttyUSB0 -c esp32s3 -b no-reset-no-sync --no-stub
[2024-06-11T18:31:06Z DEBUG] Flash(
        FlashArgs {
            connect_args: ConnectArgs {
                after: HardReset,
                baud: None,
                before: NoResetNoSync,
                chip: Some(
                    Esp32s3,
                ),
                confirm_port: false,
                list_all_ports: false,
                no_stub: true,
                port: Some(
                    "/dev/ttyUSB0",
                ),
            },
            flash_config_args: FlashConfigArgs {
                flash_freq: None,
                flash_mode: None,
                flash_size: None,
            },
            flash_args: FlashArgs {
                erase_parts: None,
                erase_data_parts: None,
                log_format: Serial,
                monitor: false,
                monitor_baud: None,
                ram: false,
                no_verify: false,
                no_skip: false,
                image: ImageArgs {
                    bootloader: None,
                    partition_table: None,
                    partition_table_offset: None,
                    target_app_partition: None,
                    min_chip_rev: 0,
                },
            },
            image: "build/firmware.elf",
        },
    )
[2024-06-11T18:31:06Z DEBUG] connecting to crates.io:443 at 65.8.20.66:443
[2024-06-11T18:31:06Z DEBUG] No cached session for DnsName("crates.io")
[2024-06-11T18:31:06Z DEBUG] Not resuming any session
[2024-06-11T18:31:06Z DEBUG] Using ciphersuite TLS13_AES_128_GCM_SHA256
[2024-06-11T18:31:06Z DEBUG] Not resuming
[2024-06-11T18:31:06Z DEBUG] TLS1.3 encrypted extensions: [ServerNameAck]
[2024-06-11T18:31:06Z DEBUG] ALPN protocol is None
[2024-06-11T18:31:06Z DEBUG] created stream: Stream(RustlsStream)
[2024-06-11T18:31:06Z DEBUG] sending request GET https://crates.io/api/v1/crates/espflash/versions
[2024-06-11T18:31:06Z DEBUG] writing prelude: GET /api/v1/crates/espflash/versions HTTP/1.1
    Host: crates.io
    User-Agent: ureq/2.9.7
    Accept: */*
    accept-encoding: gzip
[2024-06-11T18:31:06Z DEBUG] Chunked body in response
[2024-06-11T18:31:06Z DEBUG] response 200 to GET https://crates.io/api/v1/crates/espflash/versions
[2024-06-11T18:31:06Z DEBUG] dropping stream: Stream(RustlsStream)
[2024-06-11T18:31:06Z DEBUG] Config: Config {
        baudrate: None,
        bootloader: None,
        connection: Connection {
            serial: None,
        },
        partition_table: None,
        usb_device: [],
        flash: FlashSettings {
            mode: None,
            size: None,
            freq: None,
        },
        save_path: "/home/cmorgan/.config/espflash/espflash.toml",
    }
[2024-06-11T18:31:06Z WARN ] Pre-connection option 'NoResetNoSync' was selected. Connection may fail if the chip is not in bootloader or flasher stub mode.
[2024-06-11T18:31:06Z INFO ] Serial port: '/dev/ttyUSB0'
[2024-06-11T18:31:06Z INFO ] Connecting...
[2024-06-11T18:31:06Z DEBUG] Writing command: ReadReg { address: 1610641496 }
Error: espflash::timeout

  × Error while connecting to device
  ╰─▶ Timeout while running ReadReg command

Some years ago I did something similar with esptool.py I think and a board that didn't have the CP2102 uart chip and it worked ok, but that was very manual in terms of memory addresses etc and a bin file vs. the elf file.

[cmorganBE]

@SergioGasquez any other info from here that could help?

[SergioGasquez]

Could you try using probe-rs? I think it might work for your use case.

[cmorganBE]

@SergioGasquez can it? Is the protocol used for flashing the esp32 a standard? I'm not looking for serial interactivity, or jtag/swd debugging, just flashing (which is what drew me to espflash :-) )

[SergioGasquez]

@SergioGasquez can it? Is the protocol used for flashing the esp32 a standard? I'm not looking for serial interactivity, or jtag/swd debugging, just flashing (which is what drew me to espflash :-) )

probe-rs can also be used to flash via the USB/Serial-JTAG, see https://docs.esp-rs.org/book/tooling/debugging/probe-rs.html#probe-rs and probe-rs docs

[cmorganBE]

@SergioGasquez sure, but why wouldn't espflash be the place for this? It's already handling chip specific things and has the proper options to exclude reset/boot etc.

Wouldn't I have to do a bunch of the same stuff to use probe-rs for this?

If espflash isn't the right place for this kind of thing I'd be interested in why.

[cmorganBE]

Any updates on this issue? I'd like to use espflash for code load here without needing a build and esp-idf sdk on the system to load code.

[Vollbrecht]

you mention you are only connectiong tx/rx ? If you are not programming through usb-jtag but through an usb/uart converter on the uart site you need to have the correct connections. In the general case its not enough to have tx/rx connected but also dtr/rts signals. They usually go to the esp32s3 reset gpio and to the gpio0 of the chip respectivly. If that is not present than you cant expect to have a working autodownload! In that case you need to manually reset it. For example look at one official dev board schematic how its connected correctly.

[cmorganBE]

@Vollbrecht agreed, that's why I mentioned in my initial comment that I'm disabling the reset and boot control features.

I had expected that because I was putting in into bootrom codeload mode manually, that espflash would be able to program it. (I also posted how I was aware it was in that mode). I've done this in the past with espflash I think but that requires knowing memory addresses I think as well.

The use case for this product something like:

• Operator holds boot button
• Operator power cycles
• Operator runs espflash to program code