Hi,

Our STM32MP1 support is based on the STM32CubeMX examples from ST, and they indeed involve running the ST’s Linux distro on the A7 core, and the barebone code on the M4 core.

There is a 3rd-party set of examples for the STM32MP1 A7 core without Linux. We have briefly rechecked them and they appear to be working, although getting the build to work required some adjustment.

If you would like to get it working with VisualGDB, we would advise the steps below:

1. Build the 3rd-party examples manually and ensure they work. If you get the “failed to merge target-specific data” error while using the regular ARM toolchain, you can work around it by changing the target-specific passed to the linker from -mcpu=cortex-a7 -march=armv7ve -mfpu=neon-vfpv4 -mlittle-endian -mfloat-abi=hard to -mcpu=cortex-a7 -march=armv5te -mfpu=vfpv2 -mfloat-abi=hard (you still need the original files for building the C/C++/assembly files).
2. Try Embedded Quick Debug to debug the built application with the STM32MP1 OpenOCD.  Note that the stm32mp1x.cfg file in the OpenOCD directory opens 3 GDB ports for the M4, and the two A7 cores respectively. VisualGDB connects to the first one, allowing to debug the M4 core. If you would like to debug the first A7 core, you would need to change the GDB port numbers in the file (search for -gdb-port). You can also change it to debug both A7 cores within 1 gdb session by specifying the hwthread RTOS and enabling the smp mode (see the raspberrypi4.cfg file in our regular OpenOCD package).
3. Once you can confirm manual building and debugging, you can easily create a VisualGDB-managed project as shown in this tutorial. You would need to manually specify flags like -mcpu=cortex-a7 -march=armv7ve -mfpu=neon-vfpv4 -mlittle-endian -mfloat-abi=hard, and point VisualGDB to the relevant headers, linker scripts and startup files, but once you do it, the result will be similar to using the Makefiles from the examples repository.

If you wish, we can retest everything on our side and deliver a ready-to-use BSP based on the examples repository. We won’t guarantee that all the examples will work perfectly, but will test the common scenarios like generating UART output, or making sure that both cores run and can be debugged. We will send you a separate email with the quote and the timeframe.