[support]

Hi,

It looks like your support period has expired a while ago. Please kindly renew it here and we will be happy to point you to the relevant documentation.

[support]

OK, thanks for you patience. We have managed to reproduce the problem. I turns out, in some cases MSBuild would not invoke the logic responsible for updating VisualGDB’s floating license state, leading to an expiration of the temporary session key.

We have fixed the problem in the following build: VisualGDB-5.5.8.3774.msi

[support]

Sorry, the line looked a bit confusing due to the comment before code.

It’s generally hard to say what would cause this, as VisualGDB would simply pass the breakpoint commands to the underlying low-level tools and would not directly control which of the breakpoints get hit.

If the optimization level is already set to -O0, our best advice would be to try switching to the disassembly mode, and experimenting with setting breakpoints there.

Also the “pill” boards often come with the Chinese clones of the STM32 chips, that do often behave unpredictably. If the problem does not happen on the regular STM32 boards, it is very likely the glitch of the chip.

• This reply was modified 5 years ago by support. Reason: updated link

[support]

Hi,

This can be caused by optimization, or the way gcc handles debug symbols. Please make sure the optimization is set to -O0 (and not -Og). You can also try adding asm(“nop”) in the empty if() branch. If this changes the behavior, it is a side effect of the way gcc emits symbols for empty branches.

[support]

Hi,

If you are new to VisualGDB, please do allocate some time to go through the documentation and tutorials (e.g. unit testing tutorial). They do show the location of all the relevant settings (e.g. see the “Recovering from assertion failures” section) and will save you considerable time if you are planning a non-trivial setup.

[support]

Thanks for sending us the screenshot (we removed it for privacy). It looks like VisualGDB is initialized correctly, so the problem is likely caused by something else.

Please try the latest development build: VisualGDB-5.5.8.3770.msi

If the problem still persists, please try checking if there is a specific project type that triggers the problem. If yes, please share the steps to reproduce it from scratch (i.e. from creating a new project) and we should be able to fix it.

[support]

Hi,

This looks like a corrupt installation. Could you please share a screenshot of the Help->About VisualGDB window so that we could check what is going on?

[support]

Hi,

It looks like your support period has expired. Please kindly renew it here and we will be happy to help you resolve this.

[support]

Thanks for pointing this out. We have updated the tutorial.

BTW, feel free to try out the new Advanced CMake subsystem for Embedded Projects (VisualGDB-5.5.8.3770.msi). It supports multiple targets per project (i.e. bootloader + main target) and allows referencing target outputs from other targets without the need to modify any files manually.

It will be included in the upcoming v5.5 RC1 and we will publish more documentation on it soon.

• This reply was modified 5 years ago by support.

[support]

Thanks, just one more question then. Did the problem ever happen on a recently started VS instance (i.e. NOT after a long period if inactivity)?

[support]

Hi,

One quick question: does the problem always happen after you let Visual Studio instance (or MSBuild) run for a long time idling, and then do a build?

[support]

Due to some internal changes in the new toolchains, they are not fully compatible with VisualGDB 5.5 Preview 7. We are running some final tests on them and expect to release the v5.5 RC1 around next week.

Update: you can try our new R7 toolchain. It includes both ESP-IDF 4.1 and 4.2 and works out-of-the-box with the VisualGDB build linked above.

• This reply was modified 5 years ago by support.

[support]

Hi,

As long as you use the TinyEmbeddedTest framework, you can set the “Redirect printf() to Test Output window” option in the Test Framework Properties and the output will then appear under the test results (Show Additional Output link). That said, make sure you don’t have multiple conflicting options enabled (see this page).

[support]

Hi,

We have briefly retested the latest ESP-IDF 4.1 with our 8.2.0-r6 toolchain (requires this build: VisualGDB-5.5.8.3769.msi) and it worked out-of-the-box (you need to use the ESP-IDF checkout selector to clone the 4.1 release explicitly).

However, it looks like the 4.2 release is now broken due to unresolved Python dependencies. We will look for a way to ship any extra dependencies together with the toolchain and will publish an update once it works reliably. In the meanwhile, you should be able to replicate the setup on your side by using the toolchain and VisualGDB build mentioned above.

[support]

Thanks, we have updated the definitions on our side and will include them in the next release of the OpenOCD package.

[Author]

Posts