Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
You could try using the _sbrk() implementation that comes from our “Fixed-size stack and heap” framework described in this tutorial: https://visualgdb.com/tutorials/arm/stack/
You would need to modify the linker script to place the “.heap” section into SDRAM and explicitly set the heap size via VisualGDB Project Properties.
support
KeymasterSorry, the screenshot did not get uploaded properly. Could you please upload it to an image sharing hosting? I.e. a screenshot showing the context menu when you right-click on a function like “main”.
support
KeymasterHi,
Good to know it works. BTW, we have added support for the “Peek definition” feature to the Clang IntelliSense in the upcoming VisualGDB 5.2 Preview 2, and also significantly improved performance and added a special mode for diagnosing parsing time. If this sounds like something worth giving a try, let us know and we can share a build with this feature.
support
KeymasterHi,
This could be caused by either X11 forwarding or the gdb signal handling. Please try configuring VisualGDB to display the X11 windows on the Raspberry Pi itself instead of forwarding them to your Windows machine. If this does not help, please check if you can reproduce the same behavior with a basic program that will not have any other code besides the waitKey() call.
support
KeymasterHi,
We usually only officially support major releases of the ESP-IDF, as the in-between versions that introduce new functionality often also break old features.
As the ESP-IDF is being developed very rapidly, we have actually added support for importing projects built directly by esp-idf that does not require an updated BSP from us.
I.e. you can simply replace the contents of the esp-idf.orig directory with the latest version of ESP-IDF and follow this tutorial: https://visualgdb.com/tutorials/esp32/esp-idf/
support
KeymasterHi,
The problem with treating the mbed-cli projects as normal editable VisualGDB projects is that it would depend on the internal format of the files generated by mbed-cli and will stop working each time the format changes.
So with mbed we essentially offer 2 approaches:
- Using our BSP that is verified, tested and maps common mbed features to easily editable embedded frameworks. But it’s updated quarterly as we need to manually keep up with the changes to mbed itself.
- Manually importing an mbed-cli project. This is less intuitive and requires some extra steps, but will still give you access to advanced debug and IntelliSense features and does not force you to use a specific mbed version.
support
KeymasterHi,
This actually looks like a bug in our STM32 BSP. Please try locating the following lines in the BSP.XML file:
<AdditionalIncludeDirs> <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/STM32L1xx_HAL_Driver/Inc</string> <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/STM32L1xx_HAL_Driver/Inc/Legacy</string> <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/CMSIS_HAL/Device/ST/STM32L1xx/Include</string> <string>$$SYS:BSP_ROOT$$/STM32L1xxxx/CMSIS_HAL/Include</string> </AdditionalIncludeDirs> <AdditionalPreprocessorMacros> <string>$$com.sysprogs.bspoptions.primary_memory$$_layout</string> <string>$$com.sysprogs.stm32.hal_device_family$$</string> <string>$$com.sysprogs.bspoptions.stm32.hal_legacy$$</string> </AdditionalPreprocessorMacros>
Then simply remove the line with $$com.sysprogs.bspoptions.stm32.hal_legacy$$ (ensure that you do it for the L1 definition, not F1 definition).
We will also fix this in the upcoming STM32 BSP refresh.
June 22, 2017 at 18:53 in reply to: Visual GDB error with shared librarys from remote machine #11558support
KeymasterIt looks like you are trying to debug the system linker application instead of your own application.
Please check the debug page of VisualGDB Project Properties and ensure you debug the $(TargetPath) instead.
support
KeymasterHi,
The Code Map is a part of our Clang IntelliSense engine and hence will only work if you have it enabled. Please double-check that you are actually using it (you can check this by right-clicking in the source file and checking if the “Preprocess selected lines” command appears).
June 21, 2017 at 04:27 in reply to: VisualGDB not displayed in Visual Studio 2017 Professional #11550support
KeymasterHi,
This could happen if you had Visual Studio instances open while installing VisualGDB and the installer did not automatically close them. Normally installing or removing any other extension should force VS to refresh its cache and repair any menus.
support
KeymasterHi,
It looks like the program starts and exits normally. Please try stepping into it by pressing F10 instead of F5 and then stepping through.
support
KeymasterHi,
Strange, it looks like the libcompactcpp library is specified in the command line, but is not linked.
In order to troubleshoot this, please try creating a new project from scratch with the following code:
#include <exception> int main(void) { std::terminate(); }
Then link it with libcompactcpp. If the map file shows that the _ZSt9terminatev function is taken from libcompactcpp.a, please try understanding the differences between your main project and the test project. If not, please try re-downloading our latest toolchain.
If nothing helps, please add “-Wl,-verbose” to LDFLAGS and post the following:
- The full Map file
- The full verbose link log
This should help understand why libcompactcpp.a is not included.
support
KeymasterHi,
This looks like a gdb bug, so our best advice would be to try a different toolchain with a different gdb version. If this does not help, feel free to send us your ELF file so that we could try reproducing this on our side and checking why it crashes.
support
KeymasterHi,
You can import a project generated by mbed-cli into VisualGDB by first generating a Makefile-based project and then selecting Import->Import a project built with command-line tools. VisualGDB will then not make any assumptions about the project structure and will just run “make” to build the project.
The downside will be that you would need to manually synchronize the list of sources between the Makefiles and the VisualGDB project and also manually set the preprocessor macros and include directories in VisualGDB Project Properties so that VisualGDB IntelliSense could understand the code properly.
support
KeymasterHi,
Just to double-check, the board works with the Arduino core, but not with C/C++ projects, right? If yes, please try experimenting with the FLASH settings (mode/speed/size) via VisualGDB Project Properties to see if there is a combination of settings (start with the slowest frequency, smallest FLASH size and the dio mode) that works with the board.
-
AuthorPosts