Forum Replies Created
-
Posts
-
Hi,
This looks like a bug in the STM32 device table on their site (http://www.st.com/en/microcontrollers/stm32l4-series.html?querycriteria=productId=SS1580). Once they fix it, our next BSP will use the updated data.
The wrong value should only affect the device selector, but not the actual linker scripts, so you can simply ignore it.
Hi,
The problem is that ReSharper uses its own IntelliSense engine that does not handle the GCC language extensions. So our best advice would be to use our Clang-based IntelliSense engine that is fully aware of those extensions and also offers advanced refactoring functionality.
Hi,
You can download the previous versions of the BSPs here: http://visualgdb.com/hwsupport/
Then simply install them via “Install a package from file”
Hi,
CC3220S is a different chip from CC3200 and is not supported by us directly (it looks to be much less popular than CC3200, so we currently don’t have plans for supporting it directly).
Please follow our legacy device tutorial to setup a project manually.
Hi,
The Edison toolchain might require an explicit “–sysroot” argument. Please try specifying it via additional command line flags for both compiler and linker (see the toolchain documentation or included examples for the correct sysroot value).
Hi,
Thanks, according to the stack trace, VisualGDB was stuck waiting for a response from the Linux machine while trying to close an SSH connection. If you run into this problem again, please try updating your SSH server or try a different network connection (e.g. this could be caused by packet loss).
Hi,
Unfortunately, VS registry can get corrupt in many different ways, so one specific instance won’t be of much help. You could try getting a diff of the .reg files from the old and the new key and quickly check if there is anything obviously wrong there (or send the diff to us if the amount of changes is relatively small), but unless it gets obvious from the first glance, investigating it further won’t be worth the time.
Hi,
Please double-check that the .S file is actually compiled with the -ggdb switch (so that gdb can get debugging information for it). If it does not help, please try repairing breakpoints via VisualGDB breakpoint repair button in the GDB Session window.
Hi,
Please try referencing the “config” variable from your code so that the linker does not discard it as unused. Alternatively you can try using the KEEP() statement in the linker script file and attribute__((used)) in your code.
If it does not help, try enabling the map file generation via Linker Settings and check the map file to see where exactly the linker placed your variable.
Hi,
The behavior you are describing would make 100% sense if the sleep loop was infinite (the optimizer would eliminate the rest of the code), but if it’s limited to 100 iterations, it should not happen.
Please try pressing the ‘diagnose breakpoint problems’ button in the GDB Session window to automatically diagnose path mapping issues.
Hi,
Thanks, this looks like the hang is related to VisualGDB. Could you please let us know the exact VisualGDB build (from VisualGDB.exe file properties) so that we could pinpoint this further?
Please also try manually killing the CppEngineHost.exe process next time the hang happens. If the hang is related to the Clang IntelliSense engine, this should help.
Hi,
The file is only needed to setup non-Clang IntelliSense; if you don’t get any other errors, you can simply ignore this problem (and/or remove the reference to the file via VS project properties -> NMake settings -> Forced includes).
Hi,
You don’t need to delete the VisualKernel folders/keys, only the Visual Studio ones:
- C:\Users\<user>\AppData\Roaming\Microsoft\VisualStudio\14.0
- C:\Users\<user>\AppData\Local\Microsoft\VisualStudio\14.0
- HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0
- HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config
We recommend renaming the folders/keys before you confirm that it solves the problem in case you accidentally delete something critical.
Hi,
When you try to insert a breakpoint in a running program, VisualGDB sends a Ctrl-C signal to the gdb and it response gdb tries to halt your program. If anything on this path is broken, settings breakpoints in a running program won’t work.
This could be caused by your program altering the handling of SIGINT or some system-wide settings. If it only happens with one project, we would recommend placing an infinite loop in main(), checking that ‘Break all’ still works, and then moving the infinite loop around to find the code that breaks the Ctrl-C handling.
Hi,
We have double-checked the window. The GUI thread should have the following attributes set:
- Both Category and Name should read “Main Thread”
- The Managed ID should be 1
In order to get past the “external code” issue, please right-click in the Call Stack window and select “Show External Code”.
Alternatively you can simply select Debug->Save Dump As, upload the dump file (~1GB) to dropbox and share a link so that we could investigate it on our side.
