[support]

Hi,

If  you are using VisualGDB 5.2 Preview 2 or later, you can change those colors via Tools->Options->Environment->Fonts and colors->Text Editor->Code reference, Code reference (C/C++ macro) and Code reference (write).

[support]

Hi,

This error usually happens when some libraries are not found in the PATH directories. Please try launching the C:\SysGCC\Beaglebone\arm-linux-gnueabihf\sysroot\usr\local\qt5\bin\qmake.exe executable manually from Explorer and check if it complains about any missing libraries.

Normally VisualGDB should setup the paths automatically, so most likely your toolchain is corrupt (perhaps your antivirus triggered a false positive on some of the DLLs from the toolchain?). Please try reinstalling the toolchain and check your antivirus log for messages about blocked files.

[support]

Hi,

Yes, this will be the easiest. You will need a Linux machine (or a VM) to run them though.

We will also consider adding unit test support to the MinGW project wizard to create tests that run directly on Windows.

[support]

Hi,

VisualGDB is actually designed to seamlessly run the tests on your device. It will automatically start selected tests only, will gather results and failure details and display them in the Test Explorer window just like if they were running on the Windows machine. So you can test actual hardware issues there and even use them to verify that all the components on your board are working properly.

If there is a reason why you would prefer running the tests on Windows side, please let us know. We will be happy to add support for this if it proves more usable in some cases.

The screenshot in the blog post is taken from the Linux project wizard and is offers more options than the Embedded project wizard.

[support]

Hi,

It is hard to say what could be causing this without seeing the build log. Please open the Output window via the View menu and check for additional error information. If this does not help, please send us the build log so that we could help you further.

[support]

Hi,

Good to know it works.

Not fully sure what you meant by “Live variables appear in the same management”. Do you mean the menu command to show live variables?

[support]

Hi,

Do you mean that you have relocated the project, the toolchain or the BSP? Could you please attach a screenshot of the error, this should help us suggest a quick solution.

[support]

Hi,

This looks like a potential problem in the CMake file. Which version of VisualGDB did you use to create the project?

[support]

Hi,

The fast semihosting framework is designed to be used under debugger, but if your program does not call printf() or similar functions, it should not trigger. If you want to build a release executable that will discard the printf() output instead of trying to communicate to the debugger, please follow the steps below:

1. In VisualGDB Project Properties -> Embedded Frameworks please uncheck the “Redirect printf() to fast semihosting” flag
2. On the Makefile settings page for the Debug configuration add ‘FAST_SEMIHOSTING_STDIO_DRIVER’ to the list of preprocessor macros to enable this feature for Debug configuration only
3. In your code provide the default implementations for _isatty() and _write() that will just return the correct values and not send anything.

This should eliminate any references to the semihosting functionality in the release build and make it run with no debugger attached.

[support]

Hi,

Looks like your support period has expired. Please renew your license and we will be happy to help you.

[support]

Hi,

You can try using the per-user variables (or environment variables). Simply replace the host name and user name in .vgdbsettings files with something like $(VariableName) or do the same via GUI. Let us know if  you need more details.

[support]

Hi,

Perhaps the extra initizliation commands did not get imported properly. Could you attach your .vgdbsettings file and the <mcu>.xml file so that we could check that?

[support]

Hi,

Thanks for the project, we have reproduced the problem. It happens because the original ARM toolchain has a bug that does not set the FPU type correctly for Cortex-M4 devices.

The toolchain that comes with VisualGDB fixes this; the original ARM one does not. You can work around this by adding -mfpu=fpv4-sp-d16 to your LDFLAGS, however the standard libraries that come with the toolchain are still compiled with the wrong FPU setting, so they may cause random crashes if your program is using hardware FP.

We would recommend switching to the toolchain shipped with VisualGDB to avoid this problem in the first place.

[support]

Hi,

It usually requires understanding which files belong to which component and including only the relevant ones. That’s why it takes us some time to make usable wrappers around the SDK that include the necessary files automatically, sorry.

The only alternative to thoroughly looking through the sources and figuring out which ones are needed for what would be to wait a few months until we release an updated BSP.

[support]

Hi,

The latest BSP for the NXP LPC devices supports the LPC1769 MCU, however it does not come with any Smoothieboard-specific drivers or samples.

You should be able to build and debug a basic project though and then you can add any Smoothieboard-specific code manually. If you encounter any problems, feel free to let us know.

[Author]

Posts