[support]

Hi,

If you are using conditional directives in your Android.mk, VisualGDB won’t detect them automatically.

The easiest way to handle this would be to specify those directories manually on the IntelliSense Settings page of VisualGDB Project Properties.

[support]

Hi,

Sorry for the confusion. We do have separate tutorials for Angstrom-based and Debian-based images for Beaglebone. Please let us know which one you are using so that we could point you to the correct one.

It could have also happened that the Beaglebone image you are using contains a breaking change that prevents VisualGDB from doing the automatic setup. If you could point us to the image and let us know the problem you are experiencing, we will gladly update the tutorial and release a hotfix.

[support]

Hi,

Deleting the registry key would also break some context menus like “Create ISO from folder”.

It looks like we have found and fixed the problem. Could you try this build: http://sysprogs.com/files/WinCDEmu/WinCDEmu-4.1.exe?

[support]

Hi,

Good to know it works now. If you encounter this problem again, please attach a screenshot of the error showing the exact command you are using and SmarTTY output. This should help understand what could be causing it.

[support]

Hi,

Yes, please try experimenting with the flash size, speed and mode. Unfortunately there is not much documentation available from Espressif, so it’s hard to say which exact settings will work with your board.

Was the board working before with VisualGDB? Does it work with the bootloader now? Some users reported that that some of the boards come with very low-quality SPI FLASH that dies after less than 10 rewrite cycles.

[support]

Hi,

Does the correct firmware start now if you manually restart the board? I.e. does the program happen during debugging only or does the programming fail?

[support]

Hi,

Normally, tracepoint_probe_register() should be defined in source/kernel/tracepoint.c. Is your kernel patched to exclude it? Does it show in /proc/kallsyms?

[support]

Hi,

This looks like a VisualGDB bug. Switching between the IntelliSense engines resets everything, so if the IntelliSense got stuck in some strange state, this would certainly reset it. However, we would need to know more in order to pinpoint it.

Can you give an example of what happens when a class stops being recognized? Ctrl-Space lists other classes, but not this class? It stops reacting to changes? IntelliSense stops working completely? Are there any messages in the Clang IntelliSense diagnostics console?

[support]

You can add something like “MYVAR=1” to the ndk-build command-line arguments and then check it from your Android.mak:

ifeq($(MYVAR),1)
LOCAL_CFLAGS += -DTEST
endif

Let us know if you need more details.

[support]

Hi,

Currently this is a bit not straight-forward with Segger. Please edit the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\edp.xml file by removing the “load” command from GDBStartupCommands. We will add a configurable option to disable it in one of the next releases of the debugger package.

[support]

Hi,

Does it happen when you hit Ctrl-F5, or when you launch it manually on Raspberry Pi via SSH? Do you have any special environment/command-line arguments set? Does the deployment directory path contain any special characters?

[support]

Hi,

This can be just some random ESP8266 glitch. Normally unplugging everything and replugging it back solves the problem.

[support]

Your understanding of the startup sequence is correct. You can actually explore it visually it using Code Map if you are using the Clang IntelliSense:

First, the Reset_Handler from startup.c gets invoked. Startup.c files is actually generated from the .s files and should be 100% compatible with them (i.e. use same vector names). We use the .c files instead of the original .s ones to support advanced features like DEBUG_DEFAULT_INTERRUPT_HANDLERS and also to make things more uniform across different architectures.

The startup.c code does indeed copy the data section and erase the bss section. Then it calls device-specific initialization from the system_xxx.c file that is copied to your project folder and can be modified separately from other projects. If you just want to change HSI_VALUE/HSE_VALUE, you can edit the stm32fxxx_hal_conf.h for HAL projects or define HSE_VALUE via Preprocessor Macros in VisualGDB Project Properties for StdPeriph projects. For more complex changes, you would need to edit the system file. We would normally recommend switching to the STM32 HAL and then using the STM32CubeMX generator to generate the startup code automatically. If this is not an option, please replace your system file with a file from STM32 StdPeriph examples that matches your board configuration the best.

 

[support]

Hi,

Looks like the absolute Windows-style path got hardcoded into your application. Please try specifying the library name/directory separately in your linker arguments, i.e.:

-LC:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\opt\Iddk2000_3.3.0_ERelease_C++_Raspbian\sdk -lEIddk2000

[support]

Which board are you using? What happens if you then unplug the board and plug it back? Does the new program start normally, the old program start normally, or does nothing happen at all?

[Author]

Posts