support

Forum Replies Created

Viewing 15 posts - 5,056 through 5,070 (of 7,541 total)
  • Author
    Posts
  • in reply to: problem importing CubeMX FreeRTOS project #11180
    support
    Keymaster

    Hi,

    Yes, sorry about that. The STM32 BSP comes with different versions of the cmsis_os.h and the VisualGDB header discovery does not go deep enough to validate them.

    Normally if you add references to FreeRTOS via the Embedded Frameworks page, VisualGDB should set the correct include directories automatically and you won’t need to fix anything manually.

    in reply to: How to add libmraa to compile process #11179
    support
    Keymaster

    Hi,

    No problem. The shared library should do as well, as long as it is always present on your target system.

    in reply to: Test program appears inconsistent #11178
    support
    Keymaster

    Hi,

    This could happen if your toolchain is not compatible with the deployment computer. Please examine the error log shown by VisualGDB for further clues (e.g. an “invalid file format” or “invalid ELF target” message would definitely suggest a wrong toolchain being used).

    in reply to: OpenOCD and LPC1549 issues #11176
    support
    Keymaster

    Hi,

    Yes, we have published a detailed tutorial last week: https://visualgdb.com/tutorials/arm/mbed/lpc1549/

    support
    Keymaster

    Hi,

    Sorry, if you want to import complex 3rd-party projects into VisualGDB, you do need to understand how to build them manually and locate/install the necessary build tools. VisualGDB can simplify a lot of the common tasks through features like automatic header discovery, but it requires understanding of the underlying build process if you want to go beyond creating & modifying basic samples that work out-of-the-box.

    Our best advice would be to check with the project vendor for specific steps required to build the project under Windows.

    support
    Keymaster

    Hi,

    This would normally indicate a problem with the project’s Makefile and selecting a different VisualGDB configuration won’t affect this.

    Please try checking if you can build the project on Windows via command line (by running make.exe manually). If not, the project’s build scripts may not be compatible with Windows and would need to be fixed before you can import the project into VisualGDB.

    in reply to: Hardware Registers & Watch1 windows greyed out. #11162
    support
    Keymaster

    Hi,

    This is actually by design and replicates the regular VS debugging experience. The watch window and hardware registers are only active when the target is stopped (e.g. at a breakpoint). To view the variables while the target is running, please use the Live Variables window.

    in reply to: Can't get J-Link to work with Olimex ESP8266-EVB #11159
    support
    Keymaster

    Hi,

    Thanks for pointing out the incorrect FLASH size. We have double-checked the Olimex board we used and it indeed has 16 megabits of FLASH, although the default 32m setting worked for us. We will investigate this further and update the tutorial. Most likely the FLASH size matters for either the ESP8266 bootloader or some part of the system library that might have been slightly different in your case.

    Regarding stepping over and breakpoints, ESP8266 as only one hardware breakpoint, so debugging experience is extremely limited. It is recommended to explicitly move all the functions that you want to debug to RAM so that VisualGDB can use unlimited software breakpoints instead. Otherwise you would need to disable all breakpoints in order to do stepping (which may still not work as the xtensa gdb often gets confused with function prologues and incoming interrupts).

    support
    Keymaster

    Hi,

    Thanks, we have managed to reproduce this. Unfortunately this is caused by a bug in VS2017 that causes random crashes after programmatically adding files and folders to Visual C++ projects.

    We have submitted a bugreport to Microsoft and are also investigating possible workarounds, but the best short-term solution would be to temporarily downgrade to VS2015.

    support
    Keymaster

    The “xxxrker.cpp has changed since last build. Doing full analysis..” message is actually misleading here. It is always shown during code completion runs (including QuickInfo).

    Feel free to try this build, it reports the reparsing events in a less confusing way: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1497.msi

    in reply to: Can't get J-Link to work with Olimex ESP8266-EVB #11155
    support
    Keymaster

    Hi,

    Unfortunately this behavior is very common with ESP8266 and ESP32. The execution simply gets stuck inside the ROM or some of the system libraries with no way of telling what is causing this.

    Our best advice would be to try different FLASH settings (size/mode/speed) and different reset modes.

    in reply to: How to add libmraa to compile process #11154
    support
    Keymaster

    Hi,

    Normally it should be as easy as adding “mraa” to the “Library names” field.

    If you get a “cannot find -lmraa” error, please try the following command line on your Edison:

    gcc -o HelloDemo Test.c -lmraa -Wl,-verbose

    Then check the verbose link log for the actual path of libmraa.a. Once you locate it, simply copy it in the corresponding directory inside your toolchain’s sysroot and VisualGDB should be able to link your program with it.

    support
    Keymaster

    Hi,

    Just to double-check: you imported the project using the “specify build command line manually” mode, correct? If yes, you should not need to adjust any include/library directories in VisualGDB Project Properties (VisualGDB should not even show them as it will simply treat the project as a black box and build it “as is” using the original command-line tools).

    If you are not sure, could you please attach a screenshot of the include directory settings that you had to edit?

    in reply to: Can't get J-Link to work with Olimex ESP8266-EVB #11147
    support
    Keymaster

    Hi,

    This could mean a missing configuration block. Please try flashing the esp_init_data_default.bin file using the serial bootloader as described here.

    in reply to: GNU vs MSbuild #11146
    support
    Keymaster

    Hi,

    GNU Make was the original build system supported by VisualGDB from the beginning, while MSBuild support was added relatively recently. Hence many of our tutorials mention GNU Make, although we actually recommend MSBuild for all new projects.

    The main advantages of GNU Make are:

    • You can build Make-based projects on Linux without VisualGDB (e.g. on a continuous integration server)
    • If you are familiar with GNU Make internals, you can easily hack Makefiles to add complex custom steps

    If none of these are relevant to you, MSBuild will be much better because:

    • It builds faster due to heavy optimization on our side
    • It allows configuring build settings in a much more flexible way.
    • IntelliSense immediately picks up changes to build settings, so you don’t need to synchronize them manually.

    There’s actually a post in our developer blog that gives an overview of the main advantages of MSBuild over the other build systems.

Viewing 15 posts - 5,056 through 5,070 (of 7,541 total)