Forum Replies Created
-
Posts
-
Hi,
Sorry, still did not receive anything. Are you using the support form here [http://sysprogs.com/support/]?
Could you please post the ticket number from the confirmation page shown after you create a support ticket so that we could look it up?
Hi,
This is not supported yet, so the easiest workaround would be to use a Linux VM (or the Windows 10 Linux Subsystem) and run the tests there.
Hi,
We are aware of this and have added an option to suppress the deadlock message unless the deadlock call stack includes VisualGDB-related frames. As a temporary workaround please try disabling the deadlock detection unless you encounter actual deadlocks.
Hi,
This looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.3.1675.msi
Hi,
This is not supported yet. We are currently looking into automatically importing GPDSC files generated by STM32CubeMX, but before this feature is available, the only way to regenerate the project would be to re-import it or copy the files to the project directory manually.
Hi,
This is actually a matter of price/value. There are indeed products like CrossWorks and Keil that ship detailed and accurate register definitions for all devices, while providing much more basic IntelliSense and debugger experience. VisualGDB instead focuses on usability features that apply to all device families (like advanced IntelliSense or real-time watch), while relying on the device manufacturers’ definitions for hardware registers. This works very well for most of the families (most vendors provide either machine-readable definitions in the ARM SVD format or machine-generated header files that we parse).
Unfortunately TI devices are somewhat of an exception – their header files seem to be hand-edited and they don’t ship machine-readable definitions under a license that allows reusing. Also as their market share is relatively low (below 3% among our users), any feature that will add value to all device families will always get higher priority for us than resolving minor glitches in TI definitions (major bugs like the one you mentioned before are a priority).
If you are a licensed user of Keil or CrossWorks, you might be able to convert their register definitions to a format that VisualGDB supports for your own use (please double-check check their license terms to be sure). If you decide to go this way, we can provide step-by-step instructions on locating/replacing VisualGDB register definition files.
Hi,
Not sure what did you mean. Do you mean updating the list of source files in the Makefile once you add new files to Visual Studio Solution Explorer?
Hi,
So far we don’t have any tickets associated with your email address (and no unanswered tickets with crash dumps). Please try re-submitting it.
Hi,
Yes, you can add “VERBOSE=1” to make (not CMake) command template and rebuild the project. This should get CMake to print the command lines it is using.
Hi,
Yes, you can add “VERBOSE=1” to make (not CMake) command template and rebuild the project. This should get CMake to print the command lines it is using.
Hi,
Thanks, we have added this to the backlog and will consider supporting it in the next version of VisualGDB (after v5.3).
Hi,
It looks like the arm_neon.h file contains some checks that deem the current configuration (determined from checking built-in preprocessor macros via #ifdef’s) invalid. The best way to investigate it would be to look into the file that produces the error and see which exact #ifdef tests it performs.
Hi,
The easiest way to do that would be to right-click on the project in Solution Explorer and select VisualGDB Project Properties. Then go to the Makefile Settings page and edit the CFLAGS via GUI. VisualGDB will automatically update the related Makefiles and reconfigure IntelliSense.
Please note that if you are using MSBuild, you would need to use the VS Project Properties instead.
Hi,
This error means that the machine where you compile your code is missing the gdb debugger. You can normally install it by running “sudo apt-get install gdb” or “yum install gdb”.
If you are using a cross-compiler, you would need to open the VisualGDB Project Properties and manually specify the location of the GDB executable that matches your cross-toolchain.
Hi,
Unfortunately this is a bit tougher one. As TI does not ship official register definitions, VisualGDB gets them from parsing the header files and this mechanism is not as precise as parsing a machine-readable definition. Currently our parser uses common register definitions for the entire device family and does not remove registers that are not available on all devices.
Unless this causes some serious issues (e.g. disrupts program flow due to collision with some other registers), we recommend simply ignoring the extra registers.
