[support]

Sorry, trying to assume the new value instead of verifying a stable value would break the current I2C parsing logic. We might be able to add an option for this in one of the future releases, but we wouldn’t promise it currently.

As a quick-and-dirty workaround, please try selecting a several clock cycles in the SCL signal and clicking the clock pulse icon. This will print the stable values of the SDA signal, making it easier to read.

[support]

Thanks for the detailed explanation. Unfortunately, it still doesn’t make full sense. Pressing backspace in the context of the “tab-not-working-1.png” screenshot would delete the ‘/’ character at the end of the /* USER CODE END Includes */ comment. This should not be affected by the tabs settings.

Generally, if you have generated a .c/.cpp file using STM32CubeMX, it will contain the tabs or spaces depending on the STM32CubeMX settings, not VisualGDB settings.

The VisualGDB settings for tabs and spaces will apply when adding new lines to the files, but it will not automatically replace them in existing files, to avoid unnecessary changes.

You can somewhat override it by removing all indentation (Ctrl-A to select the entire file, then press Shift-Tab several times) and reformatting the document using VisualGDB (Ctrl-K, Ctrl-D).

[support]

Hi,

If the load command erases the bootloader, the file you are programming might contain some data in the bootloader regions. You can double-check it via the Embedded Memory Explorer, and also by looking at the output from the “load” command.

If you can confirm that the ELF file does not have any data there, but the ‘load’ command still erases it, please indeed check with Segger, as their gdb stub is handling the low-level FLASH programming behavior.

The FLASH protection bits are specific to each device family and are usually described in your device’s datasheet. Please refer to the device documentation/datasheets for more details on them.

If nothing helps, please check if you can program just the correct part of the memory using some command-line tools (e.g. Segger or ST-Link). If this is the case, you can disable the memory programming via VisualGDB Project Properties -> Debug Settings and then run the custom command-line tool before debugging via VisualGDB Project Properties -> Custom Debug Steps.

[support]

Hi,

VisualGDB supports all debug interfaces supported by the OpenOCD tool, including ST-Link v3. If it doesn’t work, please make sure you use the latest VisualGDB 5.5 Preview 4 and install the latest OpenOCD package via Tools-VisualGDB->Manage VisualGDB Packages.

[support]

OK, we have investigated the problem. It looks like the I2C peripheral you are using is doing the clock stretching and it releases the SCL clock at the same time as pulling SDA down to acknowledge the transmission:

At least, at the current sampling frequency, it looks like SDA changes exactly at the rising edge of SCL (when it should be stable), so Analyzer2Go aborts the I2C parsing.

Our best advice here would be to try using a faster board (e.g. CYUSB3KIT) that will be able to tell the difference between the times when SDA and SCL change.

P.S. Although it doesn’t fix this issue, we have improved our I2C parser in the following build: Analyzer2Go-2.1.0.21.msi . It now supports 10-bit addressing mode and works better for zoomed-out signals.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Sorry, unfortunately it’s hard to tell how to reproduce the problem based on your description.

Please describe it using the recommended 3-step format (including the screenshots of all relevant settings) so that we could follow exactly the same steps on our side and reproduce it.

[support]

The automatic library discovery is indeed not recursive, so if the added library depends on pthread, VisualGDB would only suggest adding pthread when you build the project again (and the build fails due to missing pthread functions).

There also might have been a confusion between pthread and the asan library that provides similar functions, but is intended to work as a diagnostic layer on top of pthread. We have updated VisualGDB internally to hide the confusing asan/lsan libraries when searching for pthread symbols and only suggest the pthread library itself. Until we release the next preview build with this fix, please make sure you select the pthread library when VisualGDB suggests several libraries resolving pthread symbols.

[support]

It looks like your support period has expired. Please renew it here: https://sysprogs.com/splm/mykey

[support]

Sorry, this looks like an issue of a specific ESP-IDF version and not something specific to VisualGDB. Please try building the project manually per ESP-IDF documentation and check if the problem persists.

If the project can be built outside VisualGDB, but doesn’t build with VisualGDB using the same toolchain/ESP-IDF/settings, we can help you configure VisualGDB to replicate the manual build results.

[support]

Hi,

Please refer to the following page: https://visualgdb.com/support/idfcheckout/

[support]

Thanks for your feedback.

Regarding the performance, most likely you are using a different build system and a different programming method (e.g. CMake vs. GNU Make and Serial port vs. JTAG). VisualGDB supports both build and both programming methods, and as long as you are using the same method with both IDEs, the build performance should be the same. Also MinGW-based toolchains are much faster than Cygwin-based toolchains, so please make sure you are using the same toolchain in both cases.

[support]

Hi,

Normally, the Segger J-Link software should only erase the affected FLASH pages, so please double-check your ELF file layout via View->Embedded Memory Explorer.

If it doesn’t help, please follow the steps below to diagnose the issue:

1. Disable the FLASH memory programming via VisualGDB Project Properties -> Debug Settings.
2. Program the memory via an external tool and verify that both parts have been programmed.
3. Start a debug session with VisualGDB (it should not re-program the FLASH memory).
4. Verify that both bootloader and main application’s areas have not been erased by running “x/10x 0x<ADDRESS>” in the GDB Session window.
5. Run the “load” command in the GDB Session window and check its output. Once the loading completes, check whether the entire FLASH memory has been erased again.

If you can confirm that the “load” command erases the entire FLASH memory, please check your FLASH protection bits, and also check with Segger support (there might be a J-Link setting controlling the FLASH erasing logic). If running the “load” program does not erase the entire memory, please create a full gdb session log and we can help you find commands that could be erasing the FLASH memory.

[support]

Thanks for the suggestion. We are currently experimenting with a new CMake-based embedded project subsystem that is more flexible than the existing MSBuild-based one, and will try to include support for target-specific configuration for embedded frameworks in it.

As a short-term workaround, please consider cloning the Fixed Stack-Heap framework and placing it under %LOCALAPPDATA%\VisualGDB\EmbeddedEFPs under a new ID/name (see how the profiler framework is defined for a quick example). Then you can remove FIXED_STACK_SIZE=$$com.sysprogs.bspoptions.stackheap.stacksize$$ from the AdditionalPreprocessorMacros element and instead define it via regular per-configuration project properties.

[support]

Sorry, this is a known limitation of the advanced semihosting. It works by continuously polling a designated memory area (semihosting buffer) to detect when new data is written there, and it won’t work if that area is moved during runtime (that would happen when transitioning from the bootloader to the main application).

As a workaround, please consider using the regular semihosting from the bootloader, and the advanced semihosting from the main program.

[support]

Normally, VisualGDB would automatically discard the saved window positions when the screen layout changes. If not, we should be able to fix it.

First of all, please try the following steps to verify that the problem is related to the multiple screens:

1. Verify the VisualGDB Project Properties are broken.
2. Close all VS instances.
3. Delete the %LOCALAPPDATA%\VisualGDB\GUIPreferences.xml file
4. Start VS again and verify that the VisualGDB Project Properties work.

If deleting the GUIPreferences.xml file solves the problem and the problem happens again, please share the contents of GUIPreferences.xml:

• Before you delete it (i.e. when it contains invalid settings).
• After it is recreated next time you use it (i.e. when it contains valid settings).

[Author]

Posts