Skip to main content
Lukas1
Lukas1
Associate II
March 25, 2020
Solved

Firmware does not run properly after stop and start

  • March 25, 2020
  • 1 reply
  • 2166 views

Hi,

I'm currently working with the STM32MP157-DK2.

I built a firmware to run on the Cortex M4.

To load/start/stop the firmware by the A7 I use :

echo -n "firmware_name" > /sys/class/remoteproc/remoteproc0/firmware

echo -n start > /sys/class/remoteproc/remoteproc0/state

echo -n stop > /sys/class/remoteproc/remoteproc0/state

So far it works fine.

If I run the firmware the first time after a reboot all works fine. But if I stop the firmware, load and start again it begins to run and hangs up.

periphery the fw uses: SPI, GPIO, TIM, DMA, DDR, UART

third party: openAMP, FreeRTOS, virtUart, RESMGR_UTILITY

Is it possible to reset M4 and the peripherals without rebooting A7?

thanks in advance

regards

Lukas

This topic has been closed for replies.
Best answer by Lukas1

@PatrickF​ 

I tried the following and now it works. I added HAL_Init() in front of the reset/DeInit

int main(void)
{
 /* USER CODE BEGIN 1 */
	HAL_Init();
	__HAL_RCC_HSEM_CLK_DISABLE();
	__HAL_RCC_TIM5_FORCE_RESET();
	__HAL_RCC_TIM5_RELEASE_RESET();
	__HAL_RCC_TIM7_FORCE_RESET();
	__HAL_RCC_TIM7_RELEASE_RESET();
 
	HAL_IPCC_DeInit(&hipcc);
	HAL_SPI_DeInit(&hspi4);
	HAL_SPI_DeInit(&hspi5);
	HAL_DeInit();
 /* USER CODE END 1 */
 
 /* MCU Configuration--------------------------------------------------------*/
 
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();
 
 /* USER CODE BEGIN Init */
...

1 reply

PatrickF
PatrickF
Technical Moderator
March 25, 2020

Hello,

this is a known limitation, and today, there is various options to make it working:

  • Reset each M4-side assigned peripherals from RCC using Cortex-A7 (Linux). This is probably not straightforward.
  • On Cortex-M4 code, before peripherals init:
    • Reset each required peripherals from RCC using CubeMP1 macro (e.g. __HAL_RCC_xxxx_FORCE_RESET(); )
    • Deinit each required peripherals using CubeMP1 functions (e.g. HAL_xxxx_DeInit(&hxxxx); )

Last option is the recommended way.

Obviously, not all peripherals are concerned, e.g. GPIO has not to be reset.

Regards

In order to give better visibility on the answered topics, please click on 'Best Answer' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent
Lukas1
Lukas1Author
Associate II
March 25, 2020

Hi @PatrickF​ ,

thanks for your fast reply.

I tried this in main before init:

__HAL_RCC_TIM5_FORCE_RESET();

__HAL_RCC_SPI4_FORCE_RESET();

__HAL_RCC_SPI5_FORCE_RESET();

__HAL_RCC_IPCC_FORCE_RESET();

HAL_IPCC_DeInit(&hipcc);

HAL_DMA_DeInit(&hdma_memtomem_dma2_stream1);

HAL_SPI_DeInit(&hspi4);

HAL_SPI_DeInit(&hspi5);

Unfortunately it does not work. Now the firmware hangs up even on the 1st start

best regards

Lukas

PatrickF
PatrickF
Technical Moderator
March 25, 2020

My answer was a bit misleading.

it is either use of RESET or DeInit. Both are overkilling.

When FORCE_RESET is used, need to put a RELEASE_RESET just after (otherwise peripheral is kept in reset and this explain why it hang during init).

Usually, DeInit function is the better option (not need to use reset).

In order to give better visibility on the answered topics, please click on 'Best Answer' on the reply which solved your issue or answered your question.Tip of the day: Try Sidekick STM32 AI agent
Terms & ConditionsAccessibility statement