support

Forum Replies Created

Viewing 15 posts - 6,676 through 6,690 (of 7,826 total)
  • Author
    Posts
  • in reply to: Remote console window? #7246
    support
    Keymaster

    Hi,

    Please use the Debug->Windows->Remote Program Console command. Note that unless a remote debugging is active, this command will not appear.

    in reply to: VisualGDB not flashing device #7245
    support
    Keymaster

    Hi,

    Sure, please share the gdb log showing the commands VisualGDB is issuing and the GDB responses so that we could help you figure out why programming is broken.

    in reply to: Openocd jtag driver problem #7238
    support
    Keymaster

    Hi,

    The settings should normally be merged. Can you attach an archive of a sample project where the settings are not propagated properly?

    in reply to: How to update files in VS? #7237
    support
    Keymaster

    Hi,

    If the file is on Windows machine in a directory specified as the source directory via VisualGDB Project Properties, VisualGDB will transfer it automatically.

    If not, please double-check the name and location of the file and your current file transfer settings.

    in reply to: Error 'Importing Specs' #7232
    support
    Keymaster

    Hi,

    Sorry for the confusion. Did I understand you correctly that:

    • Building of your project produces a valid executable, but shows the “The system cannot find the path specified” error
    • Manually deploying and running the project works
    • Debugging your project works
    • Testing toolchain fails at the “importing specs” stage and IntelliSense does not get configured properly

    If yes, please try adding “-d” to the GNU Make arguments on the Build Settings page of VisualGDB Project Properties. This should force GNU Make to print detailed log on every action it is doing, hopefully revealing what is causing the error message.

    If the debugging actually does not start, please enable verbose mode in Tools->Options->VisualGDB->General->Tweaking, start debugging and check for detailed error messages. You can also check the VisualGDB Launcher Output in the Output pane in Visual Studio. Do any of those places contain any extra information about the problem?

     

    support
    Keymaster

    Hi,

    The VisualGDB variables are only resolved directly in command lines. Variables that are saved in Makefiles will not be resolved unless you specify them explicitly in Make command line (e.g. make SourceDir=$(SourceDir)). That said, you don’t need to use the $(SourceDir) in your settings. Simply specify the relative paths (e.g. subdir/LinkerScript.lds).

    in reply to: How to update files in VS? #7230
    support
    Keymaster

    Hi,

    There is currently no standard way of doing this, so we would recommend one of the following:

    • Use a source control system like Git or SVN to merge the changes from Linux and Windows
    • Use SmarTTY to download the entire source folder or individual files from your Linux machine
    • Add a custom shortcut via VisualGDB Project properties to download the source folder and then use the VisualGDB toolbar to invoke it quickly (requires Custom or Ultimate edition)
    in reply to: Openocd jtag driver problem #7229
    support
    Keymaster

    Hi,

    The settings from VisualGDB Project Properties are saved in debug.mak/release.mak, while esp8266.mak contains settings that are common for all configurations.

    Please double-check the settings in debug.mak and see if they are actually included in compilation command line.

    in reply to: Openocd jtag driver problem #7225
    support
    Keymaster

    Hi,

    It’s hard to guess what exactly went wrong, but reasons could vary from files simply not rebuilding to some typos in the preprocessor macros.

    We would recommend something like this:

    1. Add a static variable pre-initialized to a certain string (e.g. “test123”), use this variable from user_init() so that it gets referenced. At the same time comment out the call to gdbstub initialization.
    2. Does the binary image contain your string (test123)? If no, it did not get rebuilt properly. Note that the ESP8266 .bin images are only rebuilt when you start debugging with VisualGDB, not when you build the project.
    3. Do you still get the gdb stub message? If yes, some other code is calling it. Perhaps user_init() is defined in 2 different places and one takes precedence over the other one?

    The JTAG debugging would be held by gdbstub because gdbstub essentially installs a handler to some debug-related interrupts, then triggers an interrupt and that interrupt handler waits for a reply via the COM port. The JTAG debugger does not prevent interrupts from being handled, i.e. the stub will still catch it and start waiting for gdb to attach. Once gdb attaches, however, you can still use the JTAG debugger to see what’s going on inside the stub and inside your code.

    in reply to: Debugging impossible when timer interrupts are enabled #7219
    support
    Keymaster

    Hi,

    You can try using the OpenOCD’s “cortex_m maskisr” command to disable interrupts during stepping as described here: http://openocd.org/doc/html/GDB-and-OpenOCD.html

    However this will not work when using high-level debug adapters like ST-Link.

    in reply to: Building STemWin_HelloWorld on STM32F7 Discovery board #7218
    support
    Keymaster

    Hi,

    Looks great, thanks for sharing this!

    in reply to: Cross-compiling Qt Embedded 5.5 for Raspberry Pi 2 #7217
    support
    Keymaster

    Hi All,

    Normally you don’t need to install any new packages on your Pi as long as your ld.so.conf is set correctly and the /opt/vc directory is synchronized.

    We have added troubleshooting instructions to the step 16 of the tutorial: http://visualgdb.com/tutorials/raspberry/qt/embedded/

    Let us know if you run into further problems.

    in reply to: Openocd jtag driver problem #7211
    support
    Keymaster

    Hi,

    OK, then the problem must be elsewhere. Please double-check your FLASH type setting (dio/qio/etc) in VisualGDB Project Properties.

    Please also try manually programming the <project>-0x40000.bin and <project>-0x00000.bin files from the Debug directory using the bootloader and esptool.py.

    If the LED blinks in that case, something goes wrong with programming the FLASH over JTAG. If the LED does not blink (but blinks when you are using the GDB stub), something about the images is corrupt and the next step would be to compare the images produced when using the OpenOCD debug method with the images produced from the same ELF file when using the gdb stub.

    in reply to: Openocd jtag driver problem #7208
    support
    Keymaster

    Hi,

    If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect. Perhaps this is causing the behavior you are describing. This can be easily checked by pressing the “Break in” button in Visual Studio and examining the call stack.

    You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

    in reply to: Using the QuadSPI on STM32F7 Discovery #7207
    support
    Keymaster

    Hi,

    Please use the USBDriverTool to restore the original ST-Link driver. It also looks like the newest OpenOCD works correctly with the stock driver, so you don’t need to install the WinUSB-based one anymore.

Viewing 15 posts - 6,676 through 6,690 (of 7,826 total)