Forum Replies Created
-
Posts
-
Hi,
Are you using the new advanced ESP-IDF project subsystem, or is it a regular VC++-based project?
Hi,
Yes, please try marking the sections for the external FLASH memory with the NOLOAD attribute in the linker script. This will prevent the objcopy tool from trying to place them in the same contiguous binary file as the regular FLASH sections.
Hi,
Thanks for reporting this. It looks like the advanced popup mode was inadvertently activated in some cases where VisualGDB could not fetch the regular QuickInfo text.
We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2571.msi
No change of settings is necessary – the advanced popups will now only appear when activated explicitly.
Hi,
Sorry for the delay. We have pinpointed and fixed the issue in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2571.msi
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.
