Update espressif chips

[erhankur]

Below commits cherry picked from the upstream.

c07c91a14 tcl/board: add esp32s3-builtin.cfg file
c5a48f9ed tcl/interface: add Espressif builtin usb_jtag config file.
be5f326e0 tcl/target: update esp32s3.cfg to reference shared functions in the esp_common.cfg
e5e44d0f6 tcl/target: update esp32s2.cfg to reference shared functions in the esp_common.cfg
5a458e7d4 tcl/target: update esp32.cfg to reference shared functions in the esp_common.cfg
5a615ad10 tcl/target: move Espressif shared functions to esp_common.cfg

Based on these commits, esp32c3 and esp32c2 are updated.
Additionally, related to new Espressif riscv chip config files are added. ( esp32c6 and esp32h2)

[timsifive]

tcl changes are all fine by me.

Is the libjaylink update on purpose?

[erhankur]

tcl changes are all fine by me.

Is the libjaylink update on purpose?

No, by mistake. Fixed. Thanks for the review.

[psherman42]

@erhankur @timsifive Two questions: First, in procedure riscv_soc_reset() at line 46 of tcl/target/esp32c6.cfg shouldn't dmactive be set back to '1'? I think this line is missing the following command: riscv dmi_write $_RISCV_DMCONTROL 0x80000001.

Second, after line 69 shouldn't there either be a very long delay (i.e., sleep 3000) or dmcontrol.ndmreset be set back to '0', or both?

Also, the LP_CPU (hart 1) of ESP32-C6 seems to be always dmstatus.unavail=3 even though it shows dmstatus.nonexistent=0 (i.e., present). In other words, it appears not to be in a halted state. Attempting to execute an abstract command when dmcontrol.hartsel=1 always gives abstractcs.cmderr=4 (i.e., unavailable). The HP_CPU (hart 0) operates fine in all regards. Both harts/cores should be of RV32IMAC architecture. Is there some special procedure for selecting and debugging hart 1 on this device?

[erhankur]

@psherman42 some of the actions taken there to adapt the silicon behavior. We will have a clear reset function with the upcoming chip revisions.

[psherman42]

Thanks @erhankur

Also, the LP_CPU (hart 1) of ESP32-C6 seems to be always dmstatus.unavail=3 even though it shows dmstatus.nonexistent=0 (i.e., present). In other words, it appears not to be in a halted state.

Resolved. Section 3.4.2 of the esp32-c6_technical_reference_manual says

By default, the LP CPU is in the unavail state. To connect the LP CPU for debugging, users need to clear the state by configuring the LPPERI_CPU_REG register.

Therefore, must set LPPERI_CPU_REG.LPPERI_LPCORE_DBGM_UNAVAILABLE = 0
in other words
riscv dmi_write $_RISCV_SB_ADDRESS0 0x600b280c
riscv dmi_write $_RISCV_SB_DATA0 0x00000000

Attempting to execute an abstract command when dmcontrol.hartsel=1 always gives abstractcs.cmderr=4 (i.e., unavailable).

Still a problem. Not sure how to get LP CPU (core 1) into halted state. It appears to be always running even after specifying dmcontrol.haltreq = 1.

[erhankur]

LP core debugging is something we didn't adapt to the OpenOCD yet. Normally when ulp_lp_core_run() function is called by the HP core, JTAG debugging will be enabled for the LP core. https://github.com/espressif/esp-idf/blob/master/components/ulp/lp_core/lp_core.c#L86

We will test it and let you know the instructions to halt LP core.

[gerekon]

@psherman42 I checked how halt command works from telnet session.
I used master branch from our repo https://github.com/espressif/openocd-esp32.
Currently it does not support debugging LP core of ESP32-C6, so I have to hack config files a bit to expose one TAP for esp32c6 target in SMP mode which effectively makes use of multi-core RISCV DM feature.
Below statement is from esp32c6 spec:
"DM supports multi-core debugging in compliance with the specification RISC-V External Debug Support Version
0.13, and can control the HP CPU and the LP CPU simultaneously. Hart 1 represents the LP CPU. Users can
use OpenOCD to select a hart (0: HP CPU, 1: LP CPU) for debugging."

My OpenOCD telnet session:

> targets
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  esp32c6.cpu0       esp32c6    little esp32c6.cpu0       running
 1* esp32c6.cpu1       esp32c6    little esp32c6.cpu0       running
> halt
> targets
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  esp32c6.cpu0       esp32c6    little esp32c6.cpu0       halted
 1* esp32c6.cpu1       esp32c6    little esp32c6.cpu0       halted

Log related to halt command:

