[support]

Hi,

The socat will actually no longer be required in the upcoming VisualGDB 5.5 as it is switching to the more advanced CMake file API. Once it is released, please simply build/install our latest CMake fork on the target machine (the regular CMake will do as well, although it will not support stepping through the CMake statements) and VisualGDB will use the new API, eliminating the need for socat.

[support]

No problem, we have rechecked the latest generated SDK and fixed both the build issue and the field offset detection problem.

Please try this build: VisualGDB-5.5.1.3252.msi

Please note that you would need to re-import the KSDK from the VisualGDB wizard in order to fix the FreeRTOS-related build errors.

[support]

Good to know it works. For older project types (e.g. GNU Make), the IntelliSense compilation settings are computed separately from the build settings (as GNU Make doesn’t automatically report the build flags in a structured way) and hence editing some settings manually instead of using the VisualGDB GUI might get IntelliSense out-of-sync with the actual build.

[support]

Hi,

No problem, it looks like VisualGDB doesn’t support the FreeRTOS version you are using, but it should be very easy for us to resolve. Could you please share a link/attach the exact SDK you are using so that we could ensure we are looking at the same thing?

[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.

[Author]

Posts