Forum Replies Created
-
Posts
-
Hi,
Please find the answers to your questions below:
- You can copy the HAL to your project folder by converting the project to a stand-alone one (requires Custom edition).
- You can create project templates with custom folder structures via the template mechanism
- VS IntelliSense is not designed to handle the GCC-specific language extensions, so it works less reliable than the Clang IntelliSense that is designed specifically for this purpose. You could try locating the parts of the code that are causing the errors (e.g. unrecognized special keywords) and adding workaround definitions (like #define <unrecognized keyword> <empty string>) there, but normally we advise using the Clang IntelliSense as it solves this type of problems by design.
With dark theme, we are gradually switching the VisualGDB GUI to the new WPF framework that handles the VisualGDB theme colors automatically. Currently all the tool windows are following the dark theme colors, although most of the popup windows don’t do that yet.
Hi,
We have recently fixed a similar problem in our development branch. Please try this build to see if it solves the problem: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1554.msi
If not, please let us know what type is shown for those variables in the Watch window (VisualGDB uses it to determine the correct format).
Hi,
When using quick debug, are you running gdb on the device? If yes, this could be a compatibility issue between the gdb and gdbserver. Please try using gdbserver from the original Beaglebone image or building a cross-gdb for Windows based on the same sources that were used to build gdbserver in your image.
Hi,
The GCC’s STL implementation is indeed not very well optimized, so printf() is a good alternative.
BTW, you can use the dependency view in the embedded memory explorer to quickly see what pulls the large functions in: https://visualgdb.com/tutorials/arm/dependencies/
Hi,
Thanks, this actually looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1554.msi
Hi,
This could be caused by power or connectivity issues. Can you reproduce the same behavior with the “Blinking LED” project created by VisualGDB?
Hi,
This could have something to do with the signal handling on the Linux side (incompatible combinations of gdb/kernel/libc). Please try checking if you can force the application to stop via “killall -s INT <application name>”. If yes, you can configure VisualGDB to use this command instead of the regular break-in mechanism via the Custom Debug Steps page (requires Custom edition).
Hi,
The exact FLASH programming sequence is actually handled by gdb and the underlying gdb stub (e.g. OpenOCD). We are somewhat reluctant to change the OpenOCD programming logic as that could introduce bugs and break backward compatibility, so we could advise one of the 3 options:
- Try using Segger J-Link. Their gdb stub is optimized much better than OpenOCD.
- Try hacking OpenOCD at your own risk.
- Instead of embedding the version into the ELF file, save it to a separate file and program it using an OpenOCD command. You can add OpenOCD commands to the “Additional GDB Commands” page of VisualGDB Project Properties as long as you prefix them with “monitor” (e.g. monitor flash program …).
Hi,
If your sysroot contains different versions of system libraries than the toolchain does, the compiled code may not work on the device. Please use the system image listed under “compatible image” for the toolchain you are using here: http://gnutoolchains.com/beaglebone/
Hi,
Sorry, our open-source BSP tools are completely “as is” and don’t come with any tutorials or guarantees. Normally it should be sufficient to open the main .sln file and run the generator exe, but you may need to edit the sources to adjust some paths or settings.
Hi,
OK, this indeed looks like a break-in problem. Please try checking whether this behavior is consistent for all programs on the same Linux machine or if it is specific to one project (or one library used by the project).
Hi,
The unknown code address could be an interrupt handler from the prebuilt esp8266 libraries. Generally, it is possible to do the proper stepping given one hardware breakpoint, however the corresponding part of the the xtensa gdb is very buggy and often gets confused. The reason why this functionality works out-of-the-box for ARM devices is that ARM has been around for decades, so the underlying tools have matured to handle common scenarios flawlessly. ESP8266 is based on a much less popular CPU architecture, the corresponding low-level tools are less developed and behave more sporadically.
Our primary goal with ESP8266/ESP32 is to keep VisualGDB affordable to the hobbyist community, that are the primary users of those devices, so we don’t go very deep in fixing the toolchain issues, instead providing a user-friendly layer on top of the tools. The unfortunate disadvantage of this is that VisualGDB inherits many of the ESP8266 gdb bugs until Espressif fixes the underlying tools.
We are also considering a crowdfinding campaign to fix the most annoying issues in the low-level open-source tools (keeping the fixes open-source of course), but currently it is hard to provide any specific timeframe estimates on that.
Hi,
If your code explicitly manipulates CPU sleep states and power-related registers, you may need the “connect under reset” option as described in the tutorial. If you are not sure, we would suggest editing the OpenOCD scripts as described in the tutorial and checking if it solves the problem.
