Closed joyk3872 closed 2 years ago
joyk3872
commented
2 years ago I have looked at the Doctor command results I submitted earlier and tried to fix some of the paths. Here's my new Doctor command results - even with this, I still see the same issue where I can't start debug immediately after flashing the board.
gerekon
commented
2 years ago Hi @joyk3872
According to your log below error messages are produced when chip was reset and halted and therefore app (with FreeRTOS) had not been started yet at that moment, so internal FreeRTOS data had not been initialized, so OpenOCD reads garbage and reports that. This is not critical and normal in this state,
1, FreeRTOS.c:856 freertos_update_threads(): FreeRTOS maximum used priority is unreasonably big, not proceeding: 126
2. FreeRTOS.c:893 freertos_update_threads(): Too large number of threads 1103303849!I see that initial breakpoint at app_main is set before program is started after reset.
gdb_server.c:401 gdb_log_incoming_packet(): [esp32.cpu0] received packet: Z1,400d4bf7,2
Debug: 8429 43119 gdb_server.c:1752 gdb_breakpoint_watchpoint_packet(): [esp32.cpu0]
Debug: 8430 43119 xtensa.c:1987 xtensa_breakpoint_add(): esp32.cpu0: placed HW breakpoint @ 0x400d4bf7
Debug: 8431 43119 breakpoints.c:104 breakpoint_add_internal(): [0] added hardware breakpoint at 0x400d4bf7 of length 0x00000002, (BPID: 0)
Debug: 8432 43119 xtensa.c:1987 xtensa_breakpoint_add(): esp32.cpu1: placed HW breakpoint @ 0x400d4bf7
Debug: 8433 43119 breakpoints.c:104 breakpoint_add_internal(): [1] added hardware breakpoint at 0x400d4bf7 of length 0x00000002, (BPID: 1)I see the problem when you start debugging. Debug Adapter complains that it can not launch program due to timeout expired (10 s). See below. Timeout can be caused by enabled verbose logging. Do you see the same behavior with default log level? I think that timeout error below should be printed at any log level.
[Debug Adapter]
2022-08-26 12:12:22,575 - Gdb - INFO - NOTIFY: running {'thread-id': 'all'}
[OpenOCD]
Debug: 8493 43670 gdb_server.c:418 gdb_log_outgoing_[OpenOCD]
packet(): [esp32.cpu0] sending packet: $O#4f
[Debug Adapter]
2022-08-26 12:12:23,076 - Gdb - INFO - CONS: 'Note: automatically using hardware breakpoints for read-only addresses.\\n'
[OpenOCD]
Debug: 8494 44232 gdb_server.c:418 gdb_log_outgoing[OpenOCD]
_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8495 44775 gdb_server.c:[OpenOCD]
418 gdb_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8496 45308 gdb_server.c:418 gdb_log[OpenOCD]
_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8497 45840 gdb_server.c:418 g[OpenOCD]
db_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8498 46391 gdb_server.c:[OpenOCD]
418 gdb_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8499 46926 gdb_server.c:418 gdb_log_outg[OpenOCD]
oing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8500 47466 gdb_server.c:418 gdb_log_outg[OpenOCD]
oing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8501 48027 gdb_server.c:418 gdb[OpenOCD]
_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8502 48574 gdb_server.c:418 g[OpenOCD]
db_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8503 49117 gdb_server.c:418 gdb_lo[OpenOCD]
g_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8504 49673 gdb_server.c:418 gdb_log_outg[OpenOCD]
oing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8505 50215 gdb_server.c:418 gd[OpenOCD]
b_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8506 50749 gdb_server.c:418 gdb_l[OpenOCD]
og_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8507 51299 gdb_server.c:418 gdb_l[OpenOCD]
og_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8508 51836 gdb_server.c:418 g[OpenOCD]
db_log_outgoing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8509 52369 gdb_server.c:418 gdb_log_outg[OpenOCD]
oing_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8510 52898 gdb_server.c:418 gdb_log_outgoing[OpenOCD]
_packet(): [esp32.cpu0] sending packet: $O#4f
[OpenOCD]
Debug: 8511 53449 gdb_server.c:418 gdb_log_out[OpenOCD]
going_packet(): [esp32.cpu0] sending packet: $O#4f
[Debug Adapter]
2022-08-26 12:12:32,608 - Debug Adapter (main) - ERROR - Failed to wait for target state 1! Current state 2
Traceback (most recent call last):
File "c:\Users\jkull\.vscode\extensions\espressif.esp-idf-extension-1.5.0\esp_debug_adapter\debug_adapter\command_processor.py", line 144, in on_launch_request
self.da.run(start=(not self.da.state.no_debug))
File "c:\Users\jkull\.vscode\extensions\espressif.esp-idf-extension-1.5.0\esp_debug_adapter\debug_adapter\debug_adapter.py", line 824, in run
rsn = self._gdb.wait_target_state(dbg.TARGET_STATE_STOPPED, 10)
File "c:\Users\jkull\.vscode\extensions\espressif.esp-idf-extension-1.5.0\esp_debug_adapter\debug_adapter\debug_backend\debug_backend\gdb.py", line 560, in wait_target_state
raise DebuggerTargetStateTimeoutError("Failed to wait for target state %d! Current state %d" % (state, self._target_state))
debug_adapter.debug_backend.debug_backend.defs.DebuggerTargetStateTimeoutError: Failed to wait for target state 1! Current state 2According to your log I can say that the verbose log should not be the reason because there are no much output during those 10 s (see above). After debug session was terminated I see that chip was stopped forcibly somewhere in ROM code (see below). It could be because initially you put chip ROM into download mode by pressing BOOT and RST buttons because of the problems with flashing. So I suggest you to solve the initial problem with flasjing at first. Could you try without pressing BOOT and RST buttons and post the log here? I suppose that you selected Flashing via OpenOCD method in IDE instead of Flashing over UART.
Debug: 8530 53714 xtensa.c:1858 xtensa_poll(): esp32.cpu0: Target halted, pc=0x40008747, debug_reason=00000000, oldstate=00000001
Debug: 8531 53715 xtensa.c:1863 xtensa_poll(): esp32.cpu0: Halt reason=0x00000020, exc_cause=0, dsr=0x80b1cc11
Info : 8532 53715 xtensa.c:1866 xtensa_poll(): esp32.cpu0: Target halted, PC=0x40008747, debug_reason=00000000
[OpenOCD]
Debug: 8533 53715 esp_xtensa_smp.c:258 esp_xtensa_smp_update_halt_gdb(): GDB target 'esp32.cpu0'
Info : 8534 53715 esp_xtensa_smp.c:263 esp_xtensa_smp_update_halt_gdb(): Set GDB target to 'esp32.cpu0'
Debug: 8535 53716 esp_xtensa_smp.c:272 esp_xtensa_smp_update_halt_gdb(): Check target 'esp32.cpu0'
Debug: 8536 53716 esp_xtensa_smp.c:272 esp_xtensa_smp_update_halt_gdb(): Check target 'esp32.cpu1'
Debug: 8537 53716 esp_xtensa_smp.c:286 esp_xtensa_smp_update_halt_gdb(): Poll target 'esp32.cpu1'
[OpenOCD]
Debug: 8538 53717 xtensa.c:8[OpenOCD]
90 xtensa_fetch_all_regs(): esp32.cpu1: start
[OpenOCD]
Debug: 8539 53720 xtensa.c:788 xtensa_core_st[OpenOCD]
atus_check(): esp32.cpu1: DSR (8090CC11)
[OpenOCD]
Debug: 8540 53724 xtensa.c:788 xtensa_c[OpenOCD]
ore_status_check(): esp32.cpu1: DSR (8090CC11)
[OpenOCD]
Debug: 8541 53725 xtensa.c:788 xtensa_core_status_check(): esp32.cpu1: DSR (8090CC11)
Debug: 8542 53725 xtensa.c:1858 xtensa_poll(): esp32.cpu1: Target halted, pc=0x400076DD, de[OpenOCD]
bug_reason=00000000, oldstate=00000001
Debug: 8543 53725 xtensa.c:1863 xtensa_poll(): esp32.cpu1: Halt reason=0x00000020, exc_cause=0, dsr=0x8090cc11
Info : 8544 53725 xtensa.c:1866 xtensa_poll(): esp32.cpu1: Target halted, PC=0x400076DD, debug_reason=00000000@brianignacio5 I think we need to make all timeouts used by Debug Adapter scale-able and increase them when logging level is verbose. And/or at least we can allow users to set it in config file manually. Can we create a ticket for this?
brianignacio5
commented
2 years ago Isn't this the purpose of "tmoScaleFactor": 1 in launch.json which updates tmo-scale-factor of debug adapter ? @gerekon
gerekon
commented
2 years ago @brianignacio5 Ahh, yes. But it looks like unused in the debug adapter itself. It is used in debug backend package only.
I am not sure if there are any timeouts used in DebugAdapter itself. So this is just a notice.
joyk3872
commented
2 years ago Hi @gerekon, Thanks for replying to my bug report.
I tried to do the JTAG flashing of the LyraT board without pressing the BOOT/RST buttons and the flashing process failed. I am getting the following error:
❌ Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, et[OpenOCD] ❌ c. Error: Trying to use configured scan chain anyway... Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01
The only way I can reliably get the JTAG flashing to work via ESP-PROG is by pressing the BOOT & RST buttons beforehand.
I'm a bit confused as to whether you think the Debug Adapter timeout that I'm seeing is an issue. If so, do you have a fix for it? I'm really hoping to get JTAG debugging working because it's tough to develop without it. Thanks.
esp32-lyrat_v4.3_jtag_flash_no_press_boot_rst_buttons_log_20220901.txt
gerekon
commented
2 years ago HI @joyk3872,
Ok. Let's try to simplfy things and do debugging w/o VsCode. 1) Open command line with ESP-IDF environment. You can either:
cmd.exe in your project directory and invoke %IDF_PATH%/export.bat.
1) Flash blink example app using idf.py flash monitor
2) Check UART output and LED in order to be sure that example works (does not crash or hang etc.).
3) Download the latest OpenOCD release (https://github.com/espressif/openocd-esp32/releases/tag/v0.11.0-esp32-20220706). Unpack it somewhere in your system (assume it to be pointed by %OOCD_DIR%).
3) Run OpenOCD in another command line window %OOCD_DIR%/bin/openocd -s %OOCD_DIR%/share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f target/esp32.cfg -d3 -l oocd.log
4) Open another command line window with ESP-IDF environment (see item 1 above).
4) Create gdbinit file with the follwing contents:
target remote :3333
mon reset halt
flushregs
tbh app_main
c5) Run GDB in new window: xtensa-esp32-elf-gdb -x gdbinit <path_to_your_app_elf>
6) If you have problems, please post oocd.log here.
joyk3872
commented
2 years ago Hi @gerekon,
Prior to seeing your message above, I reinstalled the esp-idf tools manually because our repo structure had changed so I had to update the paths in my project to the new directory structure. It seems that I was able to get the OpenOCD v0.11.0-esp32-20220706 with the Windows installer (I used esp-idf-tools-setup-online-2.16 installer). After building with the new setup, I was able to flash via JTAG without having to press the RST/BOOT buttons and I can now start debugging without seeing any errors in VSCode. Could the old version of ESP OOCD (v0.11.0-esp32-20220411) be the cause of the issues I was seeing?
I'm cautiously optimistic...I've flashed and started/stopped debugging multiple times on the Blink and my own project and it seems to be working fine now.
Thanks for all your help.
joyk3872
commented
2 years ago Hi Alexey,
I may have spoken too soon. This morning, I’m having issues connecting to the LyraT v4.3 board again. I’ve tried your suggestion on doing debugging without VSCode. For some reason, I’m not able to connect to the dev board. I’ve disconnected/reconnected all the cables to power cycle everything and start over but I can’t get it to connect.
Is there a LyraT jumper setting that I need to set up to get this to work? I currently have the dip switches set to enable JTAG on the board. Other than that, none of the jumpers on board are connected.
Attached is the oocd.log file I captured.
Thanks, Joy
From: Alexey Gerenkov @.> Sent: Tuesday, September 13, 2022 4:17 AM To: espressif/vscode-esp-idf-extension @.> Cc: Joy Kull @.>; Mention @.> Subject: Re: [espressif/vscode-esp-idf-extension] JTAG Debugging problems on ESP32-LyraT v4.3 (and ESP32-PICO-KIT) (VSC-959) (Issue #792)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
HI @joyk3872https://github.com/joyk3872,
Ok. Let's try to simplfy things and do debugging w/o VsCode.
Open command line with ESP-IDF environment. You can either:
Flash blink example app using idf.py flash monitor
Check UART output and LED in order to be sure that example works (does not crash or hang etc.).
Download the latest OpenOCD release (https://github.com/espressif/openocd-esp32/releases/tag/v0.11.0-esp32-20220706). Unpack it somewhere in your system (assume it to be pointed by %OOCD_DIR%).
Run OpenOCD in another command line window %OOCD_DIR%/bin/openocd -s %OOCD_DIR%/share/openocd/scripts -f interface/ftdi/esp32_devkitj_v1.cfg -f target/esp32.cfg -d3 -l oocd.log
Open another command line window with ESP-IDF environment (see item 1 above).
Create gdbinit file with the follwing contents:
target remote :3333
mon reset halt
10.flushregs
11.tbh app_main
12.c
— Reply to this email directly, view it on GitHubhttps://github.com/espressif/vscode-esp-idf-extension/issues/792#issuecomment-1245128463, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVUXJA5WTNZE7N2D3CWU57TV6BA7VANCNFSM57XTXDOQ. You are receiving this because you were mentioned.Message ID: @.***>
OS
Windows
Operating System version
Windows 10
Visual Studio Code version
1.70.2
ESP-IDF version
4.4.2
Python version
3.10.4
Doctor command output
---------------------------------------------- ESP-IDF Extension for Visual Studio Code report --------------------------------------------- OS win32 x64 10.0.19044 System environment variable IDF_PYTHON_ENV_PATH undefined System environment variable PATH C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Nordic Semiconductor\nrf-command-line-tools\bin\;C:\Users\jkull\AppData\Local\Programs\Python\Python310\;C:\Users\jkull\AppData\Local\Programs\Python\Python310\Scripts\;C:\Program Files\Git\cmd;C:\Program Files\R\R-4.2.0\bin;C:\Users\jkull\AppData\Local\Android\Sdk\platform-tools;C:\Users\jkull\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\jkull\AppData\Local\Programs\Python\Python310\;C:\Users\jkull\AppData\Local\Microsoft\WindowsApps;C:\Users\jkull\AppData\Local\GitHubDesktop\bin;C:\Users\jkull\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\jkull\AppData\Local\Programs\MiKTeX\miktex\bin\x64\;C:\Users\jkull\Documents\GitRepo\flutter\bin; System environment variable PYTHON undefined Visual Studio Code version 1.70.2 Visual Studio Code language en Visual Studio Code shell C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ESP-IDF Extension version 1.5.0 Workspace folder c:\RockyMountain\code\esp_example_apps\blink ---------------------------------------------------- Extension configuration settings ------------------------------------------------------ ESP-ADF Path (idf.espAdfPath) c:\RockyMountain\code\esp\esp-adf ESP-IDF Path (idf.espIdfPath) c:\RockyMountain\code\esp\esp-idf ESP-MDF Path (idf.espMdfPath) ${env:MDF_PATH} ESP-Matter Path (idf.espMatterPath) ${env:ESP_MATTER_PATH} Custom extra paths (idf.customExtraPaths) c:\RockyMountain\code.espressif\tools\xtensa-esp32-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32-elf\bin;c:\RockyMountain\code.espressif\tools\xtensa-esp32s2-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s2-elf\bin;c:\RockyMountain\code.espressif\tools\xtensa-esp32s3-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s3-elf\bin;c:\RockyMountain\code.espressif\tools\riscv32-esp-elf\esp-2021r2-patch3-8.4.0\riscv32-esp-elf\bin;c:\RockyMountain\code.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;c:\RockyMountain\code.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin;c:\RockyMountain\code.espressif\tools\cmake\3.23.1\bin;c:\RockyMountain\code.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin;c:\RockyMountain\code.espressif\tools\ninja\1.10.2;c:\RockyMountain\code.espressif\tools\idf-exe\1.0.3;c:\RockyMountain\code.espressif\tools\ccache\4.3\ccache-4.3-windows-64;c:\RockyMountain\code.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64 Custom extra vars (idf.customExtraVars) {"OPENOCD_SCRIPTS":"c:\RockyMountain\code\.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411/openocd-esp32/share/openocd/scripts","IDF_CCACHE_ENABLE":"1"} Virtual env Python Path (idf.pythonBinPath) c:\RockyMountain\code.espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe Serial port (idf.port) COM19 OpenOCD Configs (idf.openOcdConfigs) interface/ftdi/esp32_devkitj_v1.cfg,target/esp32.cfg ESP-IDF Tools Path (idf.toolsPath) c:\RockyMountain\code.espressif Git Path (idf.gitPath) c:\Users\jkull\Documents\DeviceSolutions\projects\RockyMountain\code.espressif\tools\idf-git\2.30.1\cmd\git.exe -------------------------------------------------------- Configurations access ------------------------------------------------------------- Access to ESP-ADF Path (idf.espAdfPath) true Access to ESP-IDF Path (idf.espIdfPath) true Access to ESP-MDF Path (idf.espMdfPath) false Access to ESP-Matter Path (idf.espMatterPath) false Access to ESP-IDF Custom extra paths Access to c:\RockyMountain\code.espressif\tools\xtensa-esp32-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32-elf\bin: true Access to c:\RockyMountain\code.espressif\tools\xtensa-esp32s2-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s2-elf\bin: true Access to c:\RockyMountain\code.espressif\tools\xtensa-esp32s3-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s3-elf\bin: true Access to c:\RockyMountain\code.espressif\tools\riscv32-esp-elf\esp-2021r2-patch3-8.4.0\riscv32-esp-elf\bin: true Access to c:\RockyMountain\code.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin: true Access to c:\RockyMountain\code.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin: true Access to c:\RockyMountain\code.espressif\tools\cmake\3.23.1\bin: true Access to c:\RockyMountain\code.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin: true Access to c:\RockyMountain\code.espressif\tools\ninja\1.10.2: true Access to c:\RockyMountain\code.espressif\tools\idf-exe\1.0.3: true Access to c:\RockyMountain\code.espressif\tools\ccache\4.3\ccache-4.3-windows-64: true Access to c:\RockyMountain\code.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64: true Access to Virtual env Python Path (idf.pythonBinPath) true Access to CMake in environment PATH undefined Access to Ninja in environment PATH undefined Access to ESP-IDF Tools Path (idf.toolsPath) true -------------------------------------------------------- Configurations has spaces ------------------------------------------------------------- Spaces in system environment Path true Spaces in ESP-ADF Path (idf.espAdfPath) false Spaces in ESP-IDF Path (idf.espIdfPath) false Spaces in ESP-MDF Path (idf.espMdfPath) false Spaces in ESP-Matter Path (idf.espMatterPath) false Spaces in ESP-IDF Custom extra paths Spaces in c:\RockyMountain\code.espressif\tools\xtensa-esp32-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32-elf\bin: false Spaces in c:\RockyMountain\code.espressif\tools\xtensa-esp32s2-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s2-elf\bin: false Spaces in c:\RockyMountain\code.espressif\tools\xtensa-esp32s3-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32s3-elf\bin: false Spaces in c:\RockyMountain\code.espressif\tools\riscv32-esp-elf\esp-2021r2-patch3-8.4.0\riscv32-esp-elf\bin: false Spaces in c:\RockyMountain\code.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin: false Spaces in c:\RockyMountain\code.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin: false Spaces in c:\RockyMountain\code.espressif\tools\cmake\3.23.1\bin: false Spaces in c:\RockyMountain\code.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin: false Spaces in c:\RockyMountain\code.espressif\tools\ninja\1.10.2: false Spaces in c:\RockyMountain\code.espressif\tools\idf-exe\1.0.3: false Spaces in c:\RockyMountain\code.espressif\tools\ccache\4.3\ccache-4.3-windows-64: false Spaces in c:\RockyMountain\code.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64: false Spaces in Virtual env Python Path (idf.pythonBinPath) false Spaces in ESP-IDF Tools Path (idf.toolsPath) false ----------------------------------------------------------- Executables Versions ----------------------------------------------------------- Git version undefined ESP-IDF version undefined Python version undefined Python's pip version undefined -------------------------------------------------- Python packages in idf.pythonBinPath ---------------------------------------------------- ---------------------------------------------------- Check ESP-IDF python requirements.txt ------------------------------------------------- Check ESP-IDF Python packages undefined ---------------------------------------------------- Check extension requirements.txt ------------------------------------------------------ Check Extension Python packages undefined ---------------------------------------------------- Check ESP-IDF debug adapter requirements.txt ------------------------------------------ Check Debug AdapterPython packages undefined ----------------------------------------------------------- Latest error ----------------------------------------------------------------- Latest error at Command failed: "c:\Users\jkull\Documents\DeviceSolutions\projects\RockyMountain\code.espressif\tools\idf-git\2.30.1\cmd\git.exe" --version The system cannot find the path specified.
Extension
esp-idf_doctor_command_output_20220826.txt esp32-lyrat_v4.3_debuglevel_3_flash_start_debug_reset_start_debug_again_log_20220826.txt
Description
I am new to Espressif and so I'm not very familiar with the device and the dev tools. I am sending this issue report because I would really like to get the JTAG debugger working consistently so that I can set breakpoints when testing my code.
I'm having issues when I start the debugging session after I flash the PICO32-LyraT v4.3 audio dev board. I am getting different results, depending on the debug session that I run, for example: 1, FreeRTOS.c:856 freertos_update_threads(): FreeRTOS maximum used priority is unreasonably big, not proceeding: 126
I've also tried the same steps on the ESP32-PICO-KIT board and I saw similar results.
I was expecting that I would be able to start debugging immediately after flashing the LyraT board and that it would work consistently.
Please advise on how to fix this.
Thank you.
Debug Message
Other Steps to Reproduce
In VSCode, I am running the Blink example from ESP-IDF examples folder.
Note that sometimes I also get a "FreeRTOS.c:893 freertos_update_threads(): Too large number of threads [large number here]!" but when I tried to capture it for this problem report, it somehow didn't show up.
I would try to start the debugging multiple times using the JTAG. I see different results depending on the debug session.
I have checked existing issues, online documentation and the Troubleshooting Guide