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

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ScWi_1017771
Level 2
Level 2
First like given

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.

FirstSecondInterrupts.png

PWM config:

Advanced tab is Enable Mode:  Software Only.  Run Mode:  Continuous.  Trigger Mode:  None.  Kill Mode:  Disabled.  Capture Mode:  none.  No interrupts selected.

PwmConfig.png

4th (intermittently missed) interrupt:  isr_RgbFrame is configured as DERIVED.

OriginalTimerInterrupt.png

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.

0 Likes
4 Replies
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi Scott,

We could not find any known issue similar to this. Could you please share your project so that we could recreate the issue at our end. A simple project with minimal components where the issue can be recreated might be sufficient.In PSoC Creator ,  go to File -> Create Workspace Bundle -> Select minimal. Please attach the generated file.

Best Regards,
Vasanth

0 Likes

Hi Vasanth,

I appreciate your attention to this issue.  Unfortunately the issue is difficult to reproduce, and goes away when we attach a short stub of wire to a trace, ditto attaching an oscilloscope probe, which has made collecting oscilloscope traces difficult.  There is clearly a hardware component and I suspect a timing component, which our specific circuit conditions can reach.  It seems to me that demonstrating it would require at least sending you an instance of our hardware, instructions / accessories to allow powering it up and the schematics; more likely this would require my meeting with you to demonstrate the issue with an oscilloscope, a development system (to allow making changes), etc.  This seems expensive and difficult to arrange.

What I ask instead is that an engineer inspect the PSoC 5LP interrupt controller and determine whether it is possible for (near-)simultaneous rising-edge triggered interrupts of the same priority to result in:

  • Both interrupts are cleared, however we observe that intermittently:
  • Only one interrupt is serviced

Perhaps due to a metastable state.

Does timing analysis (for the PSoC Creator version we use) include the interrupt controller?

This is a regulated system nearing release; changing interrupt priorities would require significant design and testing time and expense.

0 Likes

Hi Vasanth,

Is is possible to send the project file privately?  I do not wish to post it publicly.

Thank you,
Scott

0 Likes
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi Scott,

Did changing the priority of the interrupts solve the problem in any way ?

Best Regards,
Vasanth

0 Likes