Forum Replies Created
-
Posts
-
Thanks for renewing your license and good to know it works.
The problem might have been caused by an incompatibility between the Segger software and J-Link firmware, and reinstalling the Segger debug package (or some other component it uses) have likely fixed it.
Hi,
No problem, we can help you resolve this, however it looks like your support period has expired. Please renew it first, or let us know the email address associated with your new license, if you have purchased one already.
Hi,
Please use the following setting: Tools->Options->Text Editor->C/C++ (VisualGDB)->Other->Max. change-driven tags.
Simply set it to 0 in order to disable rename-triggered smart tags.
Hi,
Strange. Could you please share a screenshot of your settings and the command line shown in the build log?
Hi,
Thanks for the suggestion. We have done a few quick checks and it looks like we should be able to support it.
We will get back to this and post an update here in the next 1-2 weeks.
Hi,
Unfortunately, the global mbed setting for the toolchain location overrides the setting passed by VisualGDB. We have updated VisualGDB to clear the global setting when configuring the projects in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2564.msi
If you would like to have a global toolchain setting nontheless, please define the GCC_ARM_PATH environment variable via System Settings -> Environment.
With the target names, it looks like an issue of mbed-cli. Please try building the project from command line and check if the problem persists. If the build with mbed-cli works, but VisualGDB-based build doesn’t, please let us know and we will help you find the difference between the 2 configurations and will update VisualGDB to work around it.
Regarding the esp8266 component, the Advanced Mbed Project Subsystem delegates the build to the mbed-cli tool, so it does not have control over the low-level details of the build process. Please refer to the mbed documentation and forums for mbed-cli-specific instructions on excluding specific components. On the VisualGDB side, you can use the VisualGDB Project Properties to add arbitrary arguments to mbed-cli used to build your project.
Hi,
Yes, you should be able to customize the build command line via VisualGDB Project Properties -> CMake project settings -> Make Command.
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.
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.
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.
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.
