It seems that using the comparators with interrupts on the stm32f373 series with HAL drivers blocks the program in infinite loop.

[Nicolae Mihalache]

I attach the full code as a file and the relevant part here - for the evaluation board STM32373C-EVAL in which the red LED blinks a few times until the comparator is activated and blocks the execution.

Is there a workaround to make the comparator work with interrupts and the HAL library?

Thanks!

/* USER CODE BEGIN 2 */

 HAL_DAC_Start(&hdac1, DAC_CHANNEL_1);

 HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_1, DAC_ALIGN_12B_R, 1000);

 /* USER CODE END 2 */

 /* Infinite loop */

 /* USER CODE BEGIN WHILE */

 int lTick = HAL_GetTick();

 int count = 0;

 while (1)

 {

 int tick = HAL_GetTick();

 if(tick - lTick >= 500) {

 lTick = tick;

 count ++;

 HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_2);

 if(count == 6) {

 // will block the main program

 HAL_COMP_Start_IT(&hcomp1);

 }

 }

 /* USER CODE END WHILE */

[Tesla DeLorean]

You'd need to what you're doing in the interrupt handlers and call-backs.

For the HAL tick to work under interrupt context the SysTick interrupt must preempt all others.

The processor will not leave interrupt context if the interrupt source is not cleared properly, it will be stuck tail-chaining, and not foreground execution with occur.

[Nicolae Mihalache]

I have not implemented the callback routines in order to show that there could not be any conflict there. You can check the attached file main.c for that. It was created with CubeMX with library version 10.0 for F3 series. With the exception of the comparator and ADC1, all peripherals are on the default configuration for the evaluation board.

I had this problem previously for the same MCU on another project, which was stripped of any other code and all other hw modules were not initialized. The same code with the comparator that blocks on the F3 series works just fine on a STM32F051.

[Achau.13]

I am also facing same issue were you able to resolve this issue?

[ELowe]

Still no solution to this problem?

It seems you can not even start comparator with or without interrupts on my nucleo board H743ZI.

I am using comparator as an over-current protection for my inverter power stage. Comparator1 and ADC1 share the same pin for current sampling purposes (PB0).

My application starts, calls MX_COMP1_Init() and continues to run normally. So by this time comparator gets configured, but does not get started.

Afterwards I am not calling HAL_COMP_ Start or any other HAL function, I am letting my application run normally.

After some time I manually set bit 0 (EN: COMP channel 1 enable bit) in comparator configuration register 1 (COMP_CFGR1), the application suddenly stops, nothing else gets executed after that moment. I can set this bit via system viewer in Keil IDE.

If I decide to start comparator via HAL drivers, it gets stuck in infinte while loop which counts waiting time.

This is the problematic function:

HAL_StatusTypeDef HAL_COMP_Start(COMP_HandleTypeDef *hcomp)
{ 
  __IO uint32_t wait_loop_index = 0;
 
  HAL_StatusTypeDef status = HAL_OK;
  
  /* Check the COMP handle allocation and lock status */
  if((hcomp == NULL) || (__HAL_COMP_IS_LOCKED(hcomp)))
  {
    status = HAL_ERROR;
  }
  else
  {
    /* Check the parameter */
    assert_param(IS_COMP_ALL_INSTANCE(hcomp->Instance));
 
    if(hcomp->State == HAL_COMP_STATE_READY)
    {
      /* Enable the selected comparator */
      SET_BIT(hcomp->Instance->CFGR, COMP_CFGRx_EN);
 
      /* Set HAL COMP handle state */
      hcomp->State = HAL_COMP_STATE_BUSY;
 
     /* Delay for COMP startup time */
     /* Wait loop initialization and execution */
     /* Note: Variable divided by 2 to compensate partially    */
     /*       CPU processing cycles.                           */
    
     wait_loop_index = (COMP_DELAY_STARTUP_US * (SystemCoreClock / (1000000 * 2)));
     while(wait_loop_index != 0)
     {
       wait_loop_index--;
     }      
    }
    else
    {
      status = HAL_ERROR;
    }
  }
 
  return status;
}

I don't have any clue what to do next?????

[ELowe]

So far I have determined that bad things start to happen with interrupt enabled, irrelevant if they are really used:

Rising edge event does not cause this problem.

 I presume something went wrong in CubeMX code generation with EXTI lines.....will continue my research....

[Achau.13]

This is how i managed to fix the issue ​https://community.st.com/s/question/0D50X00009XkhHNSAZ/cubemx-422-stm32f37xx-lib-19-comp-irq-bug

[ELowe]

In the mean time I found a way how to live without comparator's interrupts.

Nevertheless thank you for sharing this with us.