Hello,
Is there an issue in the IQR_HANDLER for the encoder index pulse? https://github.com/vedderb/bldc/blob/be439a2a55ae5b1ba8cce8ad6b0da2d8046....
CH_IRQ_HANDLER(HW_ENC_EXTI_ISR_VEC) {
if (EXTI_GetITStatus(HW_ENC_EXTI_LINE) != RESET) {
encoder_reset();
// Clear the EXTI line pending bit
EXTI_ClearITPendingBit(HW_ENC_EXTI_LINE);
}
}
The last call in this function is to EXTI_ClearITPendingBit(HW_ENC_EXTI_LINE);
It seems the STM32 has a hazard with clearing the interrupt pending bit and then immediately returning. If an IRQ hander immediately returns after clearing the pending bit, it seems the STM32 may erroneously reenter the interrupt. So, people seem to add some instructions after ClearITPendingBit calls to avoid reentering the interrupt service routine.
From https://community.st.com/s/question/0D50X00009XkYyUSAV/timer-at-double-expected-speed-have-considered-clock-tree , "There is a pipelining/write-buffer hazard with the tail-chaining, your interrupt handler re-enters once immediately after it leaves. You should clear interrupt sources early, and ideally qualify the source." This person fixes the issue by having an instruction after clearing the pending bit. So, should CH_IRQ_HANDLER be:
CH_IRQ_HANDLER(HW_ENC_EXTI_ISR_VEC) {
if (EXTI_GetITStatus(HW_ENC_EXTI_LINE) != RESET) {
// Clear the EXTI line pending bit
EXTI_ClearITPendingBit(HW_ENC_EXTI_LINE);
encoder_reset();
}
}
Alternatively, this person addresses the issue by adding some NOPs after the ClearITPendingBit call: https://community.st.com/s/question/0D50X00009XkiGqSAJ/stm32f4-interrupt-pipeline-hazard . So, instead, should there be some NOPs after EXTI_ClearITPendingBit(HW_ENC_EXTI_LINE);
Here is another forum on the topic: https://community.st.com/s/question/0D50X00009XkbQcSAJ/is-calling-extigetitstatus-sometimes-unnecessary