Forum Replies Created
-
Posts
-
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).
Thanks for the update. Looks like VisualGDB tries to load it as a VisualGDB-specific XML file instead of using the SVD loading logic.
Please try changing the file extension to .svd and importing it again.
We have investigated the problem and it looks like a bug in the ESP8266 Arduino package triggered by the verbose mode enabled by VisualGDB.
We have created a Github issue in the ESP8266 Arduino repository suggesting a workaround. Please try patching the <HOME>\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.5.2\platform.txt file as described on the Github page, then reload the project via the context menu to ensure VisualGDB picks up the updated programming command line template.
Thanks for letting us know, however unfortunately it’s hard to suggest anything specific without knowing more details. If you could describe exactly how you were importing them and what you observed (and ideally, share the entire file you tried importing), we should be able to suggest a workaround or release a hotfix for it.
Hi,
You can find the firmware package versions used by VisualGDB in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\SDKVersions.xml
Hi,
It looks like the latest ESP8266 Arduino package might be broken. Could you please quickly recheck whether it works with Arduino Studio? If not, please consider filing a bug report with Espressif.
Hi,
This looks like a regular SVD file that should be already supported by VisualGDB. Simply select it when clicking on the “Locate SVD file” link in the Hardware Registers window and VisualGDB will automatically convert it to its format.
Alternatively, you can use the converter from our BSPTools repository that is equivalent to the converter used by VisualGDB.
Hi,
Good to know it works.
Regarding the major version, yes, we are currently finishing our work on supporting more device families and will start releasing preview builds on the next major version introducing new functionality in the next 1-2 months.
Hi,
Yes, VisualGDB fully supports this layout. If you are planning to continue having the Windows builds, we recommend using the Project->Add Linux Configuration command to add a VisualGDB configuration to all of the projects (if you have multiple project files, we would advise comparing the .vcxproj file before and after and scripting the necessary changes).
If you are no longer interested in maintaining the Windows builds, we would advise creating an Advanced CMake project. It fully supports multiple targets as well has an advantage of sharing common project properties (e.g. build machine, custom steps) between all targets built within the project.
If you have any further questions, please don’t hesitate to get back to us and we will be happy to provide more details.
Hi,
This looks similar to a problem that was recently fixed on our side (invalid layout computation for one of the tool windows). Please try this build: VisualGDB-5.4.112.3248.msi
If it doesn’t help, please try evaluating “$exception” in the outer VS instance and navigate to the InnerException field of it. Then check its call stack and let us know (together with the build number it was obtained from) and we should be able to fix it.
No problem. Unfortunately, there is no easy solution here, as it looks like different versions of the NXP framework (or the sample project itself) work differently.
The solution would be to extract the build command lines used by the NXP IDE, build the project manually using those command lines and then try combining them with the VisualGDB command lines (e.g. using VisualGDB’s linker command line to link the object files produced by the NXP IDE or vice versa). By checking the behavior of the build results, you should be able to pinpoint a specific source file (or a compiler/linker flag) that is causing the issue. Unfortunately, it would take several iterations to nail it down (you can check this tutorial for a similar process for the Keil compiler).
Another option would be to import the NXP project into VisualGDB as an externally built project (using NXP’s Makefile and NXP’s driver libraries). This will allow reusing the existing build system (that produces usable projects) with the rest of the VisualGDB’s features.
Hi,
The only change to R12 was the support of the Kendryte K210 AI chip. We have updated the history page accordingly.
Sorry, this is by design. The tab semantics for Unix terminals is fairly complex (e.g. it can be altered via the ANSI escape sequences and it’s also possible to start overwriting text in the middle of a tab break), so VisualGDB automatically translates all terminal input it receives into a simple 2-dimensional matrix of characters and attributes.
We might be able to add a special attribute tracking whether a group of spaces was created in response to a tab symbol, but realistically we won’t be able to do it until the next major redesign of the terminal logic (that is not on the radar yet), sorry.
