STM32MP153 M4 UART core hangs after 30-60min

[cfilipescu]

I have the M4 core using a UART core to send and receive data using DMA. This works just fine but over time after 30-60min the core crashes/locks up and reinitializing the UART channel does not help at all it actually crashes the sytem. Under normal operation the reinitialization sequence works properly.

The only thing I can get debug-wise is the gState which shows up as 0x21, and the state never changes after the lock-up. Reloading the m4 firmware from a7 side does not help and the UART core is broken until I do a system reboot.

Under normal operation, I do get the UART error callback triggered and the error code is 0x10, but the tx and rx continue to work without any action required.

Is there any sequence for resetting the UART physical core to recover without a reboot?

Are there any known reasons why the UART core would lock up after extended use?

[PatrickF]

Hi,

please double check the DMA TRBUFF bit is set when using DMA with UART.

In ES0438 Errata Sheet:

Otherwise, to ensure M4 peripheral restart after some crash, you could Deinit and Reset the related peripherals before their init.

Something like (to be adapted to your case):

// ensure clear any pending peripherals settings, interrupt or dmas
  uart.Instance = UARTx;
  HAL_UART_DeInit(&uart);
  HAL_UART_MspDeInit(&uart);
  HAL_NVIC_DisableIRQ(UARTx_IRQn);
  __HAL_RCC_UARTx_FORCE_RESET();
  __HAL_RCC_UARTx_RELEASE_RESET();
  HAL_NVIC_DisableIRQ(DMAx_Streamy_IRQn);
  __HAL_RCC_DMAx_FORCE_RESET();
  __HAL_RCC_DMAx_RELEASE_RESET();
 
// then regular init could be done
 
MX_UARTx_Init();
MX_DMA_Init();

Regards,

Patrick

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'

[cfilipescu]

@PatrickF​ 

How do I check that bit 20 is enabled? The init code was autogenerated from STMCubeIDE.

[PatrickF]

Hi @cfilipescu​ 

seems this is a bug in HAL.

Could you please try adding:

/* USER CODE BEGIN 2 */
  (hdma_uart5_rx.Instance)->CR |= 0x00100000;
  (hdma_uart5_tx.Instance)->CR |= 0x00100000;
  /* USER CODE END 2 */

just after MX_DMA_Init();

Regards,

[cfilipescu]

I will try it and see if this improves reliability

[cfilipescu]

@PatrickF​ 

It seems I hit the same problem after 3 hours.

Are there any other dumps I should get to understand why the UART core is stuck?

[cfilipescu · Accepted solution]

Issue resolved by using a DMA circular buffer

[Piranha]

> The only thing I can get debug-wise is the gState which shows up as 0x21, and the state never changes after the lock-up.

Just a typical "busy" driver lock-up because of incompetent HAL design.

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe