[ImHoTep]

Hi,

Thanks a lot for the quick fixes! I tested build 0.8.0.384. The Disassembly window now reappears in the right place next to the editor, and the sdkconfig.defaults crash is gone. However, part of my debug layout is still not restored correctly.

**My layout (screenshot 1):**
– Left: CPU Registers (active tab) and Peripheral Registers
– Middle: editor (SevenSegDriver.S, hello_world_main.c, GDB Session), with Disassembly split to the right
– Far right: a separate column with Watch (top), Memory (middle) and Locals (bottom)

**After restarting the debug session (screenshot 2):**
– Watch and Memory appear as tabs in the document area, next to the source files and GDB Session.
– Locals is docked at the bottom, below the editor and the Disassembly window, spanning their full width.
– The area on the right where the column used to be stays empty.
– On the left, VisualGDB Output is the active tab instead of CPU Registers.

**What I found in layout-debug.xml:**
– Watch and Memory are stored as <SplitStep xsi:type="Document" />.
– Locals is now stored as a DockSplit (this was a Document entry in my previous test, so that part improved), but it still ends up in the wrong place.
– Comparing the file before and after the session, only the open/closed state, tab indices and some sizes change. The positions of Watch and Memory are not updated.

So it looks like a column of tool windows docked to the right of the Disassembly split is still not handled correctly.

I also recorded a short video showing the whole process:
https://youtu.be/Rw-J_7AqHHI

May you should set the video quality manually to the highest setting (gear icon → Quality), as the automatic setting makes the text hard to read.

Best regards,
Thomas

Attachments:

You must be logged in to view attached files.

[ImHoTep]

Here are the attachments for my previous post (the forum didn’t accept them there):

– screenshot1_desired_layout.jpg: the layout I set up in the first debug session
– screenshot2_after_restart.jpg: the layout after restarting the debug session
– layout-debug-gewuenscht.txt: copy of layout-debug.xml saved right after the first session
– layout-debug-after-restart.txt: layout-debug.xml after the second session

I had to rename the XML files to .txt because the forum doesn’t allow .xml uploads. The content is unchanged.

Best regards,
Thomas

Attachments:

You must be logged in to view attached files.

[ImHoTep]

Hi,

Thanks a lot for the detailed explanation and the link to the development build! I installed CodeVROOM 0.8.0.375 and went through the steps you suggested. Here are my findings.

**Setup:** ESP32 (WROOM-32E), ESP-IDF 6.1, debugging via ESP-Prog (OpenOCD).

**Steps:**
1. Started a debug session and arranged the windows the way I want them (screenshot 1): VisualGDB Output and Peripheral Registers on the left, editor in the middle, Disassembly as a separate pane to the right of the editor, and Watch and Locals stacked on top of each other in a separate column on the far right.
2. Stopped the session and made a copy of layout-debug.xml (attached as layout-debug_-_gewuenscht.xml).
3. Started the session again (screenshot 2) and saved the resulting layout-debug.xml (attached).

**Result:** The windows on the left and at the bottom are restored correctly. However, the whole right-hand part of the layout is lost:
– The **Disassembly** window is gone completely.
– **Watch** and **Locals** are no longer docked on the right, but appear as tabs in the document area next to the source files.

**What I found in the XML files:** It looks like the problem already happens when the layout is *saved*, not when it is loaded:
– In the copy taken right after the first session, Watch and Locals are already stored as <SplitStep xsi:type="Document" /> instead of a dock split on the right.
– There is no record for the Disassembly window at all (the file contains 16 window types, including Watch, Locals, CPURegisters, CallStack, PeripheralRegisters and Timeline, but no Disassembly).
– Apart from that, the two files only differ in the splitter proportions and in which tab is active, so the rest of the layout is saved and restored correctly.

The Diagnostic Console did not show any errors related to the layout.

**Two other things I noticed:**

1. Saving the project properties crashes with a FileNotFoundException if the project has no sdkconfig.defaults file. This happens with the ESP-IDF “hello_world” example, which doesn’t contain that file, but not with “blink”, which does. Creating an empty sdkconfig.defaults works around it. Stack trace:
`
System.IO.FileNotFoundException: Die Datei “D:\source\repos\ESP\ESP32\ESPIDFProject1\sdkconfig.defaults” konnte nicht gefunden werden.
at System.IO.File.InternalReadAllLines(String path, Encoding encoding)
at dcz1.y6y1()
…
at VisualGDB.Common_GUI.Configuration_editors.ProjectPropertiesEditModel.ivw2(…)
at j911.Save()
`

2. During one debug session, the Diagnostic Console showed this message (it did not appear in a later session):
`
failed to load the embedded memory list from the linker script file: System.IO.FileNotFoundException: Missing VisualGDB.Backend.Subsystems.LinkerScriptInfo
`

Otherwise, debugging works really well, and the new Debug Timeline looks very promising. Let me know if you need any further information or tests.

Best regards,
Thomas

[ImHoTep]

Hi,

I’ve been using VisualGDB for quite a while, and in my opinion it is by far the best IDE for the ESP32 family. For other hardware I usually stick to the vendors’ own tools (STM32CubeIDE, Keil, MPLAB X), so I can’t really judge VisualGDB there.

I think the idea behind CodeVROOM is excellent. It has the potential to become the perfect solution for professional coding and especially debugging on ESP32 devices. I gave it a try and was able to create, flash and debug an ESP32 project out of the box, without any hassle. I’m not aware of any other IDE that offers this level of quality without a lengthy installation and configuration process.

