4 Replies Latest reply on Jan 9, 2020 1:54 PM by ScWi_1017771

    Intermittent missed edge-detect interrupt for coincident interrupts from different sources


      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.


      PWM config:

      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:

      1. The behavior is intermittent, averaging once every few minutes
      2. Soldered 1..2" 30ga wire stubs to several signals and connected scope probes:  the issue stopped occurring.
      3. Took off the scope probes, leaving only the wire stubs:  issue still did not occur.
      4. Took off the wire stubs:  issue started occurring again.
      5. 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:

      1. Insert an EdgeDetect_v1_0 (to avoid multiple triggers during the 4us "tc" high cycle),
      2. Add CyStatusReg_v1_90 set to "sticky" (to persist the interrupt request until the software acknowledges with a read) and
      3. Configure interrupt as DERIVED

      appears to resolve the issue, however this leaves the following questions:

      1. Is this a known issue?
      2. 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.