freeRTOS scheduler start resets EXTI-PR1 register

Kernel
1

Hello everyone. I have encountered a problem regarding the start of freeRTOS task scheduler. I configure EXTI interrupt on GPIO PA3. When I launch scheduler (only 1 task present during testing), it’s starting procedure retests the PR1 register of EXTI to 0 (value should remain as 12).

Interrupt itself works without problems as long as I don’t start scheduler. Using breakpoints I managed to track the following call stack before register modification:

vTaskStartScheduler

  • xPortStartScheduler()
    • prvPortStartFirstTask()
      • vPortSVCHandler()
        • prvTimerTask()
          • prvGetNextExpireTime()

register resets immediately when the function prvGetNextExpireTime() is called, without executing any instruction other than creating TickType_t xNextExpireTime variable.

Does anyone have any idea how to fix it, or the only choice is a workaround by remembering register’s value before it resets ?

2

Sounds weird… and I think there is a problem somewhere else.
The FreeRTOS timer code is completely unrelated to EXTI registers.
Are you sure your ISR is not invoked (and cleared the PR1 bit) ?
Starting the scheduler enables interrupts so maybe a pending IRQ kicked in.
Did you define configASSERT and also enable stack overflow checking for development/debugging. I’d strongly recommend to do so since it really helps a lot !
Did you configure the (NVIC) interrupt priorities right ? For Cortex-M MCUs this might be confusing.
I’d recommend to read the FreeRTOS docs regarding RTOS for ARM Cortex-M .
Also e.g. Understanding priority levels of ISR and FreeRTOS APIs - #16 by aggarg contains a good and easy to understand explanation.

BTW which MCU or FreeRTOS port is it and which FreeRTOS version is used ? It’s always good to add this information.

3

MCU is STM32L452RE, and RTOS version is V10.3.1 I believe (downloaded it from ST repository for L4xx MCUs).

I believe that ISR does not run, because in it, I change bool variable to false, and later in the task, the task actually hangs in loop while said variable is true.

4

I’d propose to set a breakpoint in the ISR to verify. Since it seems that you don’t use FreeRTOS API in the ISR the interrupt priorities are not important. Although busy polling for a (volatile ?) flag in a task is not a recommended design when using a multitasking RTOS.
And is your FreeRTOS application basically running properly ?