Troubleshoot with Cortex-M4 reinitialization on STM32MP1

[MHolu.1]

Hello everyone! I'm using the STM32MP157F-DK2 and the OpenSTlinux Distribution package with a set of Yocto recipes that do not affect the Linux kernel. I have written a program for the Cortex-M4 core and created a device tree in CubeMX. Then, I built my OpenSTlinux distribution based on my device tree from CubeMX (based on guide "How to compile the device tree with the Distribution Package"). Initially, everything works fine, and I have a fully functional Linux distribution and a working program for the Cortex-M4. However, if I want to stop the execution of the Cortex-M4 firmware and try to run it again, nothing happens. It's as if I'm running a firmware that does nothing. Only reboot helps. In my program, I use UART3, SPI5, several timers, GPIO ports, and OpenTTY Virtual UART for communication between A7 and M4 cores. I suspect the issue might be related to clock configuration, but I haven't found a way to diagnose this problem in more detail yet. I hope someone here can help me.

[Erwan SZYMANSKI]

Hello @Maksym Holub​ ,

That looks quite strange for me, can you explain me how do you run your M4 firmware at boot time, and how do you try to relaunch it at runtime ?

Kind regards,

Erwan.

[MHolu.1]

Hello, Erwan. Thank you for the prompt response. I have already tried various methods to launch the firmware. For my project, I am using a Python script that does exactly the same thing as the standard fw_cortex_m4.sh script. The issue remains the same whether I use my Python script, the standard fw_cortex_m4.sh script, or even manually launch it through the terminal and remoteproc. For simplicity, let's assume that I am starting and stopping the Cortex-M4 firmware using the standard script generated by CubeMX (provided below).

P.S. Other examples provided with OpenSTlinux distribution can be started and stopped correctly multiple times without any issues.

[Erwan SZYMANSKI]

@Maksym Holub​ ,

Thanks for your answer. The fact that native examples provided by ST work with the same method lets think that the issue comes from some userspace.

Did you already try a very simple (but maybe important) test, to turn on a led just at at the beginning of your M4 program ?

It is just to check if this is the entire firmware that does not run, or if this a later userspace issue that let you think that nothing happens.

To go further, maybe you could process step by step, with keeping a simple led operation to begin, and then add your different features step by step to check at which moment the relaunch does not work anymore ? (just an idea to debug).

Kind regards,

Erwan.

[MHolu.1]

Thank you for your idea. At the beginning of my program, the OpenAMP and IPCC initialization takes place. I noticed that when I restart, the rpmsg-tty channels are not created. To minimize any mistakes on my part, I tried to make the code as similar as possible to the OpenAMP_TTY_echo example. Below is the code for the main() function. The first step is the initialization of the clock and OpenAMP. After starting the firmware for the second time, I don't see the following lines in dmesg, which I see after the first boot:

[ 2795.041793] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x400

[ 2795.041793] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr 0x401

Consequently, the /dev/ttyRPMSG devices are missing.

I will test later if the program works without OpenAMP.

I will add some information about my setup:

Openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23

OpenEmbedded v4.0.4 (Kirkstone)

Linux kernel V5.15-stm32mp-r2 (v5.15.67)

Firmware package - STM32Cube_FW_MP1 V1.6.0

CubeMX 6.7.0

[PatrickF]

HI @Maksym Holub​ ,

This is maybe the classic pitfall as CubeMx generated FW assume the whole set of peripherals are in init state when doing HAL inializations.

Before init of each peripherals which you suspect they are stuck, you could try to use HAL_***_DeInit(); for e.g. UART, SPI, TIMER, etc....

Alternatively, if it is not enough (e.g. interrupt get stuck), you could use

__HAL_RCC_***_FORCE_RESET();

__HAL_RCC_***_RELEASE_RESET();

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[MHolu.1]

Hello @PatrickF​ ! You're absolutely right! Despite my assumptions that the issue was related to OpenAMP, it turned out that the M4-core hang was caused by receiving data via UART using DMA. The following functions solved the problem: __HAL_RCC_DMAx_FORCE_RESET(); __HAL_RCC_DMAx_RELEASE_RESET() in HAL_DMA_init() Thank you and @Erwan SZYMANSKI​ for your prompt assistance in resolving the issue!