Forum Replies Created
-
Posts
-
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2093.msi
It uses separate variables for gcc/g++ executables used for linking (see link.targets, e.g. GCCBinaryNameForLinking). You can now override them in your custom rule file to use xild instead.
Please note that updating VisualGDB will overwrite any changes you made to the MSBuild files; please ensure you make backups of them.
Hi,
No problem. Based on our communication with ST, they consider GPDSC to be the format used for exporting projects to 3rd-party tools and we fully support it (see our STM32CubeMX importer tutorial). Either way, we will continue monitoring the formats used by the ST project samples and will consider supporting more of them in case they change.
Hi,
If you upgrade within 1 month from your original purchase, you will pay just the price difference. If you upgrade later, the upgrade price will also include the price of extending support period (it will be set to 12 months after the upgrade).
Hi,
AVaRICE does a pretty good job for an open-source tool, so we do recommend using it. If the license of the Atmel GDB server allows using it with non-Atmel products like VisualGDB, it could be a good alternative to AVaRICE, however it might be tough troubleshooting it as it’s likely not designed to be used outside Atmel Studio.
Hi,
According to our records, the problem has been resolved, so unless you need a specific confirmation from us, you don’t have to submit another ticket.
Hi,
No problem, thanks for sharing this. For AVR devices using the Atmel gdb server could be indeed better than the open source AVaRICE tool.
Hi,
No problem. We have responded to your inquiry, however it looks like your server is rejecting emails from our ticket system:
<email> SMTP error from remote mail server after end of data: host mxbiz1.qq.com [184.105.206.87]: 550 Mail content denied. http://service.exmail.qq.com/cgi-bin/help?subtype=1&&id=20022&&no=1000726
Hi,
Please contact our support with your license key details so that we could look into this.
Hi,
Sorry, we may eventually fix this, however currently we are currently prioritizing other features over it as it requires a non-trivial backend change on our side.
Hi,
Yes, you would need to remove the calls to printf(). The easiest way to do this would be via using conditional compilation, e.g.
#ifdef _DEBUG #define LOG(...) printf(__VA_ARGS) #else #define LOG(...) #endif
Hi,
Sorry, this is a known bug caused by the internals of the Peek Definition logic and fully resolving it would involve a fairly large change on the VisualGDB side. As a workaround please try reopening the source file after the bug is triggered.
Hi,
No problem, we can help you pinpoint this. First of all, please try narrowing this down to one specific variable and a specific context. E.g. try creating a custom project where the build command will be just “echo $OPENCV_SRC_DIR”. Can you confirm that it doesn’t work when launched via VisualGDB, but works manually?
Regarding the environment fix, VisualGDB normally checks for mismatching environment each time you create a project, and then can either remember correct the per-host settings (will be shown in the SSH Manager), or add the mismatching variables to the ignore list (under Tools->Options->VisualGDB). Normally it should work intuitively, but if your variables are defined in a way that prevents VisualGDB from getting them, it might get confusing. Please try checking the variable manually as described above to narrow it down and we will help you configure VisualGDB to handle this automatically.
Hi,
Normally OpenOCD should be able to figure out the correct sectors to erase automatically. So our first advice would be to double-check what addresses are actually used by various sections of your program. Please try running arm-eabi-objdump -h <ELF file> and check what section covers the address that is erased and what attributes are set to it. If it has the LOAD attribute, you would need to mark it with the noload attribute in the linker script file.
Hi,
Sure, you can configure VisualGDB to use the Atmel gdb server as well (as well as any other IDE with GDB support), although it won’t provide many advanced features included with our OpenOCD fork (e.g. automatically resolving driver issues, profiling, monitoring memory in the background), so we normally advise getting a debug probe supported by OpenOCD and using it instead.
Hi,
The easiest way to import a generic project (based on a format that VisualGDB cannot parse directly) is to follow this tutorial. It will involve re-entering include directories and preprocessor macros manually, but will import the files automatically.
If you want to import multiple projects of the same format, please consider forking one of our open-source importing plugins. They are designed to be extremely lightweight – as long as the plugin builds the list of source files and options, VisualGDB will automatically manage the project structure and even merge the changes between the 2 projects when they are detected.
P.S. We might eventually support direct importing of SW4TM32 projects, although as the current combination of the pre-imported projects and IAR/Keil importers covers most of the scenarios, we don’t have any specific deadline for it yet.
