progress on VS Code debugger

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

progress on VS Code debugger

Postby mzimmers » Tue Jan 04, 2022 8:07 pm

Hi all -

I've made some progress getting the debugger working within VS Code. I got it working on a development board, and am now trying to get it working with our own board.

- the module is the ESP32-WROOM-32U.
- the debugger is the ESP PROG.
- I'm not (yet) trying to use the ESP PROG to program the board; I'm still doing through our serial interface.

Here's my launch.json file:

Code: Select all

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "espidf",
            "debugPort": 43474,
            "logLevel": 2,
            "mode": "auto",
            "name": "ESP32 OpenOCD",
            "initGdbCommands": [
                "target remote :3333",
                "symbol-file ${workspaceFolder}/build/iqpump.elf",
                "set remote hardware-watchpoint-limit 2",
                "monitor reset halt",
                "flushregs",
                "thb app_main",
                "c"
            ]
        }
    ]
}
When I attempt to start OpenOCD, I get this error:

Code: Select all

Open On-Chip Debugger  v0.10.0-esp32-20210401 (2021-04-01-15:46)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 2

adapter speed: 20000 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
❌ Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 20000 kHz
❌ Error: JTAG scan chain interrogation failed: all ones
Error: Check JTA❌ G interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
❌ Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
The first error (LIBUSB_ERROR_NOT_SUPPORTED) I was getting when (successfully) using the debugger with the ESP32 board, so I don't think it's relevant. But I don't know what to do about the others. Any suggestions?

Thanks...

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: progress on VS Code debugger

Postby ESP_Sprite » Wed Jan 05, 2022 1:10 am

Error: JTAG scan chain interrogation failed: all ones
This indicates an issue between the ESP-Prog and the Xtensa core: disconnected cabling, wrong connections, speed too high, GPIOs reconfigured from JTAG to something else by the ESP32 app, etc.

rsimpsonbusa
Posts: 131
Joined: Tue May 17, 2016 8:12 pm

Re: progress on VS Code debugger

Postby rsimpsonbusa » Wed Jan 05, 2022 2:29 am

Hi.

I finally got the time/nerve to setup the ESP32 environment to use a proper debugger instead of the mighty printf :D

I procrastinated cause the setup was very elaborate or badly documented or when I tried I never got it to work.

So New Year resolution, make it work, and I got it to work semi automatic :shock:

I have the ESP PROG, connected cables as stated everywhere (TMS GPIO14/TCK GPIO13/TDO GPIO15/TDI GPIO12 3.3V and GND).

I am using VS Code also so i open a ESP-IDF Terminal and manually start Openocd with

Code: Select all

openocd -c 'set ESP_RTOS none' -f interface/ftdi/esp32_devkitj_v1.cfg -f board/esp-wroom-32.cfg
The -c 'set ESP_RTOS none' is so that it runs on the first call and not 3rd or more calls (ERROR: Unable to start debugging. Failed to find thread 1 for break event) and as a result the RTOS tasks are not visible.

Now I start the debugger using the VS Code debugger with the following launch.json

Code: Select all

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "ESP32 OpenOCD",
            "type":"cppdbg",
            "request": "launch",
            "cwd":"${workspaceFolder}/build",
            "program": "${workspaceRoot}/build/[i]programName[/i].elf",
            "miDebuggerPath": "/Users/rsn/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gdb",
            "setupCommands": [
                {"text":"target remote 127.0.0.1:3333"},
                {"text":"set remote hardware-watchpoint-limit 2"},
                {"text":"monitor reset halt"},
                {"text":"flushregs"}
            ]      

        }
    ]
}
I tried to use in launch.json the prerequisite parameter that calls a task that runs the openocd cmd but i get a failure I dont understand how to fix it. Maybe Ill try later on.

As a debugger is good enough except I cannot get to the global variables, if you know how I would be grateful.

Step stepinto stepout breakpoints conditional bp etc.

Not bad but certainly better than printf except for the not getting to global variables.

rsimpsonbusa
Posts: 131
Joined: Tue May 17, 2016 8:12 pm

Re: progress on VS Code debugger

Postby rsimpsonbusa » Wed Jan 05, 2022 3:02 am

Hi.

Got a launch.json that does not require manually starting openocd.

Code: Select all

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "ESP32 OpenOCD",
            "type":"espidf",
            "request": "launch",
            "cwd":"${workspaceFolder}/build",
            "MIMode": "gdb",
            "program": "${workspaceRoot}/build/${command:espIdf.getProjectName}.elf",
            "miDebuggerPath": "${command:espIdf.getXtensaGdb}",
            "environment": [{ "name": "PATH", "value": "${config:idf.customExtraPaths}" }],
            "setupCommands": [
                {"text":"target remote 127.0.0.1:3333"},
                {"text":"set remote hardware-watchpoint-limit 2"},
                {"text":"monitor reset halt"},
                {"text":"flushregs"},
                {"text":"thb app_main"}
            ],
            "externalConsole": false,
            "logging": {
              "engineLogging": true
            }
        }
    ]
}
Your " Error: JTAG scan chain interrogation failed: all ones" is most likely cable connections.

