ESP32S3-WROOM-2-32R8 and Arduino IDE Debugger

[microfoundry]

Board

ESP32-S3-DevKitC-1-N-32R8V

Device Description

ESP32-S3-DevKitC with only USB serial cable attached.

Hardware Configuration

n/a other than onboard RGB used in sketch.

Version

v3.0.4

IDE Name

Arduino IDE 2.3.2

Operating System

Win 11

Flash frequency

80

PSRAM enabled

yes

Upload speed

921600

Description

Debugger fails memory scan and fails to attach. ESP32-S3-DevKitC-1-N-32R8V, fails Custom PCB with 32R8V, fails Tested same simple blink code with Pico-Mini DevKit, Success Test on ESP32-S3 module with 16MB, Success

Sketch

Any, but using the RMTWriteNeoPixel.ino as a test.

Debug Message

Open On-Chip Debugger v0.12.0-esp32-20240318 (2024-03-18-18:26)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : only one transport option; autoselecting 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : esp_usb_jtag: serial (7C:DF:A1:E4:45:E0)
Info : esp_usb_jtag: Device found. Base speed 40000KHz, div range 1 to 255
Info : clock speed 40000 kHz
Info : JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : [esp32s3.cpu0] Examination succeed
Info : [esp32s3.cpu1] Examination succeed
Info : starting gdb server for esp32s3.cpu0 on 50000
Info : Listening on port 50000 for gdb connections
Info : [esp32s3.cpu0] Target halted, PC=0x4037BBCE, debug_reason=00000001
Info : [esp32s3.cpu0] Reset cause (21) - (USB UART reset)
Info : Set GDB target to 'esp32s3.cpu0'
Info : [esp32s3.cpu1] Target halted, PC=0x4205F8AC, debug_reason=00000000
Info : [esp32s3.cpu1] Reset cause (21) - (USB UART reset)
Info : accepting 'gdb' connection on tcp/50000
Warn : No symbols for FreeRTOS!
Info : [esp32s3.cpu0] Target halted, PC=0x4038E452, debug_reason=00000001
Warn : Failed to get flash maps (-1)!
Warn : Failed to get flash mappings (-4)!
Info : [esp32s3.cpu0] Target halted, PC=0x4038E452, debug_reason=00000001
Error: Failed to get flash size!
Info : [esp32s3.cpu0] Target halted, PC=0x4038E452, debug_reason=00000001
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[TD-er]

At low level SPI commands you need to supply the address per byte. So if you go over 16M, you do need more than 24 bits and thus more than 3 bytes.

Maybe some of the SPI code does not allow to access areas over 16M? Have you tried on this board with a board definition for 16M flash? Though it might be hard to upload a sketch to force 16M behavior to the board using Arduino IDE or esptool.py as those might 'patch' the binary when they detect a larger flash size.

[microfoundry]

FWIW - as per the next-to-last line in the error output (above), adding the 'gdb_memory_map disable' to esp32s3-builtin.cfg does at least get the debugger to launch.

[microfoundry]

Based purely on code review for "Failed to get flash size!" is here: stub_flasher.c Which utilizes this function: uint32_t stub_flash_get_size(void) That calls this function: uint32_t stub_flash_get_id(void) That includes this block of logic:

    uint32_t ret = READ_PERI_REG(PERIPHS_SPI_FLASH_C0) & 0xffffff;
    STUB_LOGD("Flash ID read %x\n", ret);
    if (ets_efuse_flash_octal_mode() && (ret & 0xFF) != ESP_FLASH_CHIP_MXIC_OCT) {
        STUB_LOGE("Unsupported octal flash manufacturer\n");
        return 0;
    }

I have not done any debugging of the OpenOCD process itself, but I did include this line in a simple program:

#include "soc/spi_mem_reg.h"
#include "rom/spi_flash.h"

  log_i("flash %x, cs %x, bs %x, ss %x, ps %x, sm %x\n",
        rom_spiflash_legacy_data->chip.device_id,
        rom_spiflash_legacy_data->chip.chip_size,
        rom_spiflash_legacy_data->chip.block_size,
        rom_spiflash_legacy_data->chip.sector_size,
        rom_spiflash_legacy_data->chip.page_size,
        rom_spiflash_legacy_data->chip.status_mask);

On a 8MB device, the output is: flash c84017, cs 400000, bs 10000, ss 1000, ps 100, sm ffff

On a 16MB device, the output is: flash c86018, cs 1000000, bs 10000, ss 1000, ps 100, sm ffff

On the 32MB device the output is: flash c28039, cs 2000000, bs 10000, ss 1000, ps 100, sm ffff

In all 3 cases the 2 LSB value of the chip.device_id = coincidentally(?) map to stub_flash_get_size() case statement which would return the proper memory size, including 0x39 = 32MB.

And to add to the coincidental factor, for the failing 32MB device, the 2 MSB chip.device_id = "c2" which happen to match the define: ESP_FLASH_CHIP_MXIC_OCT... So I take a swag and say there's something wrong in the "if (octal mode..." logic or value feeding it.

Validation Num 2, again same mfg / device code :

C:>esptool.exe flash_id
esptool.py v4.6
Found 2 serial ports
Serial port COM8
Connecting...
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (revision v0.1)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 7c:df:a1:e4:45:e0
Uploading stub...
Running stub...
Stub running...
Manufacturer: c2
Device: 8039
Detected flash size: 32MB
Flash type set in eFuse: octal (8 data lines)
Hard resetting via RTS pin...

[lbernstone]

Did you open an issue at the openocd-esp32 repo? This project is downstream of their code, so if that function is mis-identifying the flash, they would need to provide the fix. In any case, they can clarify whether the issue is something in openocd or if the usb reset is the real error here.

[microfoundry]

Good point! An issue has been raised...