Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
Hi,
Thanks, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2562.msi
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?
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.
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
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.
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.
Hi,
Most likely you have created a project for the nRF51 chip (not nRF52) that was deprecated and removed from the modern Nordic SDKs. We handled this by forking nRF51 support (based on the latest SDK that supports it) into a separate BSP with a different ID.
Please try locating the nrf5x.xml file in your project directory and check the exact MCU ID it mentions. Then create a new project for the same MCU with the VisualGDB project wizard and check the BSP ID it puts in the new project’s nrf5x.xml file. Finally, copy the new ID to your old project and you should be able to build/debug it again (you may need to regenerate MCU-dependent files via VisualGDB Project Properties).
Hi,
OK, thanks for sharing this. Looks like we know what is going on. Your project likely explicitly stores the ARM toolchain location and VisualGDB is unable to override it with the dummy toolchain that produces a code model. We should be able to add a workaround for this. Would you be able to attach a copy of your mbed configuration files (*.py and *.json from the project’s directory)?
Hi,
It looks like your project structure might be different from what VisualGDB expects, hence it does not manage to parse it.
VisualGDB handles advanced mbed projects by temporarily replacing the toolchain with a dummy one that pretends to build all the sources, while creating a full log of all gcc/ld invocations, so VisualGDB can reconstruct the project structure from them. Most likely something about your project setup is preventing this from working.
We should be able to update VisualGDB to support it if you could share the following files under your project directory:
- VisualGDBCache\<configuration>\CodeSenseDir\MbedCommandLines.txt
- VisualGDBCache\<configuration>\BuildCommandLines.txt