Attach an image fo connections if it helps.
Attachments
Screen Shot 2022-01-04 at 21.48.45.png
Screen Shot 2022-01-04 at 21.48.45.png (474.4 KiB) Viewed 16823 times

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: progress on VS Code debugger

Postby mzimmers » Wed Jan 05, 2022 3:24 am

Hi Sprite -

Thanks for the reply. So, how does one go about chasing this down? I don't believe I'm re-assigning any relevant GPIO pins. Where do I review the speed settings, etc. that you listed?

Here's an excerpt from my settings.json file:

Code: Select all

    "idf.adapterTargetName": "esp32",
    "idf.portWin": "COM8",
    "idf.openOcdConfigs": [
        "interface/ftdi/esp32_devkitj_v1.cfg",
        "target/esp32.cfg"
    ]
Thanks for any guidance...

ESP_Sprite
Posts: 9757
Joined: Thu Nov 26, 2015 4:08 am

Re: progress on VS Code debugger

Postby ESP_Sprite » Wed Jan 05, 2022 4:18 am

The speed is in interface/ftdi/esp32_devkitj_v1.cfg, from your post it seems to be set at 20MHz. Suggest lowering that by a bunch first (to e.g. 1MHz or even 100KHz) simply to make sure the issue is not signal integrity.

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: progress on VS Code debugger

Postby mzimmers » Wed Jan 05, 2022 3:20 pm

Thanks, Sprite. I don't see a speed option for the launch.json file; do I have to change the file in my toolchain (or make a copy), or is there another way to make this change?

EDIT: I created a new file, esp32_devkitj_v1-slow.cfg, with the entry:

adapter_khz 100

and put that in my settings.json file; same results. I also verified that we're not re-using any of the JTAG pins.

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: progress on VS Code debugger

Postby mzimmers » Wed Jan 05, 2022 5:44 pm

Hi rsimpsonbusa -

It looks like you've gotten a little further than I have. I'm trying to use the ESP-IDF Debug Adapter, so the entries in our launch.json files aren't going to completely correspond.

You might be right about the cabling, but it seems straightforward. I'm connecting the ESP-Prog to my board using the (small) 10-pin header. Another developer here managed to connect with a SEGGER using the same header on our board, so I don't think it's a board issue.

EDIT: here's the output from a CLI command to start OpenOCD:

Code: Select all

C:\Users\mzimmers\fluidra\cp_fluidra\fw>openocd -f interface/ftdi/esp32_devkitj_v1-slow.cfg -f target/esp32.cfg
Open On-Chip Debugger  v0.10.0-esp32-20210401 (2021-04-01-15:46)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 100 kHz

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 100 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Listening on port 3333 for gdb connections
I'm wondering whether that libusb_open() error is the culprit here.

EDIT #2: I enabled debug-level output, and now get this:

Code: Select all

Info : 532 1951 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu0 tap/device found: 0xffffffbf (mfg: 0x7df (<unknown>), part: 0xffff, ver: 0xf)
Warn : 533 1953 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu0       UNEXPECTED: 0xffffffbf (mfg: 0x7df (<unknown>), part: 0xffff, ver: 0xf)
Error: 534 1961 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu0  expected 1 of 1: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Debug: 535 1971 jep106.c:33 jep106_manufacturer(): BUG: Caller passed out-of-range JEP106 ID!
Info : 536 1978 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu1 tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Debug: 537 1982 jep106.c:33 jep106_manufacturer(): BUG: Caller passed out-of-range JEP106 ID!
Warn : 538 1982 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu1       UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Error: 539 1992 core.c:1027 jtag_examine_chain_display(): JTAG tap: esp32.cpu1  expected 1 of 1: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
I don't know whether that "out-of-range JEP106" message is meaningful, but maybe someone here will understand it.

rsimpsonbusa
Posts: 131
Joined: Tue May 17, 2016 8:12 pm

Re: progress on VS Code debugger

Postby rsimpsonbusa » Wed Jan 05, 2022 7:01 pm

Hi mzimmers.

To test cable problems I exchanged gpio15 with gpio14 and tried to start the ESP PROG, getting the all ones error.
Also I disconnected the GPIO15 and same all ones error.

Yes, I also think that cables shouldn't be something you cannt resolve.

Still I attach an image of connections from ESP PROG to a ESP32 wroom programmer and the log output of all ones and correct connection. It also worked with a DevKit.

vscode Version: 1.63.2 with espidf v4.3.1.

Good luck

Regards.
Attachments
IMG-20220105-WA0005.jpg
IMG-20220105-WA0005.jpg (196.17 KiB) Viewed 16668 times
Screen Shot 2022-01-05 at 13.45.06.png
Screen Shot 2022-01-05 at 13.45.06.png (111 KiB) Viewed 16668 times

Who is online

Users browsing this forum: No registered users and 28 guests