Camila_99$$
DIIDevHeads IoT Integration Server
ā¢Created by Camila_99$$ on 10/2/2024 in #firmware-and-baremetal
Why Does Disabling OCIE1A Cause Immediate ISR Re-trigger on Mega 2560?
Hii guys šš Iām creating lighting variations on PORTA with a MEGA 2560 board.
I am using a zero-cross detection that triggers an interrupt, which calls the "void passage_a_0" function.
A command (continuous action on a button) modifies a lighting level setting from 1 to 25. This setting adjusts the phase delays corresponding to the lighting level.
I have an issue with the ISR interrupt. Below is the simplified code of the two related interrupts: Problem:
With the
However, if this instruction is removed, the variation works correctly, taking into account the OCR1A values for the phase delay. But depending on the value of OCR1A, the ISR is called several times before the next zero-cross.
Why is the ISR triggered immediately in the presence of 'bitClear'?
Is it a code error or a defective board?
I am using a zero-cross detection that triggers an interrupt, which calls the "void passage_a_0" function.
A command (continuous action on a button) modifies a lighting level setting from 1 to 25. This setting adjusts the phase delays corresponding to the lighting level.
I have an issue with the ISR interrupt. Below is the simplified code of the two related interrupts: Problem:
With the
bitClear(TIMSK1, OCIE1A);
instruction in the ISR, which is necessary, the ISR is executed immediately as if OCR1A were set to 0.However, if this instruction is removed, the variation works correctly, taking into account the OCR1A values for the phase delay. But depending on the value of OCR1A, the ISR is called several times before the next zero-cross.
Why is the ISR triggered immediately in the presence of 'bitClear'?
Is it a code error or a defective board?
3 replies