Forum Replies Created
-
Posts
-
Hi,
The missing hardware registers is a known issue – our mbed BSP generator uses very basic logic to associate mbed targets with register files provided by other BSPs and doesn’t pick up the ARCH_MAX properly. The workaround is very easy – just select the correct definition file from the Hardware Registers window.
Regarding clocking, it looks like your technical support as expired. Please renew your license and we can help you understand the mechanism used by mbed to control the STM32 settings and change them.
Hi,
This looks consistent with your settings – the namespace contents are not indented, the class contents are. If you could narrow this down to some specific steps that lead to undesired behavior, we should be able to diagnose/fix this. Otherwise it is hard to see what exactly could be causing the trouble.
Hi,
If you are trying to reserve a fixed amount of space for the stack/heap, please try adding the “Fixed stack/heap” framework via VisualGDB Project Properties -> Embedded Frameworks and VisualGDB will do this for you automatically.
Otherwise you would need to edit the linker script to modify the memory layout manually. You can simply copy the default linker script used by VisualGDB locally via VisualGDB Project Properties -> Build Settings, move the .reserved_for_stack section to the location you want and update the _estack symbol to be defined at the end of the .reserved_for_stack section (the initialization code will use this symbol to set the initial stack address).
Hi,
Yes, we are expecting to release the next preview with Arduino support in the next 1-2 weeks.
If you buy a license now, you will be able to use any VisualGDB version released within 1 year from your purchase. This will definitely include v5.4 that is currently in preview and might include the next major release, depending on the exact release schedule.
Hi,
Yes, we will consider doing that if ST continues actively developing/supporting TrueStudio.
Either way, we have made our project importing plugins open-source to help our users import formats that are not directly supported by VisualGDB yet. This way you might be able to create a basic importing plugin that will automate most of the work you need before we officially support it.
Hi,
Normally it should work automatically if you are using the latest VisualGDB 5.4 Preview 3, however setting it manually is a reasonable workaround if it doesn’t.
If you can confirm that the setting is not automatically picked up with the latest VisualGDB, please feel free to post a repro project here and we will investigate/fix this.
Hi,
It will basically restrict discovery of references to the main source file only. E.g. if you have a template function inside the main file, but it’s instantiated somewhere in a header file, that instantiation will be ignored and the function body won’t be colored properly (that only affects template functions and only if they are not used inside the main file itself).
It might also interfere with the ‘find all references’ functionality for translation unit-scoped entities (e.g. static functions), that are declared inside the main file, but used from headers (this won’t affect finding references for regular functions/classes, as it involves scanning the entire project using a different mechanism that is not affected by this setting).
Hi,
Thanks, this looks like a known issue. Please try clicking on the timer icon in the upper right corner of the document and click “enable lightweight references” (or enable it via VisualGDB Project Properties -> IntelliSense). This should significantly reduce the parse time.
Hi,
This might be happening because the FreeRTOS in the ESP8266 SDK is pre-compiled and hence won’t be updated, although there might be some workaround. Either way, please double-check this with Espressif, as they are the vendor of the SDK and know its internals better than we do.
Hi,
We are currently working on the new Advanced Arduino Project Subsystem that will make it possible (and very easy and intuitive) to manage Arduino projects with Visual Studio. If you would like to get notified about the new releases, please consider following us on Twitter.
Hi,
Yes, please edit the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7\15.0 value in registry to point to the VS Professional folder and then uninstall VisualGDB and install it back. This should get VisualGDB to recognize the correct VS instance.
Hi,
No problem, we rechecked the Raspberry Pi support for OpenOCD and can try to clarify this. First of all, please try reading this article – it provides detailed steps with screenshots.
Basically, you would need to build OpenOCD on your Raspberry Pi and run it there (our OpenOCD executable runs on Windows and hence it doesn’t indeed include the drivers that only make sense when running on Raspberry Pi).
On the VisualGDB side, the “custom gdb stub” mode won’t work as it would expect the stub to run on Windows. Instead, please set the following options:
Command <default GDB path> Arguments ——interpreter mi $(TargetPath) Target selection command target remote raspberrypi:<port> Start command continue Please note the double dash before “interpreter mi”.
Hi,
If you have imported the project as an externally built custom project, you can change the main executable path on the Build Settings page of VisualGDB Project Properties.
Hi,
The easiest way would be to use the “custom gdb stub mode” instead of the “full-custom” one. VisualGDB would then automatically configure the GDB arguments (the problem you are describing looks like a missing “–interpreter mi” argument to gdb).
Another option would be replace the OpenOCD binary in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\…openocd\bin with the one you built and manually pick the Rasberry Pi interface file.
It is strange that VisualGDB did not support some JTAG programmers; our OpenOCD build uses default build settings, so all programmers that are normally supported, should work. Feel free to share more details about this and we can help you figure it out.
Also Segger J-Link is recommended only if you are looking for 100% out-of-the-box experience for a wide variety of devices. If you are OK playing around with OpenOCD scripts (or are only using popular devices like STM32), getting an inexpensive Olimex probe should do the job as it works very well with OpenOCD.
Hi,
Please try attaching to your device as shown in this tutorial. It should show what exactly the CPU is doing. Please also use the “Verify memory” button in the GDB Session window to check whether the FLASH memory was programmed correctly.
