Forum Replies Created
-
Posts
-
Hi,
This is an unfortunate limitation of the semihosting mechanism. Handling a semihosting call involves stopping the CPU and reading the registers/memory. Due to the USB latencies, this takes tens of milliseconds, so your app will certainly miss some real-time events. The only reasonable workaround we could suggest is to use another UART port to print the diagnostic messages.
That said, it looks like we should be able to create a non-stop semihosting alternative similar to our live variables feature. We will investigate into this and perhaps add it to VisualGDB 5.2 feature list.
Hi,
We would recommend creating a basic LEDBlink project and testing whether it still runs without debugger. If not, something is wrong with your FLASH programming setup. If yes, try gradually adding features from your current program to the LEDBlink project to see which one breaks the flow.
Hi,
It’s hard to say why your executable is larger, it could be caused by some code being inlined/expanded, larger symbol tables, or some extra libraries. You can use the objdump tool to figure it out in detail, but if you are targeting Raspberry Pi with 512MB of RAM, 50 KB difference (0.01% of RAM) won’t have any noticeable effect at all.
Hi,
Yes, the Makefile looks like it can be built with VisualGDB. Simply install our ARM toolchain, add it to PATH and replace arm-none-eabi- with arm-eabi- in your Makefile so that it matches the arm-eabi-gcc.exe executable. However if the project is made to be built on Linux, it might rely on other Linux tools and simply not build under Windows. In that case we would suggest getting a Linux cross-toolchain, getting it to build on a Linux VM and then importing it into Visual Studio as described in this tutorial.
Either way, VisualGDB is flexible enough to build/debug any project that can be built using command-line tools, so you should be able to develop it with Visual Studio and VisualGDB even if it needs to be built remotely under Linux. If you encounter strange error messages, feel free to post them here so that we could try to help you.
Are you creating a normal VisualGDB proejct using the VisualGDB wizard, or importing some existing code? Are you selecting “FLASH” as the primary memory in the wizard?
Hi,
Thanks for letting us know. Our Jessie toolchain image was indeed missing some DLLs. We have updated the installer. Please re-download and re-install it.
Hi,
This is a known limitation caused by the way signals are implemented in Linux. You read more about it on StackOverflow: http://stackoverflow.com/questions/1717991/throwing-an-exception-from-within-a-signal-handler
Hi,
Yes, we usually update the BSPs quarterly. There are 3 ways to get the updated library:
- You can build and run our STM32 BSP generator against the new archive from ST.
- You can simply copy the new code from ST to %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\<…>stm32\<your family> replacing the old code
- You can convert the project to a stand-alone project and import the code from ST manually.
Hi,
For embedded projects VisualGDB always uses the GDB that comes with your toolchain. The easiest way to override it would be by copying the toolchain to a different directory and adding a GDBExecutable element to toolchain.xml:
<Toolchain ...> <GDBExecutable>other-gdb.exe</GDBExecutable>
Hi,
We are currently planning to release the first beta around the end of November – beginning of December.
You can include resources like image files by modifying the Makefile. See this tutorial for an example of including a .png file.
Hi,
It’s hard to answer that question from just looking at the project source page. What hardware is the project targeting? What toolchain is it using?
Hi,
Good to know the workaround works. It’s surprising that the cc1plus requires more than 2 gigabytes of RAM, how large is your source file and the included headers (you can find it out by preprocessing it to a file using -E instead of -c)?
Hi,
Please try viewing the Android log (run adb.exe logcat) or launch debugging with VisualGDB and check for errors in the GDB Session/logcat windows.
Hi,
The problem with Eclipse is that every version stores the settings a little bit differently, so there is no consistent way of importing them automatically.
We have received a lot of feedback recently about debugging embedded projects built elsewhere and will be extending our Quick Debug feature with Embedded Quick Debug in the next version. Until then the suggested workaround is to import your projects.
Hi,
You can try following our tutorial on importing projects from CooCox IDE: http://visualgdb.com/tutorials/arm/coocox/
Let us know if that works.
