ESP-WROOM-32 module with ARM-USB-OCD-H from Olimex

[intector]

Hallo,

I’m using the ESP32-DevKitC which contains the ESP-WROOM-32 module from ESPRESSIF. I am able to successfully build and flash those modules on the command line under Ubuntu and Eclipse.

Then I followed one of your tutorials(https://visualgdb.com/tutorials/esp32/) about developing software for the ESP32 and I can’t get it to work. I am using the ARM-USB-OCD-H from Olimex and connected the module correctly. Your Software can see the ESP32 module and even flashes the chip, but after the reset the chip can’t start and hangs in an endless restart cycle.

It almost looks like the flash process don’t flash the correct stuff to the chip, like not partition or bootloader, but I’m not sure about that.

I would love to use your software, but it simply don’t work correctly.

[support]

Hi,

It looks like the replies sent via our support system don’t reach your email address, so please add ticket@sysprogs.com to your spam filter whiltelist.

Below is a copy of our last reply regarding ESP32-WROOM.

Unfortunately the general problem with ESP32 devices is that they are less reliable than ARM devices and don’t provide adequate diagnostic means, so we have to limit our support to a few popular devices that we could test on our side and a few very basic scenarios.

To make it easier to diagnose the problems that we cannot handle on our side, we made all our ESP8266/ESP32 support open-source: https://github.com/sysprogs/BSPTools/tree/master/DebugPackages/ESP8266DebugPackage

When VisualGDB programs an ESP32 firmware, it loads 3 regions of FLASH:

• The bootloader (at 0x1000)
• The partition table (at 0x8000)
• The image itself (typically at 0x10000)

You can find the related logic in ESP32StartupSequence.cs, line 180. If the program fails to start on the ESP32-WROOM module, it could be caused by one of the 3 reasons:

• The memory is not programmed correctly
• The bootloader configuration or the partition table is wrong
• The compiled program is doing something unsupported (e.g. it was compiled with no optimization and hence triggers a bug in the ESP-IDF)

In order to diagnose this, please try using the esptool.py to read the FLASH memory contents back to the disk and then compare it with the bootloader file, partition table file and the <program>-esp32.bin file. This should help understand if the programming itself succeeds.

If the programming succeeds, please try programming the version that works (e.g. the one built via ESP-IDF build scripts) and compare the bootloader and the partition table contents. If they are different, please try overriding them.

If both the bootloader and the partition table are the same, please send us the downloaded first 1024 bytes of FLASH memory at offset 0x10000 for both the version that works and then one that does not so we could quickly compare the ESP32 image headers and check if there is any obvious reason for this.

[Author]

Posts