[support]

Hi,

Please try using the “Test OpenOCD Settings” button (or installing VisualGDB 5.3 Preview 7). This should automatically fix the driver issues.

[support]

Hi,

Yes, but you would need to contact our support in order to get your previous license deactivated from our side.

[support]

Hi,

Thanks for confirming this. This could be caused by IntelliSense and the compiler using different sets of headers or different build parameters. Please let us know the type of the project (Embedded/Linux/Android) and the machine on which it is built (Windows or Linux via SSH). If you could also attach a screenshot of the problem, we might be able to diagnose it by checking for known irregularities.

[support]

Hi,

This feature hasn’t been officially announced yet and will be included in the upcoming Preview 8.

In the meanwhile you can try the following build that already includes it: http://sysprogs.com/files/tmp/VisualGDB-5.3.7.1769.msi

[support]

OK, we have finally updated our KSDK importer to work with the latest v2.1 and v2.2 KSDK releases. You can download a build supporting it here: http://sysprogs.com/files/tmp/VisualGDB-5.3.7.1769.msi

[support]

Hi,

Thanks for confirming this. We have retested it and confirmed that the exception would happen before VisualGDB asks to download the matching sources. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.7.1767.msi

[support]

Hi,

This error happens because VisualGDB cannot automatically download the source code for the system library you stepped in. If your PC does not have an Internet connection, simply choose “no” when VisualGDB suggests downloading the source code and it will show the disassembly instead.

[support]

Hi,

The virtual drive could be using a different FLASH programming mechanism (e.g. different frequency) that does not trigger the bug, so it’s hard to say what exactly happens without an in-depth analysis of what is going on with the board. As the problem looks specific to one board instance, it could be easier to simply get another one.

[support]

Hi,

Thanks for the detailed log. If the FLASH programming fails, it could be an indication of a damaged board, so simply getting a new one could be the easiest fix.

Another option would be to try using J-FLASH or other Segger-specific tools for programming FLASH and see if they report any errors when you try to program the same ELF file.

[support]

Hi,

It looks like VisualGDB sent the “flushregs” command before the last “evaluate-expression” was complete:

^done,value=”0”
-data-evaluate-expression “\$s30″
^done,value=”0”
-data-evaluate-expression “\$s31″
-interpreter-exec console flushregs
-gdb-set $r0=0x1
~”The target is not responding to GDB commands.\nStop debugging it? ”
~”(y or n) [answered Y; input not from terminal]\n”
=thread-group-exited,id=”i1″
^error,msg=”Disconnected from target.”
-gdb-set $r1=0x20003448
~”Register cache flushed.\n”

Did you have to cancel the “-data-evaluate-expression” command via the “GDB Command Taking Too Long” window? If not, it could be caused by some strange race condition and we can add soem extra logging on VisualGDB side to help you diagnose this.

[support]

Hi,

Please ensure you are using Clang-based IntelliSense. It supports GCC-specific code much better than the regular VS IntelliSense.

[support]

Hi,

We usually add official support for ESP-IDF versions within 1-2 months from their official final release date. As ESP-IDF 3.0 is not officially released yet, it’s hard to say when this will happen.

As the ESP-IDF is changing very rapidly, we have considerably simplified support for importing the projects build by ESP-IDF itself. Please see this tutorial for a detailed example of importing ESP-IDF projects.

[support]

Hi,

This looks like some sort of a networking problem. Please ensure that your computer has Internet connection and try resetting your DNS cache.

[support]

Hi,

Strange, normally the MCU.CSV file should not affect the J-Link stub (you can try removing the line from it after you edited the VisualGDB settings to be 100% sure).

Can you also confirm that the problem happens when you launch the segger gdb stub manually and connect gdb from command line? You can use the following gdb commands to test it:

gdb <elf file>
target remote :3333
load
continue

[support]

Hi,

Thanks, we have tried building and running your project on our nRF52840 board and it worked out-of-the-box.

Please check if you are using the same SDK version with IAR. If not, the latest Nordic SDK might be incompatible with the preview board and would only work with the final version of it.

[Author]

Posts