Enabling Interrupt for UART stops HAL_Delay

[JDonn.1]

Hi everyone,

I'm new to the ST world so I apologise if I am asking a simple question.

I have a NUCLEO-L4R5ZI-P, I made a new project and cleared the pin outs and started fresh.

I have enabled USART2 and can send and receive data in polling mode.

If I go back into the Device Configuration Tool and enable USART2 Global Interrupt, then go to the NVIC settings and give it a lower priority than the "Timebase: System Tick Timer" everything stops working.

The uwTick variable no longer increments and so the following code hangs on HAL_Delay.

  uint8_t data[10];
  uint8_t data2[] = "Hello, World!\r\n";
  /* USER CODE END 2 */
 
  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */
    /* USER CODE BEGIN 3 */
	  HAL_Delay(1000);
	  HAL_UART_Transmit (&huart2, data2, sizeof (data2), 1000);
	  HAL_UART_Receive(&huart2, data, sizeof (data), 1000);
  }
  /* USER CODE END 3 */
}

Does anyone have any ideas why just enabling interrupts breaks this?

Cheers,

James

[Guenael Cadier]

Hi @JDonn.1​ 

Do you have an IRQ Handler that will handle the USART2 interrupts ?

If you break execution where are you stopped at ?

Maybe that if you enable USART2 interrupt without associated handler, interrupt is continuously raised, and is never processed and cleared.

Regards

[JDonn.1]

The IRQ is auto-generated, I also have an callback handler, it currently does nothing:

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    HAL_UART_Receive_IT (&huart2, data, 10);
}

This issue is present whether I call HAL_UART_Receive_IT (&huart2, data, 10); (outside the callback for the first time) or not.

When I break I get the following:

Break at address "0x1fff16d2" with no debug information available, or outside of program code.

[TDK]

> Break at address "0x1fff16d2" with no debug information available, or outside of program code.

Suggests you don't have the correct handler set up for whatever interrupt it's handling. Look at VECACTIVE bits to determine what interrupt it's in. Ensure the vector table is correct and the appropriate IRQ handler entry is there. I seem to recall the L4+ having issues with setting the vector table at startup in recent library versions, but I didn't dig into it.

I don't see how USART2 could be affecting things if you never enable the interrupt. I don't think USART interrupts are enabled in the Init functions.

[Tesla DeLorean]

Your example doesn't use interrupts.

Callbacks can/will block other interrupts if not carefully considered.

If interrupts aren't completely/properly serviced they will tail-chain indefinitely, and no foreground code will execute.

ie you enable TX IRQ, and then don't stuff data..

The HAL is a broken mess, there are complicated and unstated hazards. Use will caution.

The overall HAL really has so many dependencies on a SW ticker, that it needs the highest priority, and preemption level to ensure it keeps going.

Trapping at 0x1FFFxxxx suggests it's in ROM due to state of BOOT0, or that it power cycled with no code in FLASH, a reset is not a reset in the usual sense.

There's also some errata related to a FLASH. BANKING or OPTION BYTE setting, as I recall