Debug: 484 12115 command.c:153 script_debug(): command - halt
Debug: 485 12115 target.c:3248 handle_halt_command(): -
Debug: 486 12115 riscv.c:1922 riscv_halt(): [esp32c6.cpu1] halting all harts
Debug: 487 12115 riscv.c:1854 halt_prep(): [esp32c6.cpu0] prep hart, debug_reason=5
Debug: 488 12115 riscv.c:1854 halt_prep(): [esp32c6.cpu1] prep hart, debug_reason=5
Debug: 489 12117 riscv-013.c:4896 select_prepped_harts(): [esp32c6.cpu0] index=1, prepped=1
Debug: 490 12117 riscv-013.c:4896 select_prepped_harts(): [esp32c6.cpu0] index=0, prepped=1
Debug: 491 12118 riscv-013.c:4950 riscv013_halt_go(): [esp32c6.cpu0] halting hart
Debug: 492 12123 riscv.c:5073 riscv_invalidate_register_cache(): [esp32c6.cpu0] Invalidating register cache.
Debug: 493 12123 target.c:1779 target_call_event_callbacks(): target event 0 (gdb-halt) for core esp32c6.cpu0
Debug: 494 12123 target.c:1779 target_call_event_callbacks(): target event 1 (halted) for core esp32c6.cpu0
...
Debug: 666 12146 command.c:153 script_debug(): command - esp halted_event_handler
Debug: 667 12146 riscv.c:5280 riscv_get_register(): [esp32c6.cpu0] Reading mcause from target
Debug: 668 12146 riscv-013.c:4825 riscv013_get_register(): [esp32c6.cpu0] reading register mcause
Debug: 669 12146 riscv-013.c:1698 register_read_direct(): [esp32c6.cpu0] Reading mcause
Debug: 670 12146 riscv-013.c:888 execute_abstract_command(): [esp32c6.cpu0] access register=0x220342 {regno=0x342 write=arg0 transfer=enabled postexec=disabled aarpostincrement=disabled aarsize=32bit}
Debug: 671 12146 riscv-013.c:1717 register_read_direct(): [esp32c6.cpu0] mcause = 0x8000000b
Debug: 672 12147 riscv.c:5288 riscv_get_register(): [esp32c6.cpu0] Read mcause: 0x8000000b
Debug: 673 12147 esp_riscv.c:143 esp_riscv_print_exception_reason(): [esp32c6.cpu0] mcause=8000000b
Debug: 674 12147 target.c:1779 target_call_event_callbacks(): target event 0 (gdb-halt) for core esp32c6.cpu1
Debug: 675 12147 target.c:1779 target_call_event_callbacks(): target event 1 (halted) for core esp32c6.cpu1

So I'd start with checking:

1. What openocd repo/branch do you use?
2. What config files do you use? What is OpenOCD command line?
3. Could you post log file?

[gerekon]

@psherman42
One more question...
4. What app is running on ESP32-C6? What does it do?

[psherman42]

@gerekon
I see you are doing an ECALL. At what point do you invoke that abstract command? Not sure how you do it on hart id 1, because it hasn't been halted yet.

Bigger question: What is the precise sequence of setting the various necessary control bits? I refer to the ulp_lp_core_halt() function, and its notes in issue 12651 and lp_core_utils.c

Nowhere yet documented in the ESP32-C6 Technical Reference Manual (ESP32-C6 TRM v0.3) is register
LP_AON (0x600b 1000)
I am unsure in which sequence to manipulate
LP_AON_LPCORE_ETM_WAKEUP_FLAG_CLR (0x600b 1050 [0])

I am also having great difficulty understanding
PMU_LP_CPU_SLEEP_REQ (0x600b 0180 [31])
and
PMU_HP_SW_TRIGGER_INT_CLR (0x600b 0178 [31])

Nothing I do seems to get hartsel=1 out of its dmstatus.running state.

Please advise, and highlight a bit more of the log, especially necessary setup and initialization conditions for the LP Core. Thanks.

I refer to documentation in reg-base.h and lp_aon_ll.h for memory map and peripheral details, to fill in the blanks of the ESP32-C6 Technical Reference Manual.

[gerekon]

@psherman42

Bigger question: What is the precise sequence of setting the various necessary control bits? I refer to the ulp_lp_core_halt()

Setting various bits for what? As far as I understand ulp_lp_core_halt puts LP core into sleep mode, it is not about halting it from debugger's perspective.

Sorry I can not understand what you are doing and what you want to achieve. W/o that info it is hard to help.
Are you trying to debug LP Core using OpenOCD? As I said it is not supported yet. It is on our TODO list. So we can not provide you with fully working solution for this right now. We will start looking at this soon, but it can take time.

Meanwhile I can say that there can be problems to debug ESP32-C6 when HP core goes into sleep mode. We are investigating this, maybe it is HW problem. That why I asked you about the program you try to debug.

I asked you several questions, but till now have not got any answers. Could you describe what you do step-by-step?
Does not halt command works at you side? I did my experiments mentioned above with master branch of https://github.com/espressif/openocd-esp32 and with example https://github.com/espressif/esp-idf/tree/5454d37d496a8c58542eb450467471404c606501/examples/system/ulp/lp_core/gpio. But I have to comment the line putting HP core into sleep mode.

-    esp_deep_sleep_start();
+    //esp_deep_sleep_start();
+    while(1) {
+        vTaskDelay(pdMS_TO_TICKS(1000));
+    }

Could you try it?

[gerekon]

I see you are doing an ECALL. At what point do you invoke that abstract command? Not sure how you do it on hart id 1, because it hasn't been halted yet.

What ECALL you are talking about?

[gerekon]

@psherman42

Here is the branch with OpenOCD config files changes gerekon/openocd-esp32@e82f2c9 I used to halt targets via Telnet session. If you need