Forum Replies Created
-
Posts
-
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.
Hi,
Yes, it is almost ready for a public preview. We are still figuring out the best way to automatically edit key variables in the component.mk files, but the rest of the functionality is working quite well. We will try to release a preview this week, although it may get pushed over to the next one if unexpected complications arise.
Hi,
The VisualGDB debug/deployment functionality depends on a few MSBuild variables that are only set by VisualGDB projects, so generally we would advise converting the project to a VisualGDB-based one. You can do this by adding the “VisualGDB” platform to it via the Configuration Manager and copying the MSBuild settings (e.g. toolchain ID and remote host) from an MSBuild project created by the VisualGDB wizard. This will preserve the file structure in the Solution Explorer, but will let you use the optimized VisualGDB build engine and debug engine for your project (as long as you have the VisualGDB platform selected).
Hi,
The examples shown in the VisualGDB project wizard are pre-imported. I.e. we imported them as a part of our BSP building process, verified that they build successfully and computed all the dependency information to ensure you can just pick it in the wizard and get it created. They won’t get changed if you download an SDK manually.
If you want to import a project from your own repository, we provide automatic importers for IAR, Keil and STM32CubeMX projects, e.g. see this tutorial. However projects imported this way might require some adjustments after importing (e.g. if the original project contained IAR-specific code).
Another option would be to use the generic importing logic – it will automatically discover and add the source files from your project directory to the VisualGDB project, but you would need to manually enter various compilation options like preprocessor macros and include directories.
Either way, the most common issue when importing projects is the conflict between the ST libraries shipped with VisualGDB and the ones that might come with the project. You can easily remove the references to VisualGDB-shipped ones via the Embedded Frameworks page of VisualGDB Project Properties, although we do recommend using the startup file that comes with VisualGDB.
If you still encounter strange errors, please feel free to attach the build log showing the exact error messages (and screenshots of the related files) and we can suggest what could be the reason behind them and how to fix it.
Hi,
This could be caused by OpenOCD not handling some memory protection-related issues. As a quick workaround please try disabling the “use helper module for listing symbols” option to revert to a slower logic of scanning the regular kernel symbols.
BTW, as VisualKernel uses OpenOCD for JTAG debugging, it should work with J-Link (we did a quick test for Raspberry Pi 3 with J-Link 9.1 and could not find any problems). Another alternative would be to get a fairly inexpensive Olimex ARM-USB-OCD-H probe – it essentially gives OpenOCD low-level control over the JTAG protocol, and hence should work with any target that is supported by OpenOCD.
