• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1058 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.

TMS570LS3137 - DCC Offset?

Charles Johnston
Expert 2690 points
Other Parts Discussed in Thread: HALCOGEN

Hello,

I'm using DCC2 to compare the 16MHz oscillator (Count0) to a 9.974KHz PWM on N2HET2:0 (Count1).

I used HALCoGen to set up a 20% drift over 2.5 msec.  It set up Count0 = 25600, Count1 = 20, and Valid = 12800.  This results in a detect time start = 1.6msec, detect time end = 2.4msec, and Count1 time of 2msec.

To test, I expected that setting the Count1 time to 1.5msec and 2.5msec would generate an error interrupt; setting it to 1.7msec and 2.3msec would not generate an error interrupt. An error interrupt was not generated at 1.5msec, but was generated at 2.3 msec.

Using the single-shot measurement example in SPNU499 Section 11.2.2 as a guide, I set Valid = 6400 to make the detect time end = 2.0msec, and set Count1 = 100 to guarantee an error interrupt.  When Count0 and Valid = 0, Count1 = 16 on the first pass, then 18 on all subsequent passes.  This means that either 4 or 2 N2HET2:0 pulses were not counted.  I see where one pulse could be missed depending on the PWM output when the DCC counters were loaded.  I don't mind adding a dead band to our testing, but I have to be able to justify it.

1) Is this behavior because the two frequencies are so far apart?

2) Is there a delay before starting the Count1 decrement?

3) Are there any guidelines for calculating the offset?

Thanks, Charlie Johnston

 

  • 0
    TI__Guru 68920 points

    Charlie,

    There might be a lag in the start of the N2HET PWM.  I don't think that it would account for something on the order of 100us though, it would be on the order of a HET LRP which is usually 1us. 

    As you mention, the 20 cycles for the HET at 9.974KHz means that one edge difference (which might be a small delay) would change the value by 1/20th or 5% but again that's within the window that you setup.   The rest of the math looks ok to me for your first example.

    Can you try making the HET output faster to reduce the HET as a possible source of error - or make the compare duration longer which I think will have the same effect?

    Otherwise I think there may be more details to analyze but we'd need to look at the specific sequence in which the steps are taken in your code - how/when is the HET initialized relative to the DCC, etc.   Which would mean sending your code in.

  • 0 in reply to Anthony F. Seely
    Expert 2690 points

    Hi Anthony,

    When I increased the HET PWM from 10KHz to 100KHz, the delay was still 2 or 4 cycles. This reduced the error %, but the offset is still there.

    Before starting the DCC, I wait for the PWM signal on the HET pin to go high.  This insures that the HET is running before using it for comparison.

    I tried several timing variations - adding a wait loop between starting the HET and starting the DCC; starting the DCC, then waiting to enabling the error interrupt - no improvement.

    We're using HR Clk = 90MHz and LR period = 355.556 nsec.  Our HET loop timer CNT = 281, so our PWM = 9.974KHz. 

    Thanks, Charlie

  • 0 in reply to Charles Johnston
    TI__Guru 68920 points

    Hi Charlie,

    So if you wait until the HET pin goes high, and then start the DCC, I think you probably miss the first edge from the HET but incur most of the period which would be like missing at least 1 count.  I'm not clear from the TRM to be honest whether the DCC is counting rising, falling or both edges.    But you would think that you could justify an offset of at least 1 count this way.

    Would you please help me understand the 2 or 4 cycles delay?   Do you mean that the pass / fail window appears to be shifted by what amounts to either 2 or 4 cycles for the first compare period?

  • 0 in reply to Anthony F. Seely
    Expert 2690 points

    Hi Anthony,

    You are right, I would expect an offset of 1 count to allow for any PWM state when the DCC is started.

    The pass/fail window appears to be shifted by 4 cycles for the first compare period, and 2 cycles for each subsequent compare period.  In the example above with the PWM @ 10KHz, the seeds and valid are set up such that Count0 and Valid will reach 0 at 2msec and Count1 will never be zero.  When the DCC stops on error, Count1 will contain the number of cycles counted over 2msec.  This comes in at 16 for the first compare period and 18 for all others. This corresponds to 4 PWM cycles and 2 PWM cycles.

    When I increased the PWM to 100KHz, the Count1 values were 196 and 198.   This also corresponds to 4 PWM cycles and 2 PWM cycles.

    Thanks, Charlie

  • 0 in reply to Charles Johnston
    TI__Guru 68920 points

    Charlie,

    There are 2 stages of synchronization between the control signals you 'write' and the counters, and the synchronization is based on the counter clock period.   Also the rising edge of the clock is used.


    So let's say you miss the 1st edge of the PWM from N2HET due to the order in which the PWM is enabled v.s. the DCC counter.   Then you enable the DCC counter, but this enable signal doesn't propogate to the actual counter until the 2nd and 3rd edges of the PWM occur.  So the first 'count' of the slow counter would occur on the 4th PWM edge.

    Whereas for the counter that is running much faster, it would appear to be counting already well within that 1'st cycle of the HET's PWM - it has the same delays but they are a small fraction of the PWM period so they are negligible.

    After the startup, the 2 stages of sync probably explain the 2 counts of offset in the result. 

    This is all based on a quick inspection of the RTL code but hopefully combining it with your experiments that's enough to justify setting your thresholds with the observed offsets.

  • 0 in reply to Anthony F. Seely
    Expert 2690 points

    Hi Anthony,

    This explains exactly what I'm seeing.  

    Thank you very much.

    Charlie