Forum Replies Created
-
Posts
-
No problem, we have fixed the duplicate window issue in this build: VisualGDB-5.4.112.3249.msi
Please try adding “pthread” to the “library names” field on the Build Settings page of VisualGDB Project Properties. You can read more about various linker-related settings here: http://visualgdb.com/support/linkerinputs/
Hi,
Sorry, the Advanced Mbed project subsystem relies on mbed itself to orchestrate the build and hence VisualGDB only allows changing the settings supported by the mbed-cli itself.
Based on a quick research, it looks like supporting floating point printf/scanf with mbed-cli requires a minor modification to the build scripts (see this Github issue). Please try applying it to the mbed copy used by your project and mbed-cli launched by VisualGDB should automatically pick up the updated build rules next time you build the project.
Hi,
No problem, we will help you understand how VisualGDB handles the K210 build and how to get the setup you described.
When you create a VisualGDB project for the K210 device, it automatically downloads a copy of the K210 SDK into %LOCALAPPDATA%\VisualGDB and references it from the project. The SDK copy contains an XML list of the sources and build settings required for K210 projects, so VisualGDB can automatically generate a VS project that would replicate the build result from the original K210 SDK.
Based on your description, you have likely imported another copy of the SDK as a generic project (importing the list of source files, but not the build settings that were captured from the original K210 SDK) and hence the build produces an invalid binary.
If you would like to have a separate copy of the K210 SDK and be able to modify it yourself, please instead try creating a regular VisualGDB project and then converting it to a stand-alone one as shown in this tutorial. This will copy the SDK files into the BSP subdirectory in your project folder and will also copy all the necessary build settings, so that the build result will be equal to the regular project. while letting you tweak that specific copy of the SDK according to your needs.
If you encounter any further issues, please feel free to let us know. The K210 support is very new and all feedback will be highly appreciated.
Good to know it works. Just in case anyone else is looking for the same functionality, our bootloader tutorial describes the steps necessary to merge the bootloader with the main application.
Hi,
Yes, please use the following setting:
VisualGDB Project Properties -> Debug Settings -> Program Output -> Keep Remote Console window after debugging ends
Regarding F5, normally unless you explicitly activate the console window by clicking on it, F5 should be handled by the Visual Studio itself and should result in continuing from the breakpoint.
VisualGDB will officially support ESP-IDF 3.3 and 4.0 once they are released as stable releases. Until then, you can try using VisualGDB with those ESP-IDF versions, however some functionality may not work as expected, as Espressif often changes the internal structure of ESP-IDF during the pre-release stage.
Hi,
VisualGDB supports Segger J-Link and any programming interface supported by OpenOCD (that includes FT2232-based devices such as Olimex ARM-USB-OCD-H and almost every other popular debug probe). The only exceptions are U-Link (as it’s based on proprietary protocols not supported by OpenOCD) and generic CMSIS-DAP (it’s technically supported, although is very slow due to the USB HID poll rate limitations).
You can read more about the supported devices and debug interfaces here: http://visualgdb.com/hwsupport/
Strange, now it looks like the {upload.verbose} got expanded to an empty string. Please try removing the “{upload.verbose}” part completely from the programming command line (also remove the quotes).
The easiest way to achieve that would be to embed the simulated data into your program as an embedded resource and then reference the Fast Semihosting framework via VisualGDB Project Properties -> Embedded Frameworks and output the results via the regular printf() calls. The output will be shown in the Semihosting Output window inside Visual Studio and can be saved to a file at the end of the debug session (see VisualGDB Project Properties -> Embedded Debug Tweaking).
The platform.txt file appears correct, so most likely your project is still using the old cached command line.
Please ensure you don’t have any other versions of the ESP8266 package installed and try reproducing the problem on a new project created from scratch. If the new project works, please try reloading the existing project as we suggested earlier in order to reset its cached values.
Hi,
We usually add out-of-the-box support for new platforms once they get enough traction. Currently we are still assessing the popularity of the new nRF Connect platform and will be deciding whether to support it directly in the next 4-6 months. As a workaround, please try creating a project manually as shown in this tutorial.
Alternatively, we can support nRF Connect earlier via our paid custom BSP program. Please feel free to contact our sales to get a quote for this.
Hi,
You can add the library to your project by adding its source files to the Solution Explorer (via Add->Existing item) and then adding the paths of the header files to the Include Directories field of the VisualGDB Project Properties (or just trying to include one of the header files from your sources and then following VisualGDB’s prompts to add the necessary header directories).
