[support]

If the image produced by VisualGDB is not working, while the same project built with MCUXpresso works with the same uploading/debugging method, most likely the two projects are using different memory layout. VisualGDB imports the default settings from the MCUXpresso SDK, and the SDKs generated for the MCUXpresso IDE and generic GCC (used by VisualGDB) could be slightly different.

As suggested in our first reply, you can try using the objdump tool to dump the layouts of both projects into text files, and compare the addresses of the critical parts (vector table, stack pointer, initialization code, etc.). If they are different, please double-check the linker scripts used by both versions of the project and make sure they are consistent with each other.

Ultimately, both MCUXpresso and VisualGDB use the same GCC compiler, so if the executables produced by them are different, some arguments to the compiler do not match between the 2 setups. Running objdump could help track it down, and you can also try running the command lines from both sides manually as shown in this tutorial (it is about Keil, but the VisualGDB-side steps for the GCC compiler will be similar).

[support]

This looks like you have configured some extra settings in the project to incompatible values.

Please try reproducing the problem on a project created from scratch. If the problem persists, please let us know the steps to reproduce it per our problem reporting guidelines. If the newly created project works, please try comparing its settings against the current project settings and make sure they match.

[support]

Hi,

You can find the logic used by OpenOCD to load and run the plugin in this file: https://github.com/sysprogs/openocd/blob/master/src/flash/FLASHPlugin.c.

You should be able to understand what is going on by building a debug version of OpenOCD and running it under debugger (see this tutorial).

[support]

You can work around it by creating an empty .c file and referencing it from the targets that would otherwise have no sources. Another solution would be to patch CMake to make it report interface libraries together with the object libraries, but that could be rather complicated.

[support]

Hi,

The exact location of the setting depends on your project type. Please see this page for more details. You can also double-check whether the option gets actually passed to the compiler by enabling verbose build (see project type-specific pages linked above) and rechecking the GCC command lines.

[support]

Hi,

Normally, WSL2 should work out-of-the-box, as long as the Linux side can connect to the Windows side via TCP/IP. Please see this page for a detailed instructions on troubleshooting WSL2 issues.

[support]

Hi,

You are likely missing the “init” command. In general, we would advise first running OpenOCD using exactly the same command line VisualGDB uses, then connecting to the telnet_port via telnet and running the “mdw” command via it. This should produce results consistent with regular debug sessions.

[support]

Hi,

This is a known limitation of CMake. It indeed does not report the contents of interface targets via the mechanism used by VisualGDB.

Please consider using object libraries instead – they work similar to interface targets, but their contents is actually shown.

[support]

Hi,

VisualGDB has its own easy and intuitive mechanism for custom steps. You can use the “Custom build steps” page of VisualGDB Project Properties to define a variety of different steps using convenient GUI.

Note that this feature is available starting from the Custom edition.

[support]

Good to know you managed to reproduce it. One thing, issues like this could be caused by bugs in the network stack (packet with the command from VisualGDB gets lost and is never resent). If the issue happens intermittently over SSH, but never locally (e.g. in an xterm window), it could be caused by the network rather than the gdb executable.

[support]

Hi,

This message means that your gdb debugger is taking too long to process the variable evaluation command issued by VisualGDB. The delay does not come from the VisualGDB side and it caused by the gdb itself.

If you would like to find out what is causing it, please consider building a debug version of your gdb executable and stepping through it once you reproduce the issue.

[support]

Hi,

According to the gdb log, it actually manages to stop in main() before stopping in the unknown location:

[   13421 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x400d4bab",func="app_main",args=[],file="../../../main/blink_example_main.c",fullname="C:\\Users\\Jens\\Documents\\ESP32\\Solutions\\EmbeddedSolution1\\EmbeddedProject1\\main\\blink_example_main.c",line="74",arch="xtensa"},thread-id="1",stopped-threads="all"

Please try removing the WaitForSysprogsDebugger() function and using F10 instead of F5 to start the debug session. It will automatically stop the program at the beginning of app_main(), so you will be able to step through it and see which parts of the program work.

[support]

Hi,

Just to double-check: you are observing that unchecking the “build” checkbox in Configuration Manager for a particular project moves the unit tests from it into the “external” category, rather than hiding them as expected, correct?

[support]

Hi,

This could be a bug in OpenOCD, or something specific to a device (e.g. the firmware disabling the JTAG/SWD pins). The best way to troubleshoot it would be to break it down into smaller parts:

1. Try running OpenOCD manually. Check if you can read/write the memory at the end of stack using the mdw/mww commands.
2. If yes, try connecting gdb manually and running the “print *((void **)0x2001fffc)” command.
3. If it works, try manually running the gdb commands executed by VisualGDB (from the log file) to see which of them causes the memory to stop working. E.g. some part of the FLASH loader might interfere with the pins, clocks or other settings.

You can also try building OpenOCD from sources as shown here and double-checking what exactly happens when it tries to read memory, or run specific commands.

[support]

As we suggested before, you can try using Segger J-Link. It comes with its own software that supports more devices out-of-the-box compared to OpenOCD and include sits own support for low-level issues like this one.

If you are specifically looking for someone to get OpenOCD working with a specific example on a specific chip, unfortunately it is not something we could do without charging our consulting rate. Feel free to ask around on freelancing sites – perhaps someone can offer to do it at a lower rate. This is not specific to VisualGDB and does not rely on any VisualGDB-specific knowledge.

Please also note that we have tried including more device-specific help with our product support earlier, but it didn’t really work. It took us considerable time to investigate each project and point out the cause. The users were thankful at the moment, but they would soon come back with other issues with other projects, expecting a faster turnaround, more insights into internals of various devices, and help fixing/explaining various code originating from external sources. So unless we would agree to keep up allocating continuously increasing amount of resources to it, there was always disappointment.

Solving this at our consulting rate works for companies that prefer focusing on their domain-specific issues and occasionally outsource infrequent platform-specific issues. It saves them time and allows us allocate the resources necessary to handle it. If you are constantly working with multiple hardware platforms and encounter a large amount of issues, we advise planning sufficient time to study the documentation of each platform and find the correct platform-specific settings for each setup.

[Author]

Posts