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.

NHET multi-pin capture and HR bits?

This is I guess a continuation of

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/501774

I'm trying to capture 4x input channels in High Resolution.

I built a naive NHET program and ran it in the simulator, and the HR bits in the captured timestamps seem temporally incorrect (out of order).

Specifically, I set HR=1, LR=8, 80MHz with this program:

L00: CNT  {next=L01, reg=A, max=0x1FFFFFF }
L01: WCAP {next=L02, reg=A, pin=CC2, event=RISE, cond_addr=L02, hr_lr=HIGH, data=0, hr_data=0 }
L02: WCAP {next=L03, reg=A, pin=CC4, event=RISE, cond_addr=L03, hr_lr=HIGH, data=0, hr_data=0 }
L03: WCAP {next=L04, reg=A, pin=CC6, event=RISE, cond_addr=L04, hr_lr=HIGH, data=0, hr_data=0 }
L04: WCAP {next=L00, reg=A, pin=CC8, event=RISE, cond_addr=L00, hr_lr=HIGH, data=0, hr_data=0 }

And created a Stimulus file (HET IDE won't let me copy/paste) which triggers pins (2,4,6) high at cycles (5,15,10) and low at cycles (25,30,35),
repeating every 50 cycles. The goal was to (a) keep the input frequency lower than the loop frequency, (b) have a high probability of multiple
captures within a loop and (c) have the captures out of order wrt the program.

In the second input cycle, WaveViewer indicates that pin 6 indeed triggers 5 HR clocks (62ns) before pin 4, but the Memory window indicates
pin 4's capture Data (LR,HR)=(9,2) and pin 6's (LR,HR)=(9,4).

That seems to say that pin 4 went high before pin 6, when actually the opposite was the case. It also seems to say that the captures were
2 clocks apart rather than 5, which is somewhat more than rounding error.

Is this an artifact of the "synchronization" mentioned in the note "WCAP in HR mode" in sec 17.5.3.23? Or am I just missing something obvious?

  • Bruce,

    Did you run an entire loop after the edges are visible on the waveviewer?

    There is a sort of pipeline delay. At the beginning of the loop the state of the Hires counters are 'sampled' so to speak.

    So let's say that loop #5 begins. At the beginning of this loop the edges haven't happened. The WCAP execution during loop #5 will
    be as if there are no edges detected.

    Now during loop #5 the edges occur and are captured by the hires counters. Then loop #5 ends/loop #6 begins. Now the sampled hires have new captures and during the execution of loop #6 - the WCAP instructions will timestamp this into memory.

    So if you just execute up until the signals appear into wave-viewer, and you don't execute the following loop, there are pending captures that have not made it to RAM yet.

    -Anthony
  • Update: Comparing Fig 17-23 (spnu596a) and my WaveViewer output, it appears that actually the HR field is correct, but the LR field isn't.

    Pin 4 triggers in slot 2 of loop 8, and is captured in loop 9 (this is unsurprising). Pin 6 triggers in slot 4 of loop 7, but is not captured until loop 9 (this is surprising).

    Am I maybe looking at an artifact of the simulator?

    [Edit: Fixed Figure number.]

  • Check that you do not have the input filtering on for pin 6. The input filter adds a delay between the pin and N2HET.
    Doubt you have this on but if you are really getting this result it could explain it.
  • Thanks for the response.
    My procedure was: I stepped until the Memory tab updated, then backed up the WaveViewer to check the signals.
  • The simulator (Registers tab) claims that NHETSFENA[31:0] = 0x0.
    For good measure: NHETSFPRLD:CCDIV = 0x0 and :CPRLD = 0x0.
  • I tried exchanging the pin definitions between L02/L03 (L02 monitors pin 6, and L03 pin 4), and the (LR,HR) still indicate that pin 4 triggered first, and I see the skipped-loop artifact on pin 6. This suggests that the WCAP ordering (vs signal ordering) doesn't matter.

    The HR values are 1/5 rather than 2/4, but given the skipped-loop I'm not sure that means much. It does seem odd that the HR values changed at all, though, given that the signal properties didn't change.