[support]

Hi,

For MSBuild projects VisualGDB stores the IntelliSense configuration in the following file:

%LOCALAPPDATA%\VisualGDB\ToolchainProfiles\<remote machine>\<toolchain ID>\IntelliSense.props

Please check the conditional definitions for the C++ standard you are using, e.g.:

<ItemGroup>
    <ClCompile Condition="'%(ClCompile.CPPLanguageStandard)' == 'CPP11'">
        <PreprocessorDefinitions>%(ClCompile.PreprocessorDefinitions);__cpp_attributes=200809;__cpp_static_assert=200410;__cpp_variadic_templates=200704;__GXX_EXPERIMENTAL_CXX0X__=1;__cpp_delegating_constructors=200604;__STDC_UTF_16__=1;__cpp_raw_strings=200710;__STRICT_ANSI__=1;__cplusplus=201103L;__cpp_ref_qualifiers=200710;__cpp_rvalue_references=200610;__cpp_rvalue_reference=200610;__cpp_nsdmi=200809;__cpp_initializer_lists=200806;__cpp_lambdas=200907;__cpp_unicode_characters=200704;__cpp_unicode_literals=200710;__cpp_range_based_for=200907;__cpp_decltype=200707;__cpp_inheriting_constructors=200802;__GNUC_STDC_INLINE__=1;__STDC_UTF_32__=1;__cpp_alias_templates=200704;__cpp_constexpr=200704;__cpp_user_defined_literals=200809</PreprocessorDefinitions>
    </ClCompile>
</ItemGroup>

You can also try deleting the file and re-opening the project. VisualGDB will then run the remote gcc and re-detect the preprocessor macros.

[support]

Hi,

Most likely your baud rate in SmarTTY settings doesn’t match the baud rate of the device. Most ESP8266 boards have the default baud rate of 74880 and most USB-to-UART adapters have a default rate of 115200. Please try setting the baud rate manually.

[support]

Hi,

Good to know it works. BTW, if you miss any other features of the Custom edition, you can always upgrade here: http://sysprogs.com/splm/mykey.

[support]

Hi,

Normally the output from the ESP8266/ESP32 programs is directed to a serial port, so in order to see it you would need to use the raw terminal feature (requires the Custom edition or higher). If you are using a lower edition, please try using our free SmarTTY tool instead to view the output from the COM port.

[support]

Hi,

Thanks for letting us know. If you encounter further errors, feel free to create another topic.

[support]

Hi,

Please try adding the .natvis file directly to your VS project (via right-click->Add->Existing Item). This should help VisualGDB recognize it.

[support]

Hi,

The .bin file generated by VisualGDB should be the correct one. Furthermore, once you start a debugging session, the firmware is actually programmed into the FLASH memory in order to be debugged.

Most likely your code is using semihosting-related functionality (e.g. calling printf()) that are intercepted under debugger and cause the program to wait for a debugger to attach otherwise. The easiest way to figure out what is going on is to use the Debug->Attach to Running Embedded Firmware command (requires VisualGDB 5.3+).

[support]

Hi,

Looks like your program is missing the ‘airkiss_lan_pack’ function that is normally defined in libairkiss.a. Please try adding “airkiss” to the “library names” field in VisualGDB Project Properties.

[support]

Hi,

Please use the via Debug->Windows->Registers command to view the CPU registers.

[support]

Hi,

Sorry, as we don’t have an STM32l443RC  board here, we would be able to reproduce it/confirm the fix, hence we won’t be reporting this to OpenOCD.

Please consider reporting this via OpenOCD mailing lists as described here: http://openocd.org/doc-release/doxygen/bugs.html

Please also try our latest update to the OpenOCD package. It may already include the fix.

[support]

Hi,

You might be missing extern “C” around your interrupt handler. Please also note that our support is limited to issues related to VisualGDB. For general programming problems and troubleshooting issues with your code please use other resources like StackOverflow to get help from other community members.

[support]

Hi,

Thanks for reporting this. It looks like an OpenOCD bug, so we usually rely on the OpenOCD community to fix those.

As a workaround please try adding command to erase FLASH in to the additional gdb commands in VisualGDB Project Properties.

E.g.:

mon flash erase_sector …

You can find more about OpenOCD FLASH-related commands here: http://openocd.org/doc/html/Flash-Commands.html

[support]

Hi,

Sorry, the logs you attached unfortunately don’t show any timing. You can enable generation of timestamped logs via VisualGDB Project Properties -> Advanced GDB Settings -> Save all low-level interaction with GDB.

Please also try using this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.14.1892.msi

It resolves another issue related to Segger GDB stub and might solve the performance issues you are encountering as well.

[support]

Hi,

Thanks, looks like the ‘connect under reset’ indeed doesn’t work on STM32F7. We have fixed this in the upcoming update to the OpenOCD package.

As a workaround, please try changing the following line in stm32f7x.cfg:

reset_config srst_only srst_nogate

replace it with the version from F4X:

reset_config srst_nogate

Then VisualGDB will recognize it and show the “connect under reset” option.

[support]

Hi,

Sorry for the confusion. Changing the location of the main memory to SDRAM would not work as your firmware would need to use the memory for the stack before it can initialize the SDRAM controller.

If you want to make the malloc()/free() functions use SDRAM instead of the regular SRAM, please add an implementation of the _sbrk() function similar to the one described in this tutorial: https://visualgdb.com/tutorials/arm/newlib-nano/

Instead of returning the area between the _end symbol and the stack pointer, change the implementation so that it will return the memory between the start and end of SDRAM.

[Author]

Posts