Hi,
I have some assembly for Cortex M4 (Arm 7M Thumb), I want to enable an interrupt that is connected to a push button on an STM32 F407. It works, but for some reason when I enable the set enable register, the clear enable register also gets set ? Is this normal ?
NVIC_BASE EQU 0xE000E100NVIC_ISER0 EQU NVIC_BASESETENA6 EQU 1 << EXTI0_IRQn
EnableButtonINT PROC ;Enables the interrupt for the blue pushbutton LDR r0, =NVIC_ISER0 ;set enable interrupt from EXTI0_IRQn channel LDR r1, =SETENA6 STR r1, [r0] BX LR ENDP
So the code above results in 0x40 on set enable AND clear enable registers !
The reason I ask is that I seem to be getting two interrupts all the time. I've put a debounce on so my flow is
1. Enable interrupts
2. On button interrupt - toggle LED, disable button interrupt (for debounce), use the systick timer to get another interrupt in 200ms
3. On systick interrupt (200 ms after button press), re-enable button interrupt again ie debounce finished
So I'm disabling the button interrupt to prevent repeated button interrupts when user is really only pressing ovce (typical debounce). But I get an interrupt for button on, then when the re-enable occurs I get another one straight away (I've cleared enabled and pending).
Thanks for the reply, just finished reading your book actually on the M3 and M4 (very good). If you dont mind I have a few more questions on interrupts,
Thanks again Joseph.
Having separate set and clear registers avoid some race conditions where the interrupt enable/disable are modified inside ISRs. Without separate registers, you need read-modify-write (RMW) to change a register, which can lead to the following scenarios:
- ISR X read interrupt enable register
- ISR X modify the enable bit in software (not write back yet)
- IRQ Y (higher priority) arrived and pre-empted
- ISR Y modify its enable control by another RMW
- ISR Y exit and returning to ISR X
- ISR X write back enable control, which over-written the modification done by ISR Y.
With separated SET and CLEAR, you can modify the control using a single write, hence avoided this RMW race condition.
Your question number 2 is not very clear - I guess you mean what happen if a new IRQ event arrive when the ISR is running? The interrupt pending status is clear as it entered the ISR, and when the IRQ event arrive again during the execution of ISR, then the pending status is pended again. So when the ISR exit, the pending status will cause the processor to handle the interrupt again.
Regarding 3
Disabling interrupt (clearing enable, excluding special cases of using PRIMASK/FAULTMASK/BASEPRI) does not clear the pending status, and it is possible for the interrupt to be trigger just at the same time. This is documented in one of the application notes:
http://infocenter.arm.com/help/topic/com.arm.doc.dai0321a/BIHHFHJD.html
regards,
Joseph
Thanks for the answers. I can see now that a seperate set and clear allows the the changing of the interrupt state to be atomic and therefore prevent a pre-emption from causing a race condition by stale read/modify/write.
The biggest problem I seem to be having is when I clear the active interrupt it seems to set up another pending interrupt sometimes (this can be affected by debugging). This seems to be made less frequent by adding a DSB after I clear pending in my ISR (as the ISR clears pending and disables interrupt). Also for my debounce when systick interrupt ISR has been called many times (to give me a 500ms delay), when I re-enable interrupt I sometimes get another pending. Pending interrupts seem to be pretty flaky, and I seem to have spent 80% of my development time for this small app debugging them. I really think disabling an interrupt should clear active and pending of that type also, I understand this would not be able to clear any current active interrupt that is currently executing and has been pre-empted, but if I'm turning it off then I really don't want any ISR to be exectued for it. I can't turn off all interrupt (global state), as I'm using the systick interrupt for a debounce expiration notification.