Are there any known issues for the interrupt controller, for simultaneous, same-priority, edge-triggered interrupts?
Using CY8C5868AXI-LP035 (PSoC5 LP) at 5.0V, 24MHz reference oscillator in a system with multiple interrupts.
Using PSoC Creator 3.2 SP1 (tool set is frozen due to verification requirements).
Three of the interrupts occur in a sequence (group of three) occurring at 240Hz group repetition rate.
- First interrupt timing is generated via a PWM_v3_30 block (fed by 1MHz) "tc", interrupt configured DERIVED. We haven't seen any missed interrupts.
- Second interrupt timing from the PWM "pwm1" signal, interrupt configured RISING_EDGE. We haven't seen any missed interrupts.
- Third interrupt from an ADC_DelSig_v3_20 "eoc" signal, triggered by "pwm2", interrupt configured RISING_EDGE. We haven't seen any missed interrupts.
The fourth (problem) interrupt is driven by the 'tc' signal from a Timer_v2_70 component with a 16.4ms period (60.97Hz), fed by a 250kHz clock, configured as RISING_EDGE. Intermittently this interrupt is missed, averaging once every few minutes.
All interrupts are priority 7.
Timing analysis says "No Timing Violations".
Edit: Original circuit:
1st, second interrupts: 1st is "isr_NextChannel", 2nd is "isr_MuxSwitch" configured RISING_EDGE.
Advanced tab is Enable Mode: Software Only. Run Mode: Continuous. Trigger Mode: None. Kill Mode: Disabled. Capture Mode: none. No interrupts selected.
4th (intermittently missed) interrupt: isr_RgbFrame is configured as DERIVED.
It appears that when the second (edge-triggered) interrupt coincides with the fourth interrupt, intermittently the 16.4ms period interrupt is missed:
- The "tc" signal was routed to a spare pin; it did still occur when the interrupt was missed.
- The ISR was set to pulse a spare pin; it was not called for that cycle, although:
- It was called for the previous and next cycles.
- Other interrupts continued to be serviced (showing that interrupts were not left disabled).
What makes this particularly difficult is that it appears to be a Heisen-bug:
- The behavior is intermittent, averaging once every few minutes
- Soldered 1..2" 30ga wire stubs to several signals and connected scope probes: the issue stopped occurring.
- Took off the scope probes, leaving only the wire stubs: issue still did not occur.
- Took off the wire stubs: issue started occurring again.
- The same doesn't-happen-with-probe-wires behavior occurred on another board of the same design (not just the one PSoC).
The only thing I can think of is a race condition or metastable state in the interrupt controller, when two interrupts of the same priority coincide: sometimes the edge-detected timer interrupt gets cleared, but then the coincident "second" interrupt gets cleared and serviced.
A work-around of:
- Insert an EdgeDetect_v1_0 (to avoid multiple triggers during the 4us "tc" high cycle),
- Add CyStatusReg_v1_90 set to "sticky" (to persist the interrupt request until the software acknowledges with a read) and
- Configure interrupt as DERIVED
appears to resolve the issue, however this leaves the following questions:
- Is this a known issue?
- Validation of functionality is quite extensive and expensive. How can I either control (or compare) the generated logic layouts, to prevent (or determine whether) timing shifts for the pre-existing logic due to adding the EdgeDetect and CyStatusReg components?
Thank you in advance!
Message was edited by: Scott Willis. Added schematics and configuration images.