[support]

Hi,

 

This indeed looks like a VisualGDB bug. First of all, please try updating to VisualGDB 5.4 Preview 9. If it doesn’t solve the problem, please double-check that the .props and .xml files are writable.

If it doesn’t help, please share:

• A screenshot of the properties page before clicking “Apply”.
• The mcu.props and mcu.xml files
• A screenshot of the properties page after clicking “Apply” once the changes are lost.

This should help us identify the problem and provide you with a hotfix.

[support]

Hi,

Good to know it works. We should be able to fix the crash with aborting the FLASH downloading if you could obtain the context of the crash as described here (alternatively we would need a detailed description of your configuration, as FLASH can be programmed using several different mechanisms and it’s hard to say which one is causing the crash).

We are actually working on a redesigned system of custom actions for the upcoming VisualGDB 5.4, that will include better support for reusing the actions.

MSBuild is indeed faster than GNU Make – we have spent considerable effort optimizing our MSBuild backend, so it uses heavy parallelization and minimizes the overhead of auxiliary tasks like managing dependencies.

The idea of writing an article about ToughGFX sounds great – feel free to share a link to it on our forum.

[support]

Hi,

We would advise running a few quick experiments to understand what components could be causing this:

• Try profiling a “hello, world” program with VisualGDB.
• If it doesn’t work, try running valgrind manually (let us know if you need help with command lines).
• It the “hello, world” works, try running valgrind manually with your program.

If it looks like the problem is between valgrind and your specific project, please try simplifying it (e.g. removing some sources/libraries/optimization settings). If the problem occurs with VisualGDB, but doesn’t occur otherwise, it’s likely caused by some arguments VisualGDB is using. In this case please try comparing the command lines that work and the command lines used by VisualGDB (from View->Other->VisualGDB Diagnostics Console).

If you need further help at any step, don’t hesitate to get back to us.

[support]

Hi,

The VisualGDB frameworks indeed affect the entire project, not just separate configurations (this comes from the VS project semantics). That said, the latest semihosting/profiler framework can automatically detect whether the debugger is attached to the microcontroller (if you are using the Cortex M devices) and disable the semihosting functionality if no debugger is present. See the “hen running without debugger” setting on the Embedded Frameworks page for details.

If this doesn’t help, please let us know what you are trying to achieve and we will suggest a better way.

[support]

Hi,

 

We have done basic tests on the NONOS SDK 3.0 and it looks like several parts of it are seriously broken: the new partition table mechanism doesn’t work for non-OTA applications and some users who tried it reported random crashes in JSON-related code.

You can try using this toolchain build that includes the new SDK, however it did not pass our internal tests and we cannot recommend it for stable development. Once Espressif releases the next update to the SDK, we will re-run our tests on it and will publish an updated toolchain.

[support]

Hi,

Sorry, the “Custom Build Steps” are only supported in the Custom edition of VisualGDB or higher. If you are using a lower edition, you can achieve the same functionality by adding a custom MSBuild target manually, however the VisualGDB GUI for managing custom actions easily won’t be available.

[support]

Hi,

Good to know it works. If you encounter any further issues, don’t hesitate to get back to us.

[support]

Hi,

Copying the project should be enough even for regular VS projects (if you want to open both the original and the copied project in one solution, you would need to change the project GUID in the copy). From the VisualGDB side, unless your .vgdbsettings files contain hardcoded absolute paths, simply copying should be enough.

If it doesn’t work, please let us know your project type and the errors you get and we will advise further things to check.

 

[support]

Hi,

No problem, we can help you. First of all, please try to narrow down the problem to a specific source file (you can compile just one source by pressing Ctrl-F7 if using MSBuild). Then build just that file and check the error list (please turn off IntelliSense errors for the beginning and only look at build errors).

If you see a “header file not found” errors before the “DMA_HandleTypeDef” error, please locate the missing headers and add the corresponding paths to the project’s include directories. If no such errors are shown, please enable the “generate preprocessor output” option for that source file via Visual Studio Project Properties -> C/C++ -> Outputs and check the preprocessor output (.E file in the VisualGDB\Debug folder). It should list all headers included while building the file and the lines from those headers that were not #ifdef’ed out. If DMA_HandleTypeDef is not defined there, it might be due to including an incorrect header file, missing some HAL_XXX_ENABLED macros, that would exclude the actual definition, or missing #include<> directives altogether. If you need further help with this, please let us know your findings (build error messages, preprocessed file contents, etc) and we will provide further help.

We will consider supporting more detailed fine-tuning of additional memories in the next releases of VisualGDB. As a workaround, please consider adding any other memory (so that VisualGDB creates a local copy of the linker script) and then manually adding the QSPI sections there. Also if you already have a working GCC-based project in a different IDE, please consider simply copying an existing linker script from it and setting it via VisualGDB Project Properties. This should provide easier transition, as it will eliminate the differences between the linker scripts.

The _WIN32 macro is only shown if you are using the regular VC++ IntelliSense. Please consider switching to VisualGDB-provided Clang IntelliSense for better compatibility with GCC-specific code. Regarding FreeRTOS, if you were using the HAL/FreeRTOS packages that come with VisualGDB, it would display a more meaningful error message in case of HW/SW floating point incompatibility (we have added a check with an #error directive to our version of port.c), but using an incompatible 3rd-party copy of it unfortunately indeed results in cryptic error messages.

[support]

Hi,

Thanks, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2562.msi

[support]

Hi,

No problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2562.msi

It will honor the “Suppress CodeJumps” setting for the QuickInfo tooltips.

With the jumping popup window, it might be tricky. VS uses a rather hacky way to position the popup, so VisualGDB has to do some guessing on top of that to reposition it properly and it might not work correctly 100% of the time. If you could share a quick video showing the problem, we should be able to tell whether we could easily fix the behavior you are observing.

The second glitch might be specific to some code. Unfortunately it looks like screenshots #1 and #3 are the same. Could you please double-check it and also share the .c file where this is reproduced?

[support]

Hi,

Sorry, this is caused by the implementation details of the VS language service framework (that VisualGDB has to use in order to be compatible with 6 different VS versions), so unfortunately we won’t be able to fix it anytime soon.

[support]

Hi,

Please try pressing Alt+Tab several times see if there are any message boxes shown behind the VS window (sometimes they are shown incorrectly by VS).

If you cannot find any, please capture a VS stack trace as shown here: http://visualgdb.com/support/callstack

[support]

Hi,

Sorry for the inconvenience. As Nordic removed the support for nRF51 from their new SDKs, we had to start shipping 2 independent BSPs instead of just one, hence breaking backward compatibility. Normally we try to ensure the backward compatibility between our packages, but a lot of the BSP structure comes from the device vendor.

[support]

Hi,

We have just published a tutorial showing the stack analysis here: https://visualgdb.com/tutorials/arm/stack/static/

As a quick check, could you confirm that the “Disassembly” view in the memory explorer works correctly? If yes, we will add further diagnostic logging to the stack analyzer and should be able to pinpoint it.

[Author]

Posts