Forum Replies Created
-
Posts
-
Hi,
No problem, we will try to provide an example.
Both VisualGDB and Visual Studio distinguish between the full match and partial match (see below):
Pressing enter with a full match (A) will substitute its value. Pressing enter with partial match (B) will create a new line.
Hi,
Sorry, we currently don’t have specific plans for supporting CMake-based stand-alone Android executables. The good news is that you can easily add multiple files and subdirectories to a VisualGDB project via Add->Add Existing Item->Import Folder Recursively.
Hi,
You could try changing the file order by manually editing the .vcxproj file, however there might be other minor differences between the 2 toolchains. We would advise trying to understand the potentially impactful differences between the projects (e.g. section size/alignment) instead, as making the output 100% identical may be impossible in reasonable time.
Different mapping should not affect the “Reset_Handler” behavior. Although it might interfere with debugging (VisualGDB will try several workarounds to restore the broken mapping though), it should allow understanding whether the problem is caused by debug settings or some ELF file properties.
With the weird memory location, to answer that definitively you would need to look into the Segger J-Link stub internals to see what kind of filtering they internally use. In our experience this error message comes up frequently when starting debugging and it never interferes with the actual program flow. Also explicitly trying to read invalid memory via debugger doesn’t trigger the fault handler.
You can add the extra commands via VisualGDB Project Properties -> Additional GDB commands.
Hi,
The “breakpoint-modified” message simply means that a breakpoint was either bound or unbound when a module containing the corresponding code was loaded/unloaded. Normally it should not reduce debugging speed.
You can try enabling diagnostic GDB logs on the Advanced GDB Settings page of VisualGDB Project Properties – the advanced gdb logs contain timestamps for each line received from gdb and allow understanding the timing.
It also looks like VisualGDB is querying stack traces for all threads in your example – this could considerably slow down stepping through the code. Please try closing the “threads” window in Visual Studio and VisualGDB will only query the stack trace for the current thread.
Hi,
The “communication failure” errors almost always indicate wiring problems. Please double-check your board schematics, soldering/connections and try lowering JTAG frequency.
This could be also caused by your firmware disabling the JTAG pins at runtime. If the problem disappears after erasing the FLASH memory contents, please try using the “connect under reset” checkbox.
Hi,
Thanks for your feedback. VisualGDB tries to follow the Enter key behavior from the regular VS projects – Enter substitutes the selected suggestion if it matches the entered text (the list item will be highlighted in a solid color) or creates a new line if it doesn’t match the text (the selection will have a border around it instead of a solid highlight). You can use the ‘Tab’ key to substitute the best possible suggestion regardless of whether it matches the entered text.
Regarding formatting options, VisualGDB inherits most of the regular Text Editor->C/C++ settings that apply to the regular C++ projects (including spaces inside brackets). If it looks like they are ignored, please double-check that the regular VC++ projects have a different formatting style. If this is the case, please post the screenshot of your settings and both formatting results and we will investigate.
Hi,
Sorry, looks like the log file did not get attached. Could you please simply paste a few error messages in the post?
Most of the import-related errors arise from conflicts between the startup files used in the project and the startup files shipped with VisualGDB. If the errors mention “multiple definition of XXX”, simply looking up both files mentioned in the error and removing one of them from the project should help.
Hi,
We have long-term plans for having a special command for scanning the entire project with the code analyzer and producing a fast searchable report, however currently the built-in analyzer only works for the currently edited file by showing the warnings in the Errors pane.
The best workaround would be the solution suggested by Ophidian14 – add a custom post-build step that would invoke the analyzer. For MSBuild projects you can configure this under C/C++ settings and VisualGDB will automatically launch the step for each source file, applying the regular compiler arguments.
Hi,
Thanks for clarifying. This is supported out-of-the-box for the regular ndk-build + Make project type (can be created via the Android Project Wizard), but not yet for CMake. We would advise simply creating a new command-line Android application via VisualGDB wizard and then adding your files to the project. You can also create a unit test project from the same wizard – VisualGDB will automatically setup the unit testing framework and forward the test results from the Android device to Visual Studio.
Hi,
Strange. Could you please open the Clang IntelliSense Diagnostics Console, switch to the Project View and paste the CXXFLAGS for the project shown there? This should help understand what exact flags are fed into clang.
Hi,
As long as Eclipse and VisualGDB use different toolchains, the results might be slightly different (e.g. different optimization algorithms). Also using different input file order could affect the order of functions in the final image and might also trigger some strange bugs.
We would advise doing a quick test – replacing the ELF file generated by VisualGDB with the ELF file from Eclipse and trying a VisualGDB debug session without rebuilding. If this works, the problem is in the build settings (which is most likely, but still worth double-checking at this stage). Otherwise, it is related to debug settings.
Weird memory locations usually come from gdb doing some guessing while unwinding the stack and are usually harmless (exceptions caused by the debugger itself don’t invoke HardFault_Handler).
You can verify the FLASH automatically by adding the “compare-sections” command to the additional GDB commands in VisualGDB Project Properties or use the “Verify FLASH memory” button in the GDB Session window (this will display a detailed report on mismatches if any are found).
Hi,
The “Info : debug cause: 0x8” and other similar messages come from OpenOCD – the command line tool used for debugging; it is not directly related to the UART port output.
In order to see the UART output from esp8266, you would need to physically connect a USB-to-UART adapter to the UART pins on your module (please ensure you use a level translator, as UART and regular CMOS logic use different voltages and connecting them directly might burn one side). Once you connect it, you can see the UART output in the corresponding COM port (either via VisualGDB’s Embedded Terminal or using our free SmarTTY tool).
Hi,
OK, we have added a partial workaround to this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2009.msi
You can disable template contents indentation via Tools->Options->Text Editor->C/C++ (VisualGDB)->Formatting->Don’t indent template contents.
VisualGDB will still add indentations when you press ‘enter’ after starting a template declaration, however they will be removed once you enter the final ‘;’ or reformat the entire document via Ctrl-K, Ctrl-D.
Hi,
Thanks for the detailed description. This might be related to an OpenOCD bug in the STM32L4 driver that refuses to program some sections if they are insufficiently aligned (we were not able to reliably pinpoint it though). The file built with Eclipse shows the size of .isr_vector section to be 0x2f8, while the VisualGDB version has 0x2f4 (due to different size of mcu_cpu_systick_Handler). Please try increasing alignment of your sections and see if this works around the programming errors.
