[ESP32H2] IDF v5.1 Monitor: Input on app console causes monitor to freeze (IDFGH-10666)

[heliochronix]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm running an Arch system with kernel 6.4.3, and I have the latest release/v5.1 branch pulled (as of this posting). I'm having an issue with the IDF Monitor when talking to an ESP32-H2 board running a console app.

During the get-started/hello_world or get-started/blink program, output from the monitor is normal, though input on the keyboard seems to cause it to hang up for a bit before it resumes outputting stuff from the target. This is apparently expected behavior for non-console apps.

However, if I try to run something like openthread/ot_cli that has a console, it will output fine at first but any keyboard input seems to freeze things up, to the point I can't even use CTRL-] or CTRL-T CTRL-X to exit the console and I'm forced to manually kill the python process. I can still get CTRL-T CTRL-H to output help text, but resetting, quitting, and rebuilding/flashing the target all seem to do nothing, and all output from the target stops. The only way to get it back seems to be killing the monitor python process and restarting it, which causes the reset to trigger.

Any help in troubleshooting this would be appreciated! I'm relatively new, so apologies if I've missed some common troubleshooting steps.

[dobairoland]

Duplicate report here: https://esp32.com/viewtopic.php?f=13&t=34673

[heliochronix]

Duplicate report here: https://esp32.com/viewtopic.php?f=13&t=34673

Apologies, I made that post first but then decided I'd rather have a GH issue to track this, plus I was able to add more details here.

[peterdragun]

Hi, are you using the native USB port of ESP32H2? Can you see the same behavior when using the UART port (if available)? Have you tried setting 'Channel for console output' to USB Serial? - You can do it with the menuconfig command under 'Component config > ESP System Settings > Channel for console output'

[heliochronix]

Hi, are you using the native USB port of ESP32H2? Can you see the same behavior when using the UART port (if available)? Have you tried setting 'Channel for console output' to USB Serial? - You can do it with the menuconfig command under 'Component config > ESP System Settings > Channel for console output'

Yes, this is the native USB-C port on the ESP32-H2-DevKitM-1, not the UART port. I will try connecting up the UART to see if it reacts the same. I will double check menuconfig as well, though the output looks correct. I even get the > prompt and other periodic messages printing out. It's just input that seems to be freezing it all up.

[igrr]

@heliochronix Could you please also try examples/system/console/basic with the setting mentioned by @peterdragun above (CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG)? That example definitely works over USB_SERIAL_JTAG when that option is enabled.

[heliochronix]

@heliochronix Could you please also try examples/system/console/basic with the setting mentioned by @peterdragun above (CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG)? That example definitely works over USB_SERIAL_JTAG when that option is enabled.

Sure, I just need to figure out how to disable the various wifi subsystems as this board does not have wifi, and it's preventing it from building.

Edit: And apparently the sleep subsystems, as that is not yet available on the H2

[igrr]

My bad, I forgot that we haven't backported bb3f1fd to release/v5.1 yet.

Please try to git cherry-pick bb3f1fd2619d9344e7ceda4fced7abc41231a198, it should apply cleanly on release/v5.1.

[heliochronix]

It didn't exactly apply cleanly, but I did resolve the conflict. Also there appears to be a typo in get_version where it checks for CHIP_ESP32H4 and sets model = "ESP32-H4" (resulting in a build error because CHIP_ESP32H4 doesn't exist) instead of CHIP_ESP32H2 and setting model = "ESP32-H2". I fixed this as well locally.

As for the results of the test, the behavior is identical. It outputs everything, but I can't type anything and CTRL-] doesn't work, along with CTRL-T and any subsequent commands except for the help text.

Example output:

