HCS12 INPUT CAPTURE ISSUE

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

HCS12 INPUT CAPTURE ISSUE

778件の閲覧回数
rubykrishna
Contributor III

We are using Input capture in HCS12 family. We have some sporadic glitch in our time period calculation

Time period =( Overflow + present time stamp)- past time stamp

present time stamp is provided timer channel interrupt

Overflow is provided by timer overflow interrupt

We are using RTOS which uses timer tick interrupt which has a computation time of 30uS.

 

Anybody faced issue in time period calculation owing to this interrupt overloading ?

Please clarify?

Is it evident in HCS12 controllers?

 

150083_150083.pngpastedImage_0.png

ラベル(1)
0 件の賞賛
1 返信

491件の閲覧回数
RadekS
NXP Employee
NXP Employee

Hi Ruby,

I suppose that you use S12XHY or S12XE family (according to your previous thread https://community.freescale.com/thread/384422). Is it correct?

If I understood correctly your description, the timer tick interrupt routine sometimes causes a delay in input capture interrupt processing. Correct?

We will assume for now that timer interrupt has the highest priority from all pending interrupts.

Interrupt latency to start timer interrupt is typically given mainly by sum of:

  1. time to recognition of interrupt (typically 2 bus cycles for an external event)
  2. time to finish previous interrupt routine if any is active
  3. time to finish previous instruction (0..11 bus cycles)
  4. time for exception processing (9 bus cycles)

Both S12XHY and S12XE families contain Interrupt nesting feature - I bit maskable interrupt requests can be interrupted by an interrupt request with a higher priority.

I bit maskable interrupt requests cannot be interrupted by other I bit maskable interrupt requests per default. In order to make an interrupt service routine (ISR) interruptible, the ISR must explicitly clear the I bit in the CCR (CLI). After clearing the I bit, I bit maskable interrupt requests with higher priority can interrupt the current ISR.

In fact, the interrupt priority level must be greater than the current interrupt processing level in the condition code register (CCR) of the CPU (PRIOLVL[2:0] > IPL[2:0]).

So, you may clear I bit at begin of timer tick interrupt (for example: asm ANDCC #0xEF; or asm CLI;). After that, this ISR may be interrupted by any I-bit interrupt with higher priority – like input capture interrupt.

Of course, the designer should know which code may be interrupted and which code cannot be interrupted (critical sections) – especially in RTOS system solution. For protection these critical sections you may set I-bit (by command asm SEI;) at begin and clear I-bit (by command asm CLI;) at end of the critical section.


I hope it helps you.

Have a great day,
RadekS

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

0 件の賞賛