Forum Replies Created
-
Posts
-
Hi,
This is a known issue. Sometimes some gdb stubs report memory contents incorrectly. Please try enabling the “use ‘x’ command to read memory” checkbox in the VisualGDB Project properties (GDB Settings page). This should use a slightly slower but more reliable mechanism.
Hi,
We’ve actually just released the EFM32 package. You can now easily create a project like shown in this tutorial and VisualGDB will attach all necessary files automatically.
Hi,
We have fixed a few things in the engine since the latest 5.1 build, so please check if you can still reproduce the problem with this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.4.821.msi
If yes, please upload an updated dump file and we will look into it.
Hi,
Please find the answers to your questions below:
- We have added experimental support for changing embedded toolchains to this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.4.821.msi. Let us know if it works.
- The include directories are transferred to IntelliSense settings once VisualGDB performs toolchain testing. If you bypassed this stage, the directories won’t be added. Either way, the build above contains an experimental feature of automatically detecting and repairing missing include paths for both IntelliSense and project properties, so it should take care of this automatically. Feel free to let us know your feedback on this feature.
- You can work around this by adding something like “$$custom_pre_load_command$$ to the startup commands in EDP.XML and then setting this variable per project by editing the .vgdbsettings files (inside the DebugMethodProperties element). Let us know if you need more details.
Hi,
OK, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.4.820.msi
Then open the Clang IntelliSense Console window via the View menu and look for a line like this:
Indentation size: 4, will insert spaces
Does it match your settings? Are tabs still inserted instead of spaces?
Hi,
Most likely when you stop at a breakpoint your PC is still sending some requests to the board and once it times out (as it is stopped in the debugger), the PC assumes it has disconnected. Can you confirm that it does not disappear when you don’t set any breakpoints?
Hi,
Yes, please go to the Debug Settings page of VisualGDB Project Properties, uncheck the “Specify automatically based on project settings” flag and select the “MK64FN1M0xxx12” value from the list.
Hi,
Sorry for the confusion. We are gradually updating our tutorials to reflect the newer HAL API (e.g. see the new timers tutorial), but we did not update the PWM one yet.
Hi,
If you are never intending to deploy or debug the project with VisualGDB, you can select any arbitrary SSH connection in the wizard as it won’t be used anyway. Let us know if this works.
Hi,
This setting is normally cached, so sometimes it’s not updated immediately. Please try reopening the source file or restarting Visual Studio after changing it.
Hi,
Thanks, the build type was indeed ignored. We have fixed this in the development tree. If this is critical to you, we can share a daily build with the fix.
We will add an option to delete the remote files corresponding to recently deleted local files in v5.2.
You can specify explicit subdirectories by selecting “Include selected subdirectories only” and then unchecking the .git directory explicitly.
Hi,
We have actually added it to v5.1 some time ago. Please ensure you are using the latest version. If you still don’t get it to work, please let us know the exact steps to reproduce it and we will fix it.
This is a known issue; VisualGDB does not deploy the shared libraries during toolchain testing. You can safely ignore the error. If you get it during debugging, please ensure that the project producing the libraspicam.so is referenced by the project you are debugging. Alternatively you can add a pre-debug action to deploy the .so file manually.
