[support]

Hi,

We usually update the BSPs quarterly, so the next update will be released within the next 1-2 months.

[support]

Hi,

Thanks for confirming this, we will note down that TUMPA is compatible with ESP32.

Regarding single-core mode, you can actually try editing the <SysGCC>\esp32\esp32-bsp\OpenOCD\share\openocd\scripts\target\esp32.cfg file (uncomment the set ESP32_ONLYCPU 1 line), although we have not fully tested this mode and it may result in strange bugs.

[support]

Hi,

Please ensure you are using the MSBuild subsystem (not GNU Make). Then you can use the regular VS properties for individual files or groups of files to edit various settings.

[support]

Hi,

This happens because once you hit ‘Step over’ or ‘Step in’, an interrupt occurs and OpenOCD is trying to step over the interrupt handler to get back to your code.

You could try disabling this behavior by temporary setting the ‘$PRIMASK’ register to 1 via the Watch window and then stepping. However this will delay the interrupt handler until you set PRIMASK back to 0, so some buffer overruns/underruns may occur.

[support]

Hi,

This could be caused by the ESP32 configuration, or by incompatibility with TUMPA (we do not officially support it and have not heard of anyone successfully using it). The easiest way to get it to work would be to get the same hardware as shown in our tutorials and ensure your wiring 100% matches the one shown there. Once you get it to work, it would be easier to switch the debug adapter (or the ESP32 board) and quickly pinpoint what exactly is causing the problem.

[support]

Hi,

Yes, please try adding “compactcpp” to the list of library names in VisualGDB Project Properties. This should be equivalent to checking the “reduce size of C++ binaries” checkbox.

• This reply was modified 8 years, 1 month ago by support.

[support]

Hi,

According to the log, it looks like the program exits with an error code. Please try checking whether it prints any error messages (in the “gdbserver” part of the log), like “cannot open display” or “cannot load library”.

[support]

Hi,

You can do that by opening Debug->Windows->Visual Watch (not Live Variables), adding “Foo” to the visual watch list, right-clicking on it and selecting “export data”.

[support]

Hi,

This may happen because the default implementation of printf() in the newlib-nano library does not support floating-point numbers. Please try explicitly switching to the “newlib-nano with floating-point support” via VisualGDB Project Properties.

[support]

Hi,

We have thoroughly tested VS2017 with VisualGDB and aside from the crashes that happen when importing large projects (confirmed by MS, fix scheduled in VS15.3), it works. Feel free to share the details of the errors you get and we will help you resolve them.

[support]

Hi,

As Clang is not widely used for embedded targets yet, any custom build we would make would likely trigger lots of bugs that are not otherwise triggered with regular Clang targets. Hence you can try building it from sources at your own risk (VisualGDB should recognize it as a proper toolchain), however we won’t officially support it until it becomes more popular.

[support]

Hi,

Just to clarify: does this happen when building, or is it an IntelliSense-only issue? In the latter case, please try opening VisualGDB Project Properties and regenerating MSBuild-related files on the MSBuild Settings page (if you are using MSBuild).

[support]

Hi,

One big cause of tricky problems could be this one:

warning : Found a source file with spaces in the path: “C:\Users\Raivis-STROPS\Desktop\power board kods\Power_board_V1.7\..\..\..\..\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32F0xxxx\StartupFiles\startup_stm32f030xc.c”.

GNU Make really doesn’t support paths with spaces, so this may cause very strange bugs. Other than that, please try opening VisualGDB Project Properties and changing the MCU type back and forth. This should force VisualGDB to regenerate the relevant parts of the project.

• This reply was modified 8 years, 1 month ago by support.

[support]

Hi,

You are welcome. It is a part of the VisualGDB design philosophy to allow tweaking and customizing the parts that may not work out-of-the-box, so that our users could get convenient experience even for rare scenarios that we don’t support directly. Our AVR support package is also open-source, so feel free to check it as a reference if you decide to customize further features.

You are also welcome to post any issues you encounter here and although we don’t guarantee seamless out-of-the-box operation for AVR devices, we should be able to suggest reasonable workarounds.

[support]

Hi,

Thanks for clarifying this. Just to confirm, you are not looking into exporting historical data, but rather a contents of a large array, right?

[Author]

Posts