Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
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.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
March 12, 2018 at 05:26 in reply to: Make and existing Visual Studio Project a VisualGDB Project #20370support
KeymasterHi,
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).
support
KeymasterHi,
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.
March 12, 2018 at 05:13 in reply to: Trouble debugging sample kernel module (RPi 1 + J-Link via JTAG) #20368support
KeymasterHi,
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.
support
KeymasterHi,
Thanks for the suggestion, we will try to add an option for this into the upcoming v5.4. As a current workaround, please consider using the “Save semihosting output to” option on the Embedded Debug Tweaking page of VisualGDB Project Properties.
support
KeymasterHi,
It’s hard to say why the projects didn’t get imported correctly, although our STM32 support package comes with pre-imported ST samples from the original SDK packages (we have tested that each of them builds out-of-the-box). Please follow this tutorial to see how to create projects based on those samples.
support
KeymasterHi,
Thanks for the screenshot. Looks like VisualGDB might not be able to query the registers from the stub.
Please try capturing a gdb session log as described here and attach it to this thread (or send it to our support email). Please also attach a screenshot showing the context menu you see get the Registers window – it might contain useful clues.
support
KeymasterHi,
This type of issue is indeed fairly tricky to diagnose. Our best advice would be to try setting breakpoints at _exit(), ExitProcess() and below main() (see the call stack with the backtrace past main option).
support
KeymasterHi,
Strange, this should normally not happen. Could you please attach a screenshot of the entire VS window (and the context menu) illustrating this? It might contain some clues explaining what is going on.
support
KeymasterHi,
This could happen if VisualGDB could not locate the CMake target that corresponds to the currently edited source file. We should be able to investigate this further if you could share a repro project.
support
KeymasterHi,
Strange, we have double-checked this on a simple “Hello, world” program and VisualGDB actually followed the regular VS formatting setting. Perhaps something else is affecting this? Could you reproduce it in a minimal source file that doesn’t contain anything else? If not, could you please share the minimum repro case?
support
KeymasterHi,
No worries, the exact text slightly varies between different BSP versions, so that should not be a problem. Picking the right board is important though as different boards have slightly different pinouts. Normally the board number is printed on a sticker on top of the MCU (nRF52-DK should be PCA10040).
support
KeymasterHi,
If those expressions work in the watch window, the gdb stub is reporting them correctly. So you should be able to right-click in the Registers window and enable other register groups (VS only enables the basic CPU registers by default).
-
AuthorPosts