[support]

Hi,

We have indeed not checked this functionality with STM32L071, so it is possible that this MCU simply does not implement the “debugger attached” bit. Please try checking the DEBUGEN bit in the DHCR register either via the Hardware Registers window, or manually. Please also check the STM32 documentation for details on this. If this particular MCU does not implement a ‘debugger attached’ bit, the automatic enabling/disabling of semihosting based on it will indeed not work.

[support]

Hi,

This is likely affected by the same limitations as Live variables, so please refer to our explanation in the following thread: https://sysprogs.com/w/forums/topic/debug-in-stop-mode-how-it-should-work/

[support]

Hi,

The Live variables function relies on the CPU’s ability to read the memory contents without completely stopping. The exact details of this mechanism are target-specific and it is completely plausible that entering the STOP mode would power down either the memory itself, or the logic responsible for reading the memory through SWD/JTAG.

Our best advice is to check the STM32 documentation for the description of the STOP mode logic. There might be a configuration register that allows specifying which clocks actually get stopped during the STOP mode and you might be able to prevent the memory from being powered down (checking what exactly __HAL_RCC_DBGMCU_CLK_ENABLE(); does can provide some clues as well).

Please also feel free to ask on the ST forums, or contact ST support, as they have a better insight into the STM32 tutorials.

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

[Author]

Posts