Skip to main content
Nicolae Mihalache
Associate II
October 17, 2018
Question

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

  • October 17, 2018
  • 7 replies
  • 2891 views

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 */

    This topic has been closed for replies.

    7 replies

    Tesla DeLorean
    Guru
    October 17, 2018

    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Nicolae Mihalache
    Associate II
    October 18, 2018

    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
    Visitor II
    September 24, 2019

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

    ELowe
    Associate III
    March 22, 2020

    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
    Associate III
    March 23, 2020

    0693W000000UYDOQA4.pngSo 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
    Visitor II
    March 24, 2020

    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
    Associate III
    March 30, 2020

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

    Nevertheless thank you for sharing this with us.