ESP32 Forum

Posted: **Wed Apr 17, 2019 4:55 pm**

Hi,

I've received my Ai-Thinker ESP32-CAM modules yesterday, installed the toolchain and tried to flash some examples on it, but esptool fails after the "Running stub..." step. Here's the terminal output for the flash_id command:

Code: Select all

$ python esptool.py --port /dev/ttyACM1 flash_id
esptool.py v2.7-dev
Serial port /dev/ttyACM1
Connecting......
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:0a:c4:2e:1b:f8
Uploading stub...
Running stub...
Traceback (most recent call last):
  File "esptool.py", line 3073, in <module>
    _main()
  File "esptool.py", line 3066, in _main
    main()
  File "esptool.py", line 2780, in main
    esp = esp.run_stub()
  File "esptool.py", line 608, in run_stub
    p = self.read()
  File "esptool.py", line 280, in read
    return next(self._slip_reader)
StopIteration

When running esptool with the --no-stub argument, it works:

Code: Select all

$ python esptool.py --port /dev/ttyACM1 --no-stub flash_id
esptool.py v2.7-dev
Serial port /dev/ttyACM1
Connecting.......
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:0a:c4:2e:1b:f8
Enabling default SPI flash mode...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

When running esptool with the --trace option enabled, the error I get before the traceback is:

Code: Select all

TRACE +0.051 Timed out waiting for packet header

I have connected the IO0 pin to ground as described in many guides, and pushed the reset button before uploading. I have verified that the ESP is entering bootloader mode with a serial terminal, I get the "waiting for download..." message.

The ESP32-CAM board is connected to my laptop via an MSP430 development board, which I'm using as a USB to serial converter. I'm using this board because it provides 5V as well as 3.3V, and the serial lines are on 3.3V rather than the 5V of my other ISP. I've also tried powering the ESP from the 5V line of an old PC power supply, without success. Another thing I've tried is disconnecting the camera.

I would be very grateful if anyone could point me in the right direction here, after hours of tinkering I'm kind of lost.

Thank you very much and please let me know if I can provide any more details.

Posted: **Thu Apr 18, 2019 12:52 am**

Hi b4hofer,

Can you please post the full output from "trace" somewhere?

Is there any chance you have a logic analzyer and can capture the serial interactions to/from the ESP32, on the wire?

The unusual thing which sticks out in your report is the MSP430 as USB/serial adapter. In the past there have been a number of esptool bug reports with unusual symptoms like this, that came down to some unusual timing or (sometimes) data loss or buffering problems through custom USB/serial converters running on MCUs.

The stub loader uses different (and more heavily optimised) UART routines to the ROM code, so it could easily be tripping up on something unusual that the ROM code is ignoring.

If the serial behaviour is correct and the difference is only in timing then we can probably fix the shortcoming in the stub loader code, but most likely I will need the logic analyzer and esptool trace output in order to figure out what exactly the difference is.

The alternative is to use --no-stub, if this is working for you.

Posted: **Fri Apr 19, 2019 5:26 pm**

Hi Angus,

thank you very much for your quick reply.

Here's the full output from --trace: https://pastebin.com/wStzFvqn

I have also attached a capture file from my Saleae logic analyzer in CSV and Saleae's .logicdata format, executing the same esptool --port /dev/ttyACM1 flash_id command. Please let me know if you would like the data in another format.

Is there any drawback to using esptool with the --no-stub option? I must admit I don't really know what it does.

Thanks, I really appreciate your help.

Bernhard

Posted: **Tue Apr 23, 2019 4:45 am**

Thanks for the trace. I think this is a timing issue with the USB/serial converter buffering received serial data for longer than expected.

Can you please try one thing for me. In esptool.py, find this line near the top:

Code: Select all

MEM_END_ROM_TIMEOUT = 0.05            # special short timeout for ESP_MEM_END, as it may never respond

And change this value from 0.05 to 0.2. The stub should start working.

Is there any drawback to using esptool with the --no-stub option? I must admit I don't really know what it does.

On ESP32, the main benefit is that flashing and some other operations (like reading flash) are faster. Plus there are a few commands which are only available when using the stub loader.

If --no-stub is passed, the ROM loader program responds to all commands. If a stub is loaded, this runs in IRAM and responds to the commands.

Posted: **Wed Apr 24, 2019 2:22 pm**

It works!

After changing the line you suggested, the stub runs without any problems.

Thank you so much for your help, I really appreciate it.

ESP32 Forum

esptool timed out after "Running stub..."

esptool timed out after "Running stub..."

Re: esptool timed out after "Running stub..."

Re: esptool timed out after "Running stub..."

Re: esptool timed out after "Running stub..."

Re: esptool timed out after "Running stub..."