Forum Replies Created
-
Posts
-
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.
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.
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.
Thanks for sharing the patches. We have integrated them into our OpenOCD fork (20190828-0.10.0 available via VisualGDB Package Manager).
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.
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.
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.
No problem, we have fixed the duplicate window issue in this build: VisualGDB-5.4.112.3249.msi
Please try adding “pthread” to the “library names” field on the Build Settings page of VisualGDB Project Properties. You can read more about various linker-related settings here: http://visualgdb.com/support/linkerinputs/
Hi,
Sorry, the Advanced Mbed project subsystem relies on mbed itself to orchestrate the build and hence VisualGDB only allows changing the settings supported by the mbed-cli itself.
Based on a quick research, it looks like supporting floating point printf/scanf with mbed-cli requires a minor modification to the build scripts (see this Github issue). Please try applying it to the mbed copy used by your project and mbed-cli launched by VisualGDB should automatically pick up the updated build rules next time you build the project.
Hi,
No problem, we will help you understand how VisualGDB handles the K210 build and how to get the setup you described.
When you create a VisualGDB project for the K210 device, it automatically downloads a copy of the K210 SDK into %LOCALAPPDATA%\VisualGDB and references it from the project. The SDK copy contains an XML list of the sources and build settings required for K210 projects, so VisualGDB can automatically generate a VS project that would replicate the build result from the original K210 SDK.
Based on your description, you have likely imported another copy of the SDK as a generic project (importing the list of source files, but not the build settings that were captured from the original K210 SDK) and hence the build produces an invalid binary.
If you would like to have a separate copy of the K210 SDK and be able to modify it yourself, please instead try creating a regular VisualGDB project and then converting it to a stand-alone one as shown in this tutorial. This will copy the SDK files into the BSP subdirectory in your project folder and will also copy all the necessary build settings, so that the build result will be equal to the regular project. while letting you tweak that specific copy of the SDK according to your needs.
If you encounter any further issues, please feel free to let us know. The K210 support is very new and all feedback will be highly appreciated.
Good to know it works. Just in case anyone else is looking for the same functionality, our bootloader tutorial describes the steps necessary to merge the bootloader with the main application.
Hi,
Yes, please use the following setting:
VisualGDB Project Properties -> Debug Settings -> Program Output -> Keep Remote Console window after debugging ends
Regarding F5, normally unless you explicitly activate the console window by clicking on it, F5 should be handled by the Visual Studio itself and should result in continuing from the breakpoint.
VisualGDB will officially support ESP-IDF 3.3 and 4.0 once they are released as stable releases. Until then, you can try using VisualGDB with those ESP-IDF versions, however some functionality may not work as expected, as Espressif often changes the internal structure of ESP-IDF during the pre-release stage.
