support

Forum Replies Created

Viewing 15 posts - 5,446 through 5,460 (of 7,816 total)
  • Author
    Posts
  • support
    Keymaster

    Hi,

    Sorry for the confusion here. The variables like ${PROJECT_SOURCE_DIR}  are expanded by CMake, but only during build. To optimize debugging performance, VisualGDB only expands VisualGDB-controlled variables (like $(SourceDir)) in various VisualGDB-related settings. The “$(SourceDir)/Debug/src/libraspicam.so.0.1” path actually needs to be specified manually (please see the step 26 in the tutorial).

    You can deploy the library to /usr/lib by changing the “deployment path” setting on the Debug Settings page of the library project. Please note that this won’t work unless you explicitly grant write permissions to /usr/lib to the current Linux user.

    A simpler alternative could be to add the deployment folder to the LD_LIBRARY_PATH variable (see the Debug Settings page of VisualGDB Project Properties of the debugged executable).

    in reply to: Configurations other than Debug and Release #10839
    support
    Keymaster

    Hi,

    Looks like you are referring to an embedded project then. You can create other configurations for this type of projects as long as you use the VisualGDB Project Properties dialog for it instead of the regular VS Configuration Manager. If this does not work, let us know the details and we will help.

    in reply to: Configurations other than Debug and Release #10835
    support
    Keymaster

    Hi,

    VisualGDB does support other configurations, but the underlying build system (e.g. CMake) may impose certain limitations. Which project type/build system are you using?

    in reply to: Problem trying to update VisualGDB 5.1 to 5.2 #10833
    support
    Keymaster

    Hi,

    This could be some sort of a conflict between VisualGDB and VisualKernel. Are you using the latest VisualKernel 2.1r2? If not, please try checking if updating it solves the problem.

    in reply to: Support for STM32L496xx #10832
    support
    Keymaster

    Hi,

    We will rebuild the OpenOCD from the latest Github sources in the next month, so if the fix is already there, it will be included.

    We usually don’t add support for new devices to OpenOCD ourselves as the OpenOCD maintainers usually do that anyway, so if the support is not there yet, patching it manually (it’s usually straight-forward) could be the easiest way to get it to work.

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

    Hi,

    Looks like the _estack used in the latest log is valid: when VisualGDB writes a random value just before the end of the stack, it is read back correctly:

    [   25566 ms] ^done,name=”var1″,numchild=”0″,value=”0x39ddb05d”,type=”void *”,has_more=”0″
    [   25567 ms] -var-assign “var1″ 0x4847923d
    [   25631 ms] ^done,value=”0x4847923d”
    [   25631 ms] -data-evaluate-expression “\*\(\(void\ \*\*\)0x2003ffc\)”
    [   25648 ms] ^done,value=”0x4847923d”

    Hence the problem must be caused by something else. Could you try setting a breakpoint on the Reset_Handler() function and stepping through it to see which part causes the exception?

    Unfortunately we would not be able to reproduce it on our side, as we don’t have an LPC1549  board.

    in reply to: Linking fails – mysql #10830
    support
    Keymaster

    Hi,

    Looks like libmysqlcppconn.so is corrupt or taken from an incompatible system. Please double-check the file and try reinstalling the package that provides it.

    in reply to: Olimex ESP8266 flashing issue #10825
    support
    Keymaster

    Hi,

    No, that should be sufficient. VisualGDB will warn that the stub is not included and the debugging won’t work, but if you ignore the warning, the programming will still succeed.

    You can also use the ESPImageTool.exe from the toolchain directory to program the binary directly.

    in reply to: Olimex ESP8266 flashing issue #10823
    support
    Keymaster

    Hi,

    If you are using the GDB stub, it will wait for the debugger to connect after each restart, i.e. the device won’t start without a debugger until you disable the gdb stub.

    in reply to: Problem trying to update VisualGDB 5.1 to 5.2 #10821
    support
    Keymaster

    Hi,

    Please check the ActivityLog.xml file mentioned in the error message for detailed error records. This should explain why VisualGDB is not initializing.

    Either way, please try reinstalling VisualGDB as it would repair any corrupt files.

    in reply to: Olimex ESP8266 flashing issue #10820
    support
    Keymaster

    Hi,

    Unfortunately the ESP8266/ESP32 devices are not very reliable and often behave unpredictably. We could quickly check if your firmware works with our Olimex ESP8266-EVB to see if the problem is in the board or in the firmware. Feel free to archive your project (with the binaries) and upload it to a file hosting so that we could check it.

    in reply to: Intellisense performance (part 2) #10816
    support
    Keymaster

    Hi,

    Thanks, we will update this post once the support for handcrafted PCH file is available. In the meanwhile feel free to attach the logs from the Clang IntelliSense Diagnostics Console showing the slow parse and we can advise you on possible workarounds (it usually happens then VisualGDB fails to cache rarely modified parts of the files properly).

    support
    Keymaster

    Hi,

    No problem. If you are using MSBuild, you can use the regular VS Project Properties as well. For other build systems like GNU Make the VisualGDB Project Properties will be the right place to go.

    in reply to: MCU flash/ram size incorrectly reported. #10814
    support
    Keymaster

    Hi,

    It depends on what your goal is. The values in the XML file are copied from the default values for your MCU when you convert the project to a stand-alone one. They are propagated to the actual Makefile (or MSBuild property sheet file) once you change settings on the first page of VisualGDB Project Properties.

    If you are not sure, we would recommend checking in the entire project to a source control system like git or SVN and then changing the parts that look suspicious and observing the outcome. You can also just change the FLASH/RAM Size/Base. Those settings are only used in GUI hints and the memory explorer and don’t directly affect compilation.

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

    Hi,

    Thanks for the updated log. The stack address now looks writable, so the problem must be caused by something else. It could be memory corruption somewhere in your code, or a hardware problem.

    Can you reproduce the same behavior with the basic LEDBlink project or does it work as expected?

Viewing 15 posts - 5,446 through 5,460 (of 7,816 total)