➜ idf.py -p /dev/ttyACM0 monitor
/home/username/Projects/esp-idf/tools/check_python_dependencies.py:12: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  import pkg_resources
Executing action: monitor
Running idf_monitor in directory /home/username/Projects/esp32h2/basic
Executing "/home/username/.espressif/python_env/idf5.1_py3.11_env/bin/python /home/username/Projects/esp-idf/tools/idf_monitor.py -p /dev/ttyACM0 -b 115200 --toolchain-prefix riscv32-esp-elf- --target esp32h2 --decode-panic backtrace /home/username/Projects/esp32h2/basic/build/console.elf -m '/home/username/.espressif/python_env/idf5.1_py3.11_env/bin/python' '/home/username/Projects/esp-idf/tools/idf.py' '-p' '/dev/ttyACM0'"...
--- idf_monitor on /dev/ttyACM0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ESP-ROM:esp32h2-20221101
Build:Nov  1 2022
rst:0x15 (USB_UART_HPSYS),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x40802e74
0x40802e74: rv_utils_wait_for_intr at /home/username/Projects/esp-idf/components/riscv/include/riscv/rv_utils.h:33
 (inlined by) esp_cpu_wait_for_intr at /home/username/Projects/esp-idf/components/esp_hw_support/cpu.c:119

SPIWP:0xee
mode:DIO, clock div:1
load:0x4083cfd0,len:0xa14
load:0x4083efd0,len:0x2ab8
load:0x408460e0,len:0x1278
entry 0x4083cfd0
I (92) cpu_start: Unicore app
I (92) cpu_start: Pro cpu up.
W (101) clk: esp_perip_clk_init() has not been implemented yet
I (108) cpu_start: Pro cpu start user code
I (108) cpu_start: cpu freq: 96000000 Hz
I (109) cpu_start: Application information:
I (111) cpu_start: Project name:     console
I (116) cpu_start: App version:      1
I (120) cpu_start: Compile time:     Jul 18 2023 08:52:41
I (126) cpu_start: ELF file SHA256:  1b178c1458b9eb6a...
I (132) cpu_start: ESP-IDF:          v5.1-231-ga7b62bbcaf-dirty
I (139) cpu_start: Min chip rev:     v0.0
I (144) cpu_start: Max chip rev:     v0.99
I (148) cpu_start: Chip rev:         v0.1
I (153) heap_init: Initializing. RAM available for dynamic allocation:
I (160) heap_init: At 4080C810 len 00040B70 (258 KiB): D/IRAM
I (167) heap_init: At 4084D380 len 00002B60 (10 KiB): STACK/DIRAM
I (175) spi_flash: detected chip: generic
I (178) spi_flash: flash io: dio
I (183) app_start: Starting scheduler on CPU0
I (187) main_task: Started on CPU0
I (187) main_task: Calling app_main()
I (197) example: Command history enabled

Type 'help' to get the list of commands.
Use UP/DOWN arrows to navigate through command history.
Press TAB when typing command name to auto-complete.

Your terminal application does not support escape sequences.

Line editing and history features are disabled.

On Windows, try using Putty instead.
esp32h2> I (707) main_task: Returned from app_main()

[heliochronix]

Following up on the other testing, connecting up to the UART directly seems to work. It's seemingly just USB Serial/JTAG that is causing issues on the monitor.

[igrr]

In the case of examples/system/console/basic, could you please confirm that you have CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG=y in the sdkconfig file?

[heliochronix]

In the case of examples/system/console/basic, could you please confirm that you have CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG=y in the sdkconfig file?

Setting this does result in a functional USB Serial/JTAG interface. This is good to know! When I tested this on the other app I was still having issues. Let me double check that though...

[igrr]

When I tested this on the other app I was still having issues. Let me double check that though...

As far as I can tell, openthread/ot_cli example, unlike system/console/basic, doesn't implement console support via USB_SERIAL_JTAG, there is only UART support. (cc @chshu)

The reason why you still see output on USB_SERIAL_JTAG is that by default, CONFIG_ESP_CONSOLE_SECONDARY_USB_SERIAL_JTAG is enabled on ESP32-H2. This forwards stdout and stderr to USB_SERIAL_JTAG, in addition to UART. That secondary channel is output-only, however.

[heliochronix]

Ah, that must be what happened... Okay thank you, this clarifies things greatly.

[chshu]

@heliochronix You may follow this #11924 (comment) to enable USB port for ot_cli example.