Forum Replies Created
-
Posts
-
Hi,
Simply saving all files should do the trick. VisualGDB will automatically update the function index then (you can check View->Clang IntelliSense Status to make sure the updating takes place) .
Hi,
The “disable optimization” option in VisualGDB simply replaces the optimization flags such as “-O2” with “-O0” when passed to gcc. This works for most libraries and platforms, however, if the library you are trying to build specifically relies on optimization, it may indeed break the build.
As the library does not come from us, we will not be able to help troubleshoot it, so our best advice would be to check the entire build output from the VisualGDB Build window for anything suspicious, and try editing the library to work around the issues raised by disabling optimization.
Hi,
Please note that our technical support only covers issues in VisualGDB itself. We are not able to help fix errors in specific projects, port libraries, or offer help with freelancing projects without directly billing for the time required to do it.
Hi,
This looks like a bug in Visual Studio itself. Based on the latest feedback we got from Microsoft, it was triggered by an unexpected combination of flags returned by our debug engine, however from a quick test on VS 16.8.2, it appears to be resolved on the VS side.
Please try updating your Visual Studio to the latest version. If the problem persists, we will try updating VisualGDB to emulate the fields VS would normally expect.
Thanks, we have located the difference. We have indeed changed the Arduino reset logic to match the Arduino IDE more closely, as another user reported problems with Arduino Nano.
As we do not have the hardware to recheck it on our side, please try downloading and running the attached test project. Does it reset the board properly into the bootloader (with a different COM port)? If not, does removing everything between port.Open() and port.Close() result in a reset?
Trying different things at the same time almost always results in strange behavior, and it’s hard to say which of the multiple changed things caused it.
We can gladly investigate it further if you could gather the output from VisualGDB Diagnostics Console in v5.4 vs v5.5 using the same COM port. This will show what has changed and will help us pinpoint the cause.
Based on the logs you provided, VisualGDB and the Arduino tools use different COM ports (your latest log mentions COM4, VisualGDB log mentions COM6). Please double-check that you specify the same COM port in VisualGDB Project Properties as you use in the Arduino IDE.
Hi,
No problem. Please try this build: VisualGDB-5.5.104.3927.msi
It uses invariant culture for formatting of timestamps in the .trx files and also updates the BSP files after running VisualGDB.exe /pkgmgr. If the problem with the .trx files persists, please try editing a faulty file manually until it is accepted by your source control system, and then attach both files in a .zip archive (sorry, due to the limitations of our forum engine, it requires a whitelist of supported attachment extensions).
We have tried reproducing the problem with tests in subdirectories, however it worked as expected. Can you confirm that you are specifying the correct .vgdbtestcontainer file when running VisualGDB.exe /listtests? The container file should explicitly mention the target in the Target element. Also if you could create a very basic project, archive it to a zip file (including the .vgdbtestcontainer file) and attach it here along with the exact repro command line and output from VisualGDB.exe, we should be able to fix it promptly.
Hi,
It looks like your Arduino core requires an external reset sequence. I.e. it will pulse the DTR signal on COM6, but will then expect the actual programming port to appear as another COM port. VisualGDB determines this by analyzing the Arduino core parameters and might determine some settings incorrectly for your board.
Please try double-checking what happens if you program the board with the Arduino IDE. Does it mention COM6 in the logs? Does another COM port temporarily appear in Device Manager during the programming? Are there any command lines for any programming-related tools shown in the Arduino IDE log?
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.
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).
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.
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.
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.
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.