One thing I noticed, though: CodeVROOM apparently reused my existing VisualGDB/ESP-IDF installation, since nothing had to be installed. This makes me wonder what the experience looks like on a clean machine without VisualGDB and ESP-IDF. How are the toolchains and tools installed and configured in that case?

This is of particular interest to me because I’m planning to make a YouTube video about CodeVROOM, and I would like to at least mention how the tools get installed. Any information on how the tool installation works on a fresh system would be very helpful.

One drawback I ran into during my first tests: the debugging layout is not preserved. When I arrange the tool windows the way I want them during a debug session (which windows are open and where they are placed), this setup is lost once the session ends. After restarting the debugger, I have to set everything up again from scratch. For daily debugging work this is a significant limitation. Is there a way to save the debug layout, or is this planned for a future version?

I’m going to test CodeVROOM with other ESP32 variants over the next few days and will report back.

Keep up the great work!

Best regards,
Thomas

[ImHoTep]

I also believe that Rust is the future of embedded development. I currently use it on the ESP32‑xx platform with CLion; however, compared to VisualGDB, CLion is extremely poor in terms of usability, visual clarity, and configuration. In the embedded domain, it delivers virtually nothing out of the box, making it feel like a regression to the early days of IDEs.

[ImHoTep]

Sorry, I could’ not upload the script here.
Go:
https://mindmake.de/dl/visualgdb/

 

[ImHoTep]

Hello Sysprogs team,

Thank you very much for reproducing the problem and for the detailed explanation, that helps a lot.

Since my VisualGDB 6.1 setup is working reliably for my ESP-IDF projects, I would prefer not to replace it with a development build. I will wait for a stable release of VisualGDB 6.2 (and CodeVROOM) and will be happy to test the new Arduino core support then.

In the meantime, I found a workaround that works well with VisualGDB 6.1, and I’d like to share it in case it is useful for you or other users. I use the Arduino core as an ESP-IDF component in a regular VisualGDB ESP-IDF project:

– ESP-IDF 6.1.0, ESP32 (Consolidated) toolchain
– espressif/arduino-esp32 4.0.0-rc1 from the ESP Component Registry (based on ESP-IDF 6.1)
– Tested on ESP32 (FTDI JTAG) and ESP32-S3 (built-in USB-JTAG): build, flash, breakpoints, stepping and terminal all work.

Changes required on a freshly generated project:

1. main/idf_component.yml: dependency espressif/arduino-esp32: “4.0.0-rc1”
2. sdkconfig: CONFIG_FREERTOS_HZ=1000
3. sdkconfig: CONFIG_MBEDTLS_PSK_MODES=y and CONFIG_MBEDTLS_KEY_EXCHANGE_PSK=y (required by NetworkClientSecure)
4. Top-level CMakeLists.txt, before project(): idf_build_set_property(COMPILE_OPTIONS “-Wno-error=missing-field-initializers” APPEND) (ESP_I2S.cpp in the RC1 vs. new fields in i2s_chan_config_t)
5. Top-level CMakeLists.txt, after project(): -Wno-error=cpp for the Arduino component only (on ESP32-S3, ESP_SR emits a #warning about the partition table):
idf_component_get_property(arduino_lib espressif__arduino-esp32 COMPONENT_LIB)
target_compile_options(${arduino_lib} PRIVATE -Wno-error=cpp)
6. Main source converted to .cpp, app_main declared extern “C” and calling initArduino().
7. Advanced GDB Settings: “Use file names only when setting breakpoints” (UseRelativePathsOnly) enabled.

I have automated all of these steps in a small Python script (attached, standard library only). Usage:

1. Create a new ESP-IDF project with the VisualGDB wizard and let it configure once.
2. Unload the project in Visual Studio.
3. Copy idf_arduino_setup.py into the project root (next to sdkconfig and the .vgdbproj file) and run it (double-click or “python idf_arduino_setup.py”).
4. Reload the project and build. The first build downloads the Arduino core.

The script creates .bak backups of all modified files and can safely be run multiple times.

Two observations that might be worth checking in 6.2, since your reply only covered the GDB path:

– With “Program FLASH using: OpenOCD”, the Arduino project type failed with a KeyNotFoundException in ESP32StartupSequence.BuildFLASHImages (core 3.3.12, ESP32 Dev Module).
– Point 7 above: without this option, Visual Studio froze or crashed and restarted itself as soon as the target stopped at a breakpoint. The GDB log ended in the middle of the response to -file-list-exec-source-files. With the Arduino core and its dependencies, this source file list becomes very large. This might also affect the Arduino project type in 6.2.

Thank you again for your support.

Best regards,
Thomas

[ImHoTep]

So I got it.., I was able to get the ESP32-S31 listed as an available device by downloading the ESP-IDF 6.1 checkout via “Download another IDF/ADF checkout”. Unfortunately, debugging does not work, because VisualGDB cannot find an esp32s31.cfg file for the debug configuration. Is there a solution for this?

[ImHoTep]

Sorry there was a typo in my Post, I’m using IDF 6.1

[ImHoTep]

Thaks.

It works with the Debug settings “OpenOCD “and  the “esp32-bridge.cfg”

[ImHoTep]

Thanks for the fast reply and help. That works!

This was likely the same reason why the try to integrate the Arduino framework as a component failed. I will test this further…

[Author]

Posts