• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1501 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.

TMS570LC4357: Details on HALCoGen HET CAP functions

1138
Expert 1226 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

We're looking into using N2HET pins to measure pulse trains by using HALCoGen to generate CAP code.

HALCoGen can generate a "capGetSignal()" function which "Gets current signal of the given capture signal."  (Requires that we have used HALCoGen to have mapped our selected pins to the HET CAP blocks.)

This function reports "duty cycle in %" and "period in us".

I am assuming that this is reporting the data for the single, most recently captured complete period, is that correct?  (That the underlying HET micromachine code is not doing any averaging over time of multiple periods, for example.)

capGetSignal() is performing two successive reads on data from HET RAM.  Are there any atomicity issues we should be aware of, where the HET micromachine could be updating one or both of them at the same time that we're reading them, resulting in us getting invalid data?

Are there any side effects from performing these reads?  (Does reading them reset them in any way?)

capGetSignal() is performing a division using a value read from HET RAM as the divisor, without confirming first that that value is non-zero.  What can we do prior to calling capGetSignal() to ensure that we won't have an error?

--thx

  • 0
    TI__Guru**** 198546 points

    Hello,

    The capture code generated by HALCoGen uses PCNT instruction to capture the high/low pulse time or period of the input signal. PCNT doesn't do any averaging over time of multiple period.

    Reading NHET RAM is similar to read the value from register. Reading the duty cycle and reading the period is not synchronized, may be in different LR loop.
    The NHET instructions have a feature allowing to automatically clear the data field immediately after the data field is read by the host CPU or DMA. This feature is enabled the control bit (bit C26).

    If PCNT is configured for automatic read clear, then when the CPU reads the PCNT data field it will be cleared automatically. The CPU can then poll the PCNT data field again, and as long as the field returns a value of zero the host CPU program knows a new capture event has not occurred. If the data field were not cleared, it would be impossible for the CPU to determine whether the data field holds data from the previous capture event, or if it happens to be data from a new capture event with the same value.

    When the NHET module is enabled, the microcode in NHET RAM starts execution, and PCNT starts to capture the edges of the input signal. If the period of the input signal is very long, and you read the period value immediately after thye NHET module is enabled, you might get a zero value for the period. For this special case, you need modify the code (capGetSignal())to make sure the period is not equal to zero beore doing division. Another way is to use interrupt feature of the PCNT instruction.

    Regards,
    QJ

  • 0 in reply to QJ Wang
    Expert 1226 points
    Hello QJ,

    Thanks for following up!

    So, you've identified two scenarios where the period stored in HET RAM could be zero, resulting in a division by zero problem if we called capGetSignal() at the wrong time:

    1) Data field was cleared automatically during an earlier read because control bit C26 was set.
    2) No period has yet been captured.

    Are there other scenarios where the period could be 0? Is it possible for a pulse to be long enough that it gets noticed and captured by the microcode, but short enough that its value is stored as 0?

    --thx
  • 0 in reply to 1138
    TI__Guru**** 198546 points
    Hello,

    If the NHET clock is 100MHz, the highest resolution is 10ns. The pulse should not be too short. You need make sure that the data in PCNT data field is ready before you read it.

    The #1 is not a problem, if the data field is not zero, you get the non-zero value before the data field is cleared automatically.

    Regards,
    QJ
  • 0 in reply to QJ Wang
    Expert 1226 points
    Hello QJ,

    Are you saying that if a pulse is shorter than (or equal to?) a LR cycle, it won't be captured by the HALCoGen black box HET CAP code at all, and if the pulse is longer than an LR cycle, then the pwmPeriod read inside capGetSignal() will be greater than zero?

    --thx