Closed mbrunnen closed 2 years ago
mbrunnen
commented
2 years ago The error disappeared, when I changed gdbinit from
mon esp sysview start file:///tmp/heap_log.svdat
to
mon esp sysview start file:///tmp/heap_log.cpu0.svdat file:///tmp/heap_log.cpu1.svdat
But I still can't start and analyse it within the vscode extension.
radurentea
commented
2 years ago Hi @mbrunnen,
Thank you for the report!
I've looked into it and fixed the issue on my local, however, there is another issue regarding heap tracing coming from the ESP-IDF, which will be fixed with the ESP-IDF 5.1 release. Until the release there is no workaround I'm afraid for the ESP32-S3 chip.
mbrunnen
commented
2 years ago Hi @radurentea, these are good news, thank you! Do you have a reference for the issue in IDF?
radurentea
commented
2 years ago Hi @mbrunnen,
So it seems that the fix for the issue I've mentioned is already out if you are using the master version of IDF. However, I still had issues with S3 tracing. There is someone already looking into it and when I will have more info I will come back to you.
This is the commit I was mentioning before on IDF v 5.1:
Regarding the modification needed on the VSCode Extension, I've created this PR
mbrunnen
commented
2 years ago Hi @radurentea, thank you for that information! Unfortunately this commit seems to be released in v5.1:
github-actions[bot]
commented
2 years ago This issue has been marked as stale since there are no activities, and this will be closed in 5 days if there are no further activities
mickeyl
commented
8 months ago May I ask about the current status here? I tried with ESP-IDF 5.2.1 and the latest version of the extension (1.7.1 as of today) and it doesn't work here. My example hangs on the ESP32S3 in heap_trace_start() and does not continue.
OpenOCD debugging in general works though.
0xjmux
commented
7 months ago I'm also interested in the status of this.
I was able to get the program to execute (nominally) by modifying gdbinit like mbrunned mentioned in this reply.
GDB Log:
xtensa-esp32-elf-gdb -x gdbinit build/sysview_tracing_heap_log.elf
GNU gdb (esp-gdb) 12.1_20231023
...
Reading symbols from build/sysview_tracing_heap_log.elf...
0x4037a416 in esp_cpu_wait_for_intr () at /home/jmux/Documents/esp/v5.2.1/esp-idf/components/esp_hw_support/cpu.c:145
145 }
JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
[esp32s3.cpu0] requesting target halt and executing a soft reset
[esp32s3.cpu0] Debug controller was reset.
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
[esp32s3.cpu1] requesting target halt and executing a soft reset
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
Temporary breakpoint 1 at 0x42006040: file /home/jmux/Documents/esp/v5.2.1/esp-idf/components/app_trace/heap_trace_tohost.c, line 36.
Note: automatically using hardware breakpoints for read-only addresses.
Temporary breakpoint 2 at 0x42006058: file /home/jmux/Documents/esp/v5.2.1/esp-idf/components/app_trace/heap_trace_tohost.c, line 48.
[esp32s3.cpu0] Target halted, PC=0x42006040, debug_reason=00000001
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000
[New Thread 1070178928]
[New Thread 1070182088]
[New Thread 1070174276]
[Switching to Thread 1070178928]
Thread 2 "main" hit Temporary breakpoint 1, heap_trace_start (mode_param=(HEAP_TRACE_LEAKS | unknown: 0x2)) at /home/jmux/Documents/esp/v5.2.1/esp-idf/components/app_trace/heap_trace_tohost.c:36
36 {
Total trace memory: 16384 bytes
Open file /tmp/heap_log.cpu0.svdat
Open file /tmp/heap_log.cpu1.svdat
App trace params: from 2 cores, size 4294967295 bytes, stop_tmo -1 s, poll period 0 ms, wait_rst 0, skip 0 bytes
Connect targets...
Targets connected.
[esp32s3.cpu0] Target halted, PC=0x42006058, debug_reason=00000001
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000
[New Thread 1070197012]
[New Thread 1070191164]
[New Thread 1070185316]
[New Thread 1070199984]
[New Thread 1070194136]
[New Thread 1070188288]
Thread 2 "main" hit Temporary breakpoint 2, heap_trace_stop () at /home/jmux/Documents/esp/v5.2.1/esp-idf/components/app_trace/heap_trace_tohost.c:48
48 {
Resume targets
16500
16753
16996
17072
Disconnect targets...
[esp32s3.cpu0] Target halted, PC=0x4038046F, debug_reason=00000000
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40043A40, debug_reason=00000000
Targets disconnected.
Tracing is STOPPED. Size is 17072 of -1 @ 76.483856 (73.379166) KiB/s
Data: blocks incomplete 0, lost bytes: 0
Block read time [126.265007..126.265007] ms
Block proc time [0.082000..0.082000] ms
(gdb)Following along with the steps in the example, I then open it in Systemview - but when opening either heap log in Systemview the program hangs and refuses to read it.
I have two questions:
SYSVIEW_FreeRTOS.txt to /opt/SEGGER/SystemView_vX, but it didn't help; the heap log being produced seems to be incompatible with Systemview, but all of Segger's examples load fine on my machine. Thanks.
OS
Linux
Operating System version
Debian GNU/Linux 11 (bullseye)
Visual Studio Code version
1.70.2
ESP-IDF version
4.4.2
Python version
3.9.2
Doctor command output
Extension
Description
I could not run the example
system/sysview_tracing_heap_logas described in https://github.com/espressif/vscode-esp-idf-extension/blob/master/docs/tutorial/heap_tracing.md.The only change I have made, is to use the ESP32S3, hence I added a file
sdkconfig.defaults.esp32s3with the content:CONFIG_HEAP_TRACING_STACK_DEPTH=10After I press "Start Heap Trace", I get an openocd error, but the UI-Symbol suggests, that the tracing is running. When I stop, I do not have any trace archive.
Debug Message
Other Steps to Reproduce
No response
I have checked existing issues, online documentation and the Troubleshooting Guide