Forum Replies Created
-
Posts
-
Good to know it works. Most likely, you have initially upgraded the toolchain, but not the SD card image (or the other way) and synchronized an incompatible SD card image with a toolchain that expected different versions of the headers/libraries. Either way, the procedure you described is the correct way of resetting the toolchain, so it should now work as expected.
Hi,
Thanks for finding this out. Normally, the clock-related code in stm32fxxx.cfg would get executed just after starting a debug session. It would raise the system clock frequency, allowing for faster FLASH programming and faster JTAG communication, and once the SystemClock_Config() runs, it would override the parameters set via stm32fxxx.cfg.
The clock parameters set by the stm32fxxx.cfg would only affect the code that runs before SystemClock_Config() (i.e. startup code) and should not affect the rest of the program.
Either way, if you prefer disabling this mechanism, you can copy a modified version of the .cfg file to the project directory and replace the path to it in OpenOCD settings (expand the Advanced view to edit it) to $(ProjectDir.forwardslashes)/<cfg file name>.
Regarding the startup file, VisualGDB normally does not allow replacing it because the file shipped with VisualGDB is 100% equivalent to the original .s file. It only defines the interrupt vector table and the reset handler and does not handle the clock. If you absolutely need to override it, please consider setting the “excluded from build” flag for the .c file and adding the .s file to the project manually.
Hi,
This looks like a corrupt toolchain. Unfortunately, as you have cropped the screenshot, it’s hard to tell whether it’s an IntelliSense-only issue, or a full-scale toolchain corruption (see this page for best error reporting practices). Either way, the easiest way to solve this would be to delete the entire Raspberry Pi toolchain, reinstall the one compatible with your SD card image (see the full list here), and verify that newly created projects build after reinstalling the toolchain.
If the projects stop building after you resynchronize the toolchain’s sysroot, your SD card image is likely incompatible with the toolchain. If this is the case, simply start with a fresh compatible image from the list and you should be able to build the projects.
The actual clock initialization is performed by the SystemClock_Config() function. Hence if the clock is initialized incorrectly, the function either does not get executed, or uses incorrect parameters. The only way to diagnose this is to step through the SystemClock_Config() function in the debugger and double-check the values it sets.
Hi,
The clock setup for STM32 devices is normally done by the SystemClock_Config() function. Please try locating it in the files generated by STM32CubeMX (if you cannot find it, try searching for functions calling HAL_RCC_OscConfig()) and then check whether the VisualGDB project includes the file defining this function and whether it is called from your main() function.
Our consulting focuses on issues that are too specific to be supported directly by the off-the-shelf products. E.g. porting specific libraries to new platforms, porting projects between compilers or SDKs, creating tools for automatically importing large multi-project solutions in a custom format, creating BSPs and detailed setup tutorials for niche devices that are not sufficiently popular to be supported directly, etc. We also do paid screen sharing sessions helping our users troubleshoot weird problems in their codebase that would otherwise take too long to narrow down. Feel free to reach out to our sales if you need an estimate for a specific issue.
Indeed, VisualGDB normally uses the GCC compiler (that is itself one of the most popular compilers in the embedded space), so all the solutions that work with GCC would also work with VisualGDB.
Also a heads up that our support covers VisualGDB-specific issues (e.g. help finding features like Live Memory or fixing bugs in VisualGDB itself), however we are generally not able to provide help with the external components (e.g. the GCC compiler, vendor-specific SDKs, connectivity/power issues, external libraries, etc.), as those components are outside of our control. We do offer paid consulting services for everything that isn’t covered, however in order to make sure we can allocate resources to develop our products and fix issues that are within our control, we have to be fairly strict about what we can address via our regular product support.
Hi,
Please try enabling the live mode in the Memory window (lightning icon). This will allow viewing the contents of the buffer as it is being filled. We are also experimenting with an alternative mechanism for fetching live variable information directly from the ELF file, so we might be able to support additional variable types in the future, although it’s hard to give any estimates now.
Regarding C++, you can try using the regular STL, however it would have a considerable runtime overhead.
NMEA message handling unfortunately looks too specific for VisualGDB to handle it directly. Please feel free to ask on StackOverflow and/or STM32 forums; perhaps someone else have developed a similar application and can share some suggestions.
The mechanisms used by VisualKernel to manage the modules vary between different Linux kernel versions. To make things more complicated, some of the distros have previously backported some trace-related changes into their kernel fork (so that the same kernel version used by different distros would require a different configuration).
Furthermore, those options are also different between hardware platforms, hence a configuration that works for one distro/kernel versions will very likely not work with others (we have previously encountered that).
This is exactly why we chose to support a handful of most popular distros and configurations (i.e. test everything on our side and make sure VisualKernel sets all necessary parameters automatically) and provide sources for all low-level components so that they could be tweaked to target an unsupported configuration.
We understand you are using an unsupported distro and expect the level of support we would normally provide for a supported distro. Unfortunately, this is not something we can offer at a price of an off-the-shelf product, as it is only possible to directly support popular distros/targets that are relevant to many users as the same time.
Sorry, VisualKernel does not support the generic armhf build of Debian as it is not as popular as other distros.
VisualKernel does support the following distros for desktop (x86 and amd64 targets):
- Ubuntu
- Debian
- Mint
- CentOS
- Fedora
See the history page for a list of specific versions supported by a particular VisualKernel release.
VisualKernel also supports the following ARM targets:
Generally, you should be able to target an unsupported distro as well, however you would need to research the compatible flags and settings on your side. As directly supporting each distro requires considerable non-trivial troubleshooting, we are only able to offer out-of-the-box support for a handful of most popular distributions.
Regarding LinuxKernelDebugHelper, we will try to address this in one of the next releases of VisualKernel, however as the issue is only triggered by a specific kernel configuration on an unsupported distro, this has a relatively low priority.
We have quickly rechecked the latest Debian 10.2 and the default kernel shipped with it is built with the CONFIG_KALLSYMS_ALL option.
Most likely, you are using an unsupported Linux distro, that explains the configuration errors. You can find a list of supported distros here: https://visualkernel.com/history/.
If you are not sure, please share the URL to the ISO file you are using and can check if it is supported.Also VisualKernel would normally detect tracepoint issues a compile-time and would not attempt to load LinuxKernelDebugHelper, however if you are using an unsupported distro that was never tested with VisualKernel, this check indeed may not work as expected. Either way, it is highly unlikely that dereferencing a null pointer would replace the kernel version string with random characters, while keeping the system otherwise usable.
This limitation comes from the fact that the native Linux Kernel build system (KBuild) does not natively support separate debug/release build subdirectories, hence supporting Debug/Release builds from the VisualKernel GUI without the risk of combining incompatible files would require non-trivial patches to Kbuild.
Furthermore, in our experience, the release builds of performance-critical modules (e.g. drivers) are usually done as a part of a larger build system (e.g. Yocto), while the VisualKernel projects are used for debug builds.
Since VisualKernel uses unmodified KBuild Makefiles, you can always extend them to use conditional statements (e.g. ifeq()) in order to apply different flags depending on the arguments passed via command line. However, as this presents a risk of combining files built with different flags, it is not supported out-of-the-box and is only recommended for advanced users that are comfortable editing Makefiles.
Hi,
Yes, you should be able to get it working by running OpenOCD on the customer’s machine and setting up TCP port forwarding so that you can connect to it from your lab.
You would need to find out the following parameters used in a regular debug session and replicate them manually with a 2-machine setup:
- The OpenOCD command line. You can find it in the OpenOCD window in Visual Studio (or in the connection testing window when you press the “Test” button in the VisualGDB Project Properties).
- The GDB command line. Is is typically gdb –interpreter mi $(TargetPath).
- The startup gdb commands involved in a regular session (e.g. target remote host:port, load, etc). You can find them out by switching the GDB Session window to “All GDB Interaction” mode.
Once you find out those parameters and can successfully launch OpenOCD remotely, you can use the Debug Settings page of VisualGDB Project Properties to switch the debug method to the “Custom” mode. This will allow entering the gdb command line and startup commands manually, so you can connect to the remote OpenOCD instance.
We would also advise trying to manually launch OpenOCD locally and connect to it using the custom mode first. This should help decouple the manual setup problems from potential network problems.
Sorry, we have reviewed the differences between the STM8 devices and other devices. Given that the STM8 devices require a special C-only compiler and are not compatible with most of the tools used by VisualGDB, we have decided to not support them at this time. We may reevaluate this in the future in case the underlying tools improve or the STM8 devices become more mainstream, however currently we have decided to not support STM8 out-of-the-box, sorry.
