Keep up the great work!

[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

[support]

Hi,

Thanks for the kind words and the feedback!

Both CodeVROOM and VisualGDB 6.1+ actually try to follow the ESP-IDF tool layout used by Espressif’s own tool installer. If you used Espressif’s VS Code extension on that computer, both VisualGDB and CodeVROOM will detect the tools installed by it, and if it’s a completely clean installation, they will download and install the tools, trying to follow the same directory structure as the original installer would do. You can check this tutorial – it shows the steps from the first run on a clean Linux machine to debugging a basic ESP32 project.

You can see the tools detected/installed by CodeVROOM via the link at the bottom of the ESP-IDF checkout selector (see attached file).

With the layout, it should normally be saved. There are actually 2 different mechanisms for the window layout:

• The full layout is saved to <workspace>\.sysprogside\<project name>\layout.xml and layout-debug.xml files with separate layouts for design and debug mode.
• The last used window locations are saved to %LOCALAPPDATA%\CodeVROOM\ToolWindowLocations.xml. So, if you move the Threads window from the bottom dock to the top dock in project A, and then open it for the first time in project B, it will remember the preferred position.

Based on what you are describing, something is interfering with the layout saving logic. We would appreciate it if you could try the following steps:

1. Open View->Diagnostic Windows->Diagnostic Console.
2. Try starting the debug session and opening one extra tool window.
3. Try stopping the debug session immediately.
4. Did the layout-debug.xml file get created under the .sysprogside directory? If not, are there any error messages in the diagnostic window?
5. If the file did get created, try making a copy of the file and starting the session again. This time, try opening another window and stopping the session. Is there anything different about the layout file?

You can also try the latest development build here: CodeVROOM-0.8.0.375.exe. It fixes a few glitches from v0.7, and introduces the new Debug Timeline window, that records all the debug stops together with the variables evaluated during them, and allows rigging breakpoints to record relevant data & immediately continue.

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]

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.

[support]

OK, thanks again for the feedback. The double set of docked tool windows on the left, and the disassembly window docked on the right triggered quite a few glitches. The good news is that we managed to fix them all:

• You can now have any number of docked tool windows on either side, and any combination of vertical/horizontal document splits. All this is correctly switched between build/debug views – the document layout is preserved, while the tool window layouts are switched out.
• The disassembly window now remembers if it was split vertically or horizontally from the main source, and will re-appear in the same location next time (per-workspace).
• Disassembly window also remembers whether it was active at the end of the last session, so it will reopen automatically next time.

We also fixed the sdkconfig saving bug, a bug where the disassembly view wasn’t properly centered around the current instruction, and enabled recording of the disassembled instructions in the timeline. Feel free to try this build: CodeVROOM-0.8.0.384.exe

That said, the timeline will unleash its full potential when AI is properly integrated into it. The current models don’t seem to be smart enough to fix tricky bugs on their own, but they can do a lot of legwork for collecting data. Like stepping through 20 different functions to track down where some weird value came from, and then giving you a report with clickable links to the relevant debug steps… But this is still a couple of weeks away.

Attachments:

You must be logged in to view attached files.

[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.

[support]

Hi,

This is a different issue. On this layout, the windows on the right side are not docked, but are a part of the regular document area. Note the different header styles on attached docks.png. The docked headers (red) are on the left, and document headers (green) are on the right.

So, the behavior is by design. The docked windows (red) are supposed to be persistent, while the documents are expected to change from session to session. The layout shown on the screenshot happened because at some earlier point (prior to the video) you dragged the Watch window into the main document area, as a regular document tab (see attached watch.png), changing its style from tool window to a docked document.

You can undo it by dragging it over any of the docked windows (e.g. Peripheral Registers). It will get switched back into a tool window, so if you drag it to the side of the document area now, it will have a different header style, and will remember the location. Alternatively, you can just use the Reset Window Layout command to force all tool windows to side docks, and rearrange them from there.

 

Attachments:

You must be logged in to view attached files.

[ImHoTep]

Hi,

Thanks for the explanation, that makes sense! I hadn’t noticed the difference between docked tool windows and the document area.

I tried to follow your suggestion and use Reset Window Layout during a debug session, but CodeVROOM 0.8.0.384 shows an error instead (“Failed to compare two elements in the array”). The cause seems to be a NullReferenceException in DockableObjectLocation.CompareLocationsForApplyingOrder. My guess is that it’s related to the Watch/Memory windows that currently live in the document area and therefore have no dock location.

`
System.Reflection.TargetInvocationException —> System.InvalidOperationException: Failed to compare two elements in the array. —> System.NullReferenceException: Object reference not set to an instance of an object.
at Sysprogs.DockingFramework.DockableObjectLocation.CompareLocationsForApplyingOrder(DockableObjectLocation a1, DockableObjectLocation a2)
at System.Array.FunctorComparer`1.Compare(T x, T y)
at System.Collections.Generic.ArraySortHelper`1.InsertionSort(…)
at System.Collections.Generic.ArraySortHelper`1.Sort(…)
at System.Collections.Generic.List1.Sort(Comparison1 comparison)
at ulv1.u44(Func`2 a2)
at drb.gu82(ISystematicCommandTarget a2, z7m2 a3, Boolean a4)
at q811.ptb2(drb a2)
trace=[…DockableObjectLocation.CompareLocationsForApplyingOrder:223, …]
`

In the meantime I’ll try the other approach you suggested and drag the Watch and Memory windows back onto a docked tool window.

Best regards,
Thomas

[support]

No problem and sorry about the comparison error. It should be already fixed in the latest version. Feel free to try this build: CodeVROOM-0.8.0.391.exe.

It also has partial support for analyzing debug timeline with AI. You can now use the “Debug with AI” command, select “Analyze & Report” and the model will see all previous recorded steps, evaluated values, etc, and will be able to produce reports with hyperlinks. E.g. you can record all writes to a variable (with call stacks/parent variables if needed), and then ask AI to look for particular suspicious changes, and give you a table of relevant steps, pointing where exactly each value came from.

There’s also very experimental support for driving the debugger with AI (“Investigate & Report” command), but invoking the model for each debug event separately (as opposed to a recording that capturing a particular problem) can burn up the tokens quite fast.

[Author]

Posts