Fast interrupt problem on STM32F411

[Dodo]

Hello,

When I am using fast interrupts on ChibiOS they fire only once (sometimes twice), although the actual interrupt flag is still set. When using a normal interrupt it works perfectly.

I had this problem in a more complex project, but I tried to make a simple program where the same issue occurs to simplify debugging. I have set a up a timer in the CPU (TIM10) to generate a periodic overflow interrupt.

I have enabled this interrupt line using:

Code: Select all

   TIM10->DIER |=  TIM_DIER_UIE;
   nvicEnableVector(STM32_TIM10_NUMBER, STM32_TIM10_IRQ_PRIORITY); //Priority is 5 now.

The interrupt is then handled as follows:

Code: Select all

CH_IRQ_HANDLER(STM32_TIM10_HANDLER) {
    CH_IRQ_PROLOGUE();
    palTogglePad(GPIOA, GPIOA_TEST);
    TIM10->SR = 0;
    CH_IRQ_EPILOGUE();
}

This works, the line is toggled at the rate the timer is configured for. I do not need to use any chibios functions in the interrupt and it should have low jitter so I tried to use fast interrupts. I changed priority to 0 (the highest I believe) and the handler to:

Code: Select all

CH_FAST_IRQ_HANDLER(STM32_TIM10_HANDLER) {
    palTogglePad(GPIOA, GPIOA_TEST);
    TIM10->SR = 0;
}

The GPIOA_TEST line toggles only once or twice in this case. I see that the overflow flag in the timer status register is still set, so I would expect new interrupts to be generated.

I can make the fast interrupt work by putting __set_BASEPRI(0); as the last line of the handler. I don't really know why this works, but it is obviously harmful to do it.

Sincerely,
Dodo

[Giovanni]

Hi,

I missed this question, sorry for the late answer.

I am not sure about your problem but note that CH_IRQ_EPILOGUE() hides OS code and must never be used for fast interrupts.

The correct way to write fast handlers is the second you posted: CH_FAST_IRQ_HANDLER().

Giovanni

[Dodo]

Hi,

Thanks for the reply.

I gave the example with CH_IRQ_EPILOGUE() and a normal interrupt to show that the interrupt is actually working and firing continuously. The fast interrupt was implemented in the second way.

I was not able to get the fast interrupt to work, but the jitter caused by using a normal interrupt at the highest priority allowed was still within specification so I did that.

Sincerely,
Dodo