ESP32 and ESP-Prog continuing issues

Development Platforms
1

This item is a continuation of a previous post, that thread was getting too long and difficut to follow:

Problem uploading to ESP32-CAM with ESP-Prog - Development Platforms - PlatformIO Community

I am finding that using the PlatformIO extension for VSCode on a small ESP32 project is quite unreliable. I have now spent several days trying to pin down what the triggers for the failures are. The problem is that it appears there may be more than one issue and that secondary failures occur as a result of some unidentified issue. I began to think the issue was with the ESP32-CAM boards, however, after changing to an ESP32 DevKit I see the same issues.

Uploading using JTAG and the ESP-Prog sometimes works and sometimes not. Once the uploading has failed, changing to use serial with PlatformIO to upload also fails. It is interesting to note that switching to the Arduino IDE (v1.8) always uploads, also, when trying PlatformIO upload via the serial port after Arduino, it generally works again.

This is the terminal output when JTAG fails:

WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 500 kHz

Warn : Empty flash mapping!
Warn : Failed to get flash mappings (0)!
Error: Failed to get flash size!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Failed to find bank 'esp32.cpu0.flash'!

*** [upload] Error 1

Repeating the upload attempts with JTAG continues to produce the above error.

After switching to the Arduino IDE v1.8 and uploading successfully, the next upload attempt with JTAG produces a slightly different error:

WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
DEPRECATED! use 'adapter speed' not 'adapter_khz'
adapter speed: 500 kHz

Error: timed out while waiting for target halted
Error: xtensa_wait_algorithm: not halted 0, pc 0x4000c2e8, ps 0x60e23
Error: Failed to wait algorithm (-302)!
Error: Algorithm run failed (-302)!
Error: Too many flash mappings 10417884! Must be 2.
Warn : Failed to get flash mappings (-4)!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Failed to find bank 'esp32.cpu0.flash'!

*** [upload] Error 1

I am very happy to debug this issue, however I need some guidance as to where to start.

I am hoping that once this can be resolved debugging with JTAG will also begin to work reliably.

I really want this all to work, but there is a limit to how many days I can be running in circles without progress on my project.

Sincerely,
Sid

2

It looks as if your sketch configures the JTAG pins or is using deep sleep. The result is the same in both cases: JTAG does not work.

To troubleshoot your issues:

  • Start with the blink sketch and upload it via the default upload protocol (esptool), i.e. without JTAG
  • Configure upload_protocol = esp-prog and try the upload again. This will upload it via JTAG and test the JTAG communication while no sketch is running
  • Try debugging the blink sketch. It will test the JTAG communication while the sketch is running.

And use the simplest dev board you have and not one with JTAG pins wired to LEDs, SD card slots etc.

1 Like
3

@manuelbl Neither of the two sketches I have tried initializes the JTAG pins or uses deep sleep. One of the sketches is a blink-link sketch. It uses only the Serial output to send a message every 2-seconds.

4

I’ve seen this error pop up in other posts too, but not sure if someone ever got to the bottom of it. I can only verify that with a adafruit FT232H board, not with a esp-prog.

5

@maxgerhardt That is the secondary error that occurs after the initial failure. Some part of the system appears to be getting into a bad state.

At the moment I am unable to use the ESP-Prog, back to using serial and println!

6

Could we ask you to post this issue on https://www.esp32.com/ ? Maybe, the Espressif Systems engineers have an idea. It would be great to share a solution to this problem. So, others will find it useful.

7

Hello @ivankravets I just did that:

https://www.esp32.com/viewtopic.php?f=40&t=28580

8

It really looks like a hardware problem with your board. Are you still using the ESP32-CAM board?

The ESP32-CAM board has a few pitfalls:

  • The JTAG pins are also used for the SD card. So if an SD card is inserted, JTAG does not work. The same if the SD card code is initialized.
  • Another user in this forum was only successful when powering the ESP32 board with 5V. You certainly shouldn’t power the board from the ESP-Prog as it cannot provide sufficient power.

If you do not get an answer on the esp32.com forum, I propose you provide the full information of your project here:

  • Exact board you are using
  • Complete schematics / wiring diagram of how the ESP32 board and the ESP-Prog are connected to each other, to a computer and to power supplies
  • Complete and minimal PIO project (basically platformio.ini and main.cpp)
9

Sid,

This sounds like a dumb reply but I’ve found that poor quality and long USB cables cause problems with some ESP32 boards.

The various cheap ESP32 cam boards, I’ve found difficult to repeatably load code to, either with Platform I/O or the Arduino IDE. I’ve come to the conclusion that the problems are with the hardware. There are hardware guidelines on the Espressive site it might be worth looking at.

The only ESP32 boards I’ve not had problems with are the AZDelivery ones. AZ delivery quality assure the boards they sell. So I tend to use them. Sadly they don’t do one with a camera on.

Regards,

Steve

10

Hi Steve, thanks very much for taking the time to respond. In this case the USB cables are high-quality, and the issue remains regardless of cable changing.

The total lack of support from Espressif, while not surprising, is disappointing. Unless I have to use one of their boards or modules, I will be avoiding them in the future. I guess you get what you pay for :frowning: