[support]

Hi,

As the AVR devices are much less popular than ARM-based devices, and rely on a relatively unreliable open-source tool (AVaRICE), our support for them is very limited.

You can find detailed instructions for debugging AVR-based Arduino projects here, however many advanced functionality, such as unit tests will not work.

The missing avr-gdb error happens because the Arduino core for AVR does not include gdb. VisualGDB can automatically work around it when using our built-in AVaRICE wrapper, but won’t do it for custom setups. The easiest work around would be to copy avr-gdb from either our AVR toolchain or your build of gdb to the directory shown in the error message. Another option would be to override the path to gdb executable via VisualGDB Project Properties -> Embedded Debug Tweaking.

[support]

Hi,

Fully compensating for the single-step overhead could be trickier that it may seem, as the overhead would depend on the internal implementation of the debug stub (e.g. OpenOCD) and may vary between different cores and things like interrupt level. Also events like skipped conditional breakpoints would considerably skew it.

The main use case for Chronometer is comparing different versions of the code, or different code paths. As the same overhead is added to both compared options, it will not affect the difference between them, and the effect of it on the relative difference will be negligible in most cases.

Either way, the Chronometer rules are stored in <VisualGDB directory>\TickCountExpression\DWT.xml file. You can subtract any arbitrary constant from the TickCountExpression to achieve the effect you described (since TickCountResetCondition is 1, the tick counter is always reset after it has been queried).

[support]

Our regular licenses are activated per seat. The activation is permanent, so it will work without Internet connection as well.

If you have specifically requested to switch your license to a floating license, it will require continuous Internet connection. It will update the session state once every several minutes. If our server is unreachable during 2 or more attempts to update the key, VisualGDB will stop working and you would need to restart Visual Studio. Again, this only applies if you have specifically requested a floating license.

According to our records, the license associated with your email address is not a floating license. Hence it uses permanent activation and will not require Internet connection afterwards.

[support]

This is correct. If the Internet connection goes offline, the floating license will stop working.

We understand your concerns, however we are not able to offer any other licensing schemes other than floating and seat-based.

[support]

This is done to ensure fair use (otherwise one could backup the previously issued activation key and restore it after a deactivation has been completed).

If you would like to use the same license from multiple computers, we can gladly switch it to a floating license that tracks simultaneous active sessions instead of activations (requires continuous Internet connection). Please contact our sales if you would like to do that.

[support]

Hi,

This looks more like a broken board than anything else. You can try erasing the FLASH memory and programming the image using the Nordic JTAG tools to see if there is any difference.

If it still doesn’t work, please try modifying one of the Nordic samples from their SDK to work with your board, and then build it using the original Make scripts and program it outside VisualGDB. If that works and an equivalent project built with VisualGDB doesn’t, please try comparing their memory layout via Memory Explorer. Most likely, some fine setting, like memory size or some peripheral configuration, is off.

[support]

Hi,

VisualGDB itself does not provide any special commands for programmatically dumping the memory, however you might be able to achieve this via gdb commands (since it’s not a VisualGDB feature, the specifics are not covered by our technical support, but we can do a detailed research and share detailed instructions via our consulting track if you prefer).

On the VisualGDB side, you can issue GDB commands via the GDB Session window, or create your own gdb scripts (e.g. with actions bound to breakpoints) and load them by adding the “source” command to VisualGDB Project Properties -> Additional GDB Commands.

You can also try using the Embedded Integration Tests. They support running arbitrary gdb commands.

[support]

Thanks, we have added it to the backlog and will try to address it in one of the next releases.

[support]

Hi,

Unfortunately, we were not able to reproduce the problem based on the description you provided.

In order for us to diagnose it further, please provide a clear description of steps we could follow on our side to reproduce the issue, according to our problem reporting guidelines.

[support]

Hi,

Sorry, this also doesn’t look like a VisualGDB-specific issue, but rather a problem with a specific computer. Please try creating and building an equivalent CMake-based project on it manually. If the project builds successfully outside VisualGDB, but causes errors when building with VisualGDB, we can help you replicate the manual build results. Otherwise, the issue is not caused by VisualGDB and is out of VisualGDB’s control.

[support]

Thanks, we have confirmed that gdb indeed unexpectedly disables conditional breakpoints that were set in a shared library prior to its load. As this is a bug in gdb, rather then VisualGDB itself, we can offer one of the following workarounds:

• You can try enabling all breakpoints by issuing the “enable” command via the GDB Session window after the library has been loaded, or by using the Breakpoints window in Visual Studio.
• You can also try using Python scripting to respond to breakpoint change events and reenable them.
• If your company purchases 5 licenses or more (or if the issue starts affecting a customer with 5 or more active licenses), we can add a special workaround to this on the VisualGDB side. The workaround will automatically detect breakpoints that have been disabled by GDB without VisualGDB asking for it, and will manually reenable them. This will imply using the stop-on-solib-events option.

[support]

Hi,

Normally both options should work the same way. Please try double-checking whether the LEDs start blinking after you power cycle the board after it has been programmed.

[support]

Hi,

This looks like a bug in a specific toolchain, rather than a VisualGDB issue. We can gladly help you find the root cause and devise a workaround, however as the issue is not in VisualGDB itself, we would have to charge a consulting fee for this work. Please contact our sales for a quote if you are interested.

[support]

Unfortunately, as you have not attached the full log, it’s hard to say what exactly is going on. Can you confirm that breakpoint #4 is created with enabled=”y” and then switches to enabled=”n” without VisualGDB issuing any breakpoint-related commands?

Regarding the second issue, could you please share the example C++ code and specific natvis file so that we could reproduce the issue on our side? Otherwise it’s hard to say what is going on.

[support]

Thanks for the update. We have rechecked everything and found a possible cause for the issue. Please try this build: VisualGDB-5.5.103.3919.msi

[Author]

Posts