• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 801 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LM4F232 CCP pin as edge detection

Hailin Jiang
Intellectual 730 points

Hi

I have used the CCP pin to do the falling edge detection. With the help of scope, I have found that sometimes it detects the rising edge instead. The input clock is about 1.6MHz. The code to configure the pin is as follows. Any suggestions to make it reliable? Or is there any specific requirement to the input clock?

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOL);    
    SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2);
    GPIOPinConfigure(GPIO_PL4_T2CCP0);
    GPIOPinTypeTimer(GPIO_PORTL_BASE, GPIO_PIN_4);

    // configure the timer to capture falling edge once
    TimerConfigure(TIMER2_BASE, TIMER_CFG_SPLIT_PAIR|TIMER_CFG_A_CAP_COUNT);    
    TimerControlEvent(TIMER2_BASE,
                        TIMER_A,
                        TIMER_EVENT_NEG_EDGE);    // _BOTH_EDGES, _POS_EDGE
    TimerLoadSet(TIMER2_BASE,
                    TIMER_A,
                    1);
    TimerMatchSet(TIMER2_BASE, TIMER_A, 0);

Thank you,

-Hailin

  • 0
    Guru 117855 points

    Four quick comments:

    a)  Repeat your testing - but by employing a "GPIO-Only" pin.  Test/observe if rising edge (illegal) detection also occurs.  (it may be that your test signal is not as "pure" as you think - or it may be some complication added by the timer)  Can report that we've used M4F without issue - both falling-only and rising-only edges.  Kindly report the results of your investigation.  Also wise to switch to another Timer - "just in case."  (you have many - this MCU)

    Should the "GPIO-Only" pin reject your rising edges - appears that indeed there is undesirable Timer sensitivity.  If not - perform (b thru d, below).

    b)  Can you link the frequency of the "sometimes" detected - illegal rising edges to any count or timer "roll-overs" or similar?  And do provide a superior description of fault frequency.  (beyond dreaded "sometimes" - once a minute, hour, year, half-life of radium...)

    c) Often a noise burst or spike can "ride-along" your injected signal - and over-drive your input.  Carefully check - even better "voltage-clamp" your signal so that this cannot occur. 

    d) How have you determined that the illegal "rising edge" impacts (triggers) your timer?  How have you eliminated other sources of MCU disruption - which may be causative?

    *** this post just prior to yours of 11:11 - kindly respond should you seek further guidance (fm this reporter)

  • 0
    Intellectual 730 points

    When I looked hard at the waveform, there is another reading. So I should ask this question instead:

    Is it possible to control the jitter after the falling edge? How to make it shorter than the half cycle of the clock? In my case, the period is more than 600ns.

    Thanks.

  • 0 in reply to cb1_mobile
    Intellectual 730 points

    cb1_mobile said:

    a)  Repeat your testing - but by employing a "GPIO-Only" pin.  Test/observe if rising edge (illegal) detection also occurs.  (it may be that your test signal is not as "pure" as you think - or it may be some complication added by the timer)  Can report that we've used M4F without issue - both falling-only and rising-only edges.  Kindly report the results of your investigation.  Also wise to switch to another Timer - "just in case."  (you have many - this MCU)

    Should the "GPIO-Only" pin reject your rising edges - appears that indeed there is undesirable Timer sensitivity.  If not - perform (b thru d, below).

    Switched to another CCP pin. Still the same result.

    cb1_mobile said:

    d) How have you determined that the illegal "rising edge" impacts (triggers) your timer?  How have you eliminated other sources of MCU disruption - which may be causative?

    I have stripped down my code to the minimum. The clock is free running. Within the timer interrupt handler, pull another GPIO from high to low. Use the scope to capture the waveform. Sometimes the time between the falling edge of the clock and the falling edge of this GPIO is well greater than the half-cycle. Any suggestion to minimize the MCU disruption?

  • 0 in reply to Hailin Jiang
    Guru 117855 points

    Hailin Jiang said:
    Switched to another CCP pin. Still the same result.

    My goal was to first "isolate" GPIO from Timer - to learn if the Timer pin has this sensitivity to illegal rising edges.  Your "switch" to another CCP does not provide this insight.  Really need you to "temporarily" switch to a GPIO - NOT CCP pin. 

    You're making all of your tests via software - often experience teaches that hardware can provide fast/simple insights - which I believe will prove helpful...  (a,b,c,d are each there for a reason...)  None of your reports so far give me confidence that your input signal is not contributing to this issue...

  • 0 in reply to cb1_mobile
    Intellectual 730 points

    I have found the problem. It is another timer interrupt that I forgot to disable. This interrupt has higher priority. It would hijack the edge detection. This makes the longer jitter than expected.

  • 0 in reply to cb1_mobile
    Guru 117855 points

    cb1_mobile said:

    b)  Can you link the frequency of the "sometimes" detected - illegal rising edges to any count or timer "roll-overs" or similar?  And do provide a superior description of fault frequency.  (beyond dreaded "sometimes" - once a minute, hour, year, half-life of radium...)

    Believe that 1st diagnosis (above)  -  landed extremely close.   (even w/your system remote (unknown/unseen))   Yours really was not a Timer issue - instead your test code & method enabled "outside" events to color your judgement.  You may consider a more systematic - isolated method for future testing.   Glad you got it...

  • 0 in reply to cb1_mobile
    Intellectual 730 points

    Thanks for your reply. Actually after solving the problem, I have added another UART0 as debugging port. I could be able to say that "sometimes" is about 25% while repeating the test for hundred times. -Hailin

  • 0
    Intellectual 320 points

    Dear Hailin,

    Do you mind to share your coding?

    Regards,

    Dorene