Forum Replies Created
-
Posts
-
Hi,
Sorry, the AT91SAM7 BSP is very old and may not properly work with the latest toolchains or the MSBuild subsystem.
The build problems with GNU Make are most likely caused by the incorrect “AS” environment variable inherited from the environment. Commenting out ifeq/endif as you mentioned above should successfully work around it.
Getting MSBuild to work with AT91SAM7 could be harder, as its linker script expects a specific order of the source files, that is not guaranteed with MSBuild. We would advise using MSBuild for newer device families and GNU Make for AT91SAM7S. You can solve the “invalid instruction” error by adding the #define __ASSEMBLY__ line to the beginning of the board_cstartup.S file, however the build may still fail due to the linker input ordering.
The fast semihosting was only tested with the THUMB instruction set used by the modern embedded ARM devices, while AT91SAM7 uses the ARM instruction set by default. You can try switching the instruction set to THUMB, however the background memory reads required by the advanced semihosting may not be supported by the older ARM7TDMI core used by the AT91SAM7 devices.
Please follow the instructions from our reply in the following thread: https://sysprogs.com/w/forums/topic/problem-error-building-after-update-to-new-release/
Most likely, the problem is triggered by an accidental change of some settings of the project or a toolchain. Please try comparing the settings of the working and non-working projects (either compare each page of VisualGDB Project Properties, or compare the .vgdbsettings and .pro files using KDiff or another diffing tool) and then try editing the broken project to match the settings of the working project. If you can narrow down a specific setting, we can check whether it could be caused by a VisualGDB update and release a hotfix, however it is not possible for us to confirm it without knowing a specific setting.
Hi,
It looks like your Visual Studio font/color cache is corrupt, preventing extensions like VisualGDB from registering custom code coloring items. Please try repairing/reinstalling your VS installation.
Thanks for the update. It looks like the connection succeeds, so the error might be caused by something else.
Please try switching the GDB Session log to “All GDB Interaction” and check the GDB output for a specific error.
If you are not sure, please create a full gdb session log and attach it here so that we can review it.
Sorry, this fix isn’t a part of the official release yet, as we will be bundling it together with a few other small improvements. We expect to release the updated version in the end of this week, or the beginning of the next one.
Hi,
We have recently finished investigating this and added logic for automatically correcting invalid file references. Please try this build: VisualGDB-5.4.111.3240.msi
Hi,
This could happen if an old instance of OpenOCD was still running in the background, preventing the new one from listening on port 3333. As an experiment, please try changing the port (by adding -c “gdb_port 1234” to OpenOCD command line) and update the gdb settings accordingly. If this solves the problem, please double-check that the old OpenOCD instance terminates successfully and that no other program is holding the TCP port open (you can use the netstat tool to do that).
You can also troubleshoot this by starting OpenOCD and trying to telnet to its TCP port. If the connection fails, try disabling the firewall as it sometimes incorrectly prevents programs from connecting to OpenOCD.
Sorry, unfortunately it’s hard so suggest anything specific without knowing the exact steps to reproduce it, as there are too many factors that could be causing this.
Our best advice would be to try creating a similar project from scratch (same type, same toolchain, etc), and try comparing the behavior between them. E.g. add the same “hello, world” source file to both test project and the big project and if it behaves differently, try reducing the big project until it matches the small one (e.g. by removing files and settings from it). Once you pinpoint a specific setting that causes the problem, we should be able to suggest a workaround, or provide you with a hotfix.
Installing VisualGDB 5.4R11 should normally be sufficient, so the problem is likely caused by something else. Would you be able to create a short video showing the problem (from creating a project via the wizard to having no Ctrl-Click functionality available)? Alternatively, please describe the exact steps to reproduce it (including every choice you make in the wizard and the screenshots of the VS window with the editor where Ctrl-Click is not working).
Hi,
Based on the information you provided via the support form, a trial has been successfully started on that computer under a different user account on 2019-06-06 14:23:36 and has indeed expired. Hence the message you are observing is by design.
Hi,
Most likely, some incomplete construct in one of the template functions in your code is triggering some bug in Clang. VisualGDB is designed to run the Clang IntelliSense in a separate process and make sure that those crashes don’t result in losing any work, but we should be also able to patch the corresponding Clang logic to fix it. Please send us a minidump file via the support interface and we will get back to you with more details.
Hi,
Normally, just adding a config file should be sufficient, however there could be several factors interfering with it. Please try reopening the solution file to reset all caches; if it doesn’t help, please check whether the new configuration entries appear in the command-line configuration interface (right-click on the project in Solution Explorer -> Open MinGW shell -> make menuconfig). If not, please check with Espressif whether the ESP-IDF version you are using requires some additional steps (or try comparing your project with one of the samples that has custom KConfig files).
If the entries appear under make menuconfig, but not with VisualGDB, please let us know your esp-idf version, your project type (Make/CMake) and the exact steps to reproduce it (if the problem can be reproduced by adding a KConfig file to a basic ledblink sample, please archive and attach the project demonstrating the issue) and we should be able to fix it promptly.
As mentioned above, this looks like an incompatibility between the OpenOCD FLASH driver and the custom FLASH programming code you are using.
As both of those components are external to VisualGDB, unfortunately is it not covered by our product support. Please consider contacting ST support for further help on this.
Hi,
The easiest way to get this to would would be to manually add the source directory containing the files to VisualGDB project properties -> Extra Source Directories.
We understand that it is an extra configuration step and will update VisualGDB to do it automatically in the next major release along with other mbed-related improvements.
