[support]

Thanks for getting back to us. We have released an update to the profiler framework resolving the issue. Please update it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

Good to know it works. Normally, VisualKernel should be able to find an incomplete sources/tools directory and continue the build. Once the build completes, it is registered with the VisualKernel and is automatically reused for all future projects. If you believe this is not working, please feel free to share the exact instructions to reproduce the behavior you encountered and we should be able to fix it or suggest a workaround.

[support]

This message generally means that the processor got stopped at a location that does not have debugging symbols (i.e. was not derived from one of the source files). You can still use the Call Stack window to see the function name or the Disassembly window to see the address and the assembly instructions.

[support]

Hi,

No problem, we can help you troubleshoot this. Please check that the Errors window does not show any other IntelliSense errors that could explain why Clang IntelliSense is not able to parse the type definitions. If it doesn’t help, please try the following:

1. Try closing the project, deleting the CodeDB subfolder and reopening it.
2. If it doesn’t help, please locate the definition of CAN_HandleTypeDef and check if it’s surrounded by any #ifdef blocks. If the #ifdef block appears inactive, please check where the macro controlling it is defined. It might be manually defined in the build settings in a way that doesn’t get passed to the IntelliSense (normally, please use the VisualGDB GUI to edit preprocessor macros for the project as it will automatically update IntelliSense).
3. If the #ifdef block is active, please try copying it to the .c file directly. If it resolves the problem, please try copying it to a separate .h file and try including this file from different parts of the .c file. If there is any particular place in the .c file after which the included file stops working, it could be a bug triggered by some previously defined code. In that case, please let us know more details and we will help you track it further down.

[support]

Thanks for confirming your license status. It looks like you are using an STM32 device/firmware version that was not tested with our profiler framework. Please let us know your MCU type and any settings you explicitly specify in the wizard when creating the project, and we should be able to reproduce and fix the problem.

[support]

Most likely, some of the files in your project are compiled without debugging symbols. Please follow this tutorial to diagnose the issue.

[support]

Hi,

It would be possible to use another Raspberry Pi as a build machine, however you would need to manually configure VisualKernel to use the correct build settings (e.g. see the tutorial for Xilinx Zynq, although the specific steps for Raspberry Pi will be different and some troubleshooting might be required, as we have never tested this configuration).

Normally, we would advise creating a 64-bit Linux VM (Ubuntu 18.04 LTS should be the easiest one to setup/maintain) using VirtualBox or Hyper-V and then following our regular Raspberry Pi module tutorial. This way the kernel/modules will build much faster compared to another Raspberry Pi and no other physical machine will be required.

[support]

Sorry for the confusion, this looks like a different issue actually. Please double-check that the Linux machine/VM used to build the kernel is a 64-bit one. The Raspberry Pi cross-toolchain released by the Raspberry Pi foundation is likely designed to run on 64-bit hosts only and won’t run on 32-bit systems.

[support]

No problem, we will help you get it to work.

The “exec format error” for kernel modules typically happens when trying to load a module that was built for a different kernel. Running “dmesg” from the SSH console should normally show more details on this.

Generally, for Raspberry Pi we recommend building a debug kernel, installing it, and then using the cross-compilation environment from the kernel to build modules. VisualKernel can automate most of those steps for you, so please try following this tutorial (including the part about building/installing a custom kernel) and let us know if anything doesn’t work.

[support]

Sorry, simply copying arbitrary code snippets between projects will not always work, as there are several different types of projects, libraries and targets and not all of them are mutually compatible.

If you are new to the STM32 development, please consider following some of our STM32 tutorials step-by-step in order to familiarize yourself with common settings, project types and functions.

[support]

Thanks for sending us the screenshots. It looks like you are trying to step through the program while it is already running in the background, hence the “step” and “continue” commands are grayed out.

Please try setting a breakpoint in main() before starting the debug session and wait for the breakpoint to hit (a yellow arrow will appear inside the breakpoint symbol). Then you will be able to step through the program.

It also looks like you were trying to use the regular VS Project Properties instead of VisualGDB Project Properties and hence could not locate the Embedded Frameworks page. Please follow this tutorial for a detailed description of the steps required to enable semihosting.

[support]

Thanks for sharing the patches. We have integrated them into our OpenOCD fork (20190828-0.10.0 available via VisualGDB Package Manager).

[support]

Hi,

This is by design. Most microcontrollers expect the interrupt vector table pointing to the entry point to be at a specific address (typically, beginning of FLASH) and placing arbitrary data there will prevent the program from starting.

The Embedded Memory Explorer shows the memory layout as defined in the BSP and ignores any manual changes to the linker script. Normally, we advise using the Additional Memories page of VisualGDB Project Properties (Custom edition and higher) to add extra memories to your project and have VisualGDB automatically update the linker script, generate macros for placing variables into those memories and also update the Embedded Memory Explorer.

[support]

Hi,

Normally F10 and F11 should work as usual. Perhaps the debug session doesn’t start properly, or the initial breakpoint doesn’t hit (i.e. the program is still running in the background)? If you are not sure, please try attaching a screenshot of the VS window with the step commands disabled and we will help you understand what is going on.

The printf() output should be redirected to Visual Studio as long as you reference the Advanced Semihosting and Profiling framework via VisualGDB Project Properties -> Embedded Frameworks, or enable the regular semihosting via the first page of VisualGDB Project Properties. Let us know if you need more details on this.

[support]

Hi,

From the VisualGDB side, there are no limitations regarding the C++17 support. As long as you are satisfied with the level of support provided by the GCC version you are using, it should be totally OK.

The ‘experimental’ label was added to VisualGDB settings when the C++17 support was still incomplete in most of GCC releases and should not apply to the latest GCC anymore. We have updated VisualGDB internally to remove the ‘experimental’ label.

[Author]

Posts