Missing SCTimer input events on LPC812

[timcarney]

I am developing an input signal period monitor using the SCTimer on the LPC812. I have configured a simple state machine with two states.

The initial state (0) waits for an event to signal the first rising edge transition of the input signal. When this event occurs, we store the value captured in the capture register and transition to the running state (1). Once in the running state, we continue to monitor the input signal for rising edges. Each time a rising edge is detected, we use the value in the capture register to determine the number of ticks that have occurred since the last event and report this to the application to calculate the frequency of the input signal.

This works most of the time, however, I frequently see frequencies reported at half of the actual frequency. The LPC812 is running at 24 MHz and I'm attempting to record frequencies on the order of 10 Hz.

I have implemented this using an LPCXpresso812MAX development board and a function generator connected to P0_14 (SCT_IN0).

Looking at frequencies near 10 Hz, I see about 5% of my readings reporting double the period I expect. It appears that transitions on the input pin are being missed. Changing the frequency of the input signal shows similar behavior.

Another curious note is that I see the event that triggers the transition from the initial state to the active state occurs more than once. I expected the SCTimer to begin in the initial state waiting for a transition on the input pin and then transition to and remain in the active state permanently. I cannot explain why I see this transition occur more than once. It is possible that I've misconfigured the SCTimer causing it to reset during runtime?

Any feedback on my use of the SDK calls is appreciated.

Thanks in advance,
Tim

[timcarney]

I've simplified the application to demonstrate what I believe is the root problem. 

I now have a single state with events triggered on both the rising edge and falling edge of the input signal. I then added toggle actions to an output pin to occur with *either* of these events occur. I expect to see transitions on the input signal and output signal in synchronization when looking at both with a 2-channel oscilloscope. Instead, I see the output transitions *most* of the time the input transitions.

I have attached the source code as well as an oscilloscope screen capture of the input (yellow/top) trace from a function generator and the output (purple/bottom) connected to the SCTimer output pin.

[jeremyzhou]

Hi Tim Carney,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
It's recommended to set the sync option when detecting edge sensitive input.
Please give a try.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ianbenton]

I was fooled by this - reading the manual it seems like like using INSYNC is optional. It isn't. If you don't use INSYNC it doesn't work.

[jeremyzhou]

Hi,
I think you misunderstand it. I'd highly you to recommend to a SCTimer application: https://www.nxp.com/docs/en/application-note/AN11538.zip , in the application, it illustrates an example of the input synchronization
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[timcarney]

Thank you. That seems to have solved this problem. I have a couple related questions:

1. Is there a reason that the SDK clears all of the INSYNC bits inside of SCTIMER_Init()?

2. When I configure the halt condition register with one of the asynchronous input events, I see the timer occasionally fail to restart when I clear the halt bits in the callback function. Attaching a debugger, halting the controller and resuming restarts the SCTimer. Is there a problem using the halt conditions on events that have the INSYNC bit set?

Also, if I halt the SCT to reload a match register and then restart it inside of the callback functions, I see no issues.

Thanks again,

Tim

[jeremyzhou]

Hi Tim Carney,
1) 1. Is there a reason that the SDK clears all of the INSYNC bits inside of SCTIMER_Init()?
-- I think it may be ignored.
2) When I configure the halt condition register with one of the asynchronous input events, I see the timer occasionally fail to restart when I clear the halt bits in the callback function. Attaching a debugger, halting the controller and resuming restarts the SCTimer. Is there a problem using the halt conditions on events that have the INSYNC bit set?
-- No, the INSYNC bit value is impossible to interfere clear the HALT bit, as they'are independent.
I'd highly you to recommend to a SCTimer application: https://www.nxp.com/docs/en/application-note/AN11538.zip which illustrates a variety of example and usage for the SCTimer in LPC, please refer to it.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[timcarney]

@jeremyzhou Thank you for your response. I understand that the INSYNC bit should not interfere with the HALT bit. My application is successfully running if I halt, set the match register and restart the SCTimer inside of the callback function.

Can you explain the behavior I described in #2 above?

Can you please explain why the INSYNC bits are cleared by default when using the driver included with SDK_2.4.2_LPCXpresso812MAX?

[jeremyzhou]

Hi Tim Carney,
1) Can you explain the behavior I described in #2 above?
-- It seems so weird, and I've not replicated the phenomenon on my site. So I was wondering if you can share a compile-able demo which can replicate this weird phenomenon, then I can dig much deeper.
1) Can you please explain why the INSYNC bits are cleared by default when using the driver included with SDK_2.4.2_LPCXpresso812MAX?
-- In my opinion, it's a 'flaw' in the SDK and I'll give the feedback to the SDK develop team later.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[timcarney]

@jeremyzhou Thank you again for your feedback. I have created my application using the Rowley CrossStudio IDE. I believe the behavior should be easy to reproduce. While looking over my application again this morning, I realized that I am making an assumption when using the SCTIMER_SetupCounterHaltAction() and SCTIMER_SetCallback() APIs together. 

Is it guaranteed that the SCTimer will halt the counter before calling the callback function? I am clearing the HALT bit in the callback function and that is only safe to do if the callback is guaranteed to be called after the counter has been halted.

To reproduce this, I have created a callback function that is called when an input transitions on a rising edge. I connect a function generator to this input and use the SCTimer to measure the period between consecutive rising edges. When I use the SCTIMER_SetupCounterHaltAction() API and force my function generator to make a drastic change in the periods (order of magnitude), I will often see the timer halted indefinitely.

Simultaneously, I am using the SCTimer to make sure that we see two rising edges in a certain window. If the match register event ever occurs, we do not report a period. For this reason, I need to modify the contents of the match register inside of my SCTimer callback function. Since that can only be done when the timer is halted, I first tried to use the SCTIMER_SetupCounterHaltAction() API to halt the counter and then restart it before returning from the callback functions.

However, if I remove the SCTIMER_SetupCounterHaltAction() from my application and instead halt and restart the counter in the callback in order to modify the match register, I see no problems.

The UART driver is different, but the contents of the attached file show all of the relevant SCTimer API calls. You will see the calls to halt the counter on the events on lines 215-217 have been commented out since I tried to halt the counter inside of each of the callback functions.

[jeremyzhou]

Hi
I don't have the LPC812 board on hand now, as we're during the National holiday (1~7th Oct), and we'll go to the office at 8th, Oct after the National holiday ends, meanwhile, I'd like to suggest you port the application to any one of MCUXpresso, IAR, Keil IDE, it can save more time for me on testing
Thanks for your understand.

Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[timcarney]

@jeremyzhou Thank you for looking into this. At this time, we have a suitable alternative by halting and restarting the counter inside of the callback function. 

I understand reproducing this issue in a supported IDE will help. While this is a reasonable request, I need to spend my time on the development of our product at this time. If you have time to look further into this issue, I am curious to know what you find, but this issue is not causing us any problems in our current design.

Thank you again for your time and attention to these issues. Please enjoy your time off.

-Tim