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

enhanced time processing with TMS570-LC4357 (eCAP N2HET)

Achim Olaf Zacher
Intellectual 260 points
Other Parts Discussed in Thread: TMS570LC4357, HALCOGEN

Hi,

Is there any possibility (common hardware timebase) to change an output signal (N2HET) exactly xxx µs after detecting an edge or specific pulse with given pulse width  on an input signal (eCAP)?  (without estimating latency of an ISR and counting CPU states)

Is there any possibility to start periodic sampling (N2HET) exactly yyy µs after detecting a specific pattern (eCAP)?

Is there any possibility to switch one GIO exactly zzz µs after detecting a change on another GIO?

Is there any possibility to store the absolute CPU time of an event and start another event  relative to the first one? (sample code?)

Thanks in advance

  • 0
    TI__Guru**** 190806 points

    Hi Achim,

    Achim Olaf Zacher0 said:
    Is there any possibility (common hardware timebase) to change an output signal (N2HET) exactly xxx µs after detecting an edge or specific pulse with given pulse width  on an input signal (eCAP)?  (without estimating latency of an ISR and counting CPU states)

    Is there any possibility to start periodic sampling (N2HET) exactly yyy µs after detecting a specific pattern (eCAP)?

      'Exact yyy us' is a hard requirement. I don't think it is possible without some tolerance. You can get as close as possible to the granularity of  some cycles or timebase but not exactly down to absolute time. Can you feed your input to both the eCAP and NHET? If this is possible then you can write a NHET program to generate an output signal based on detection of the input?

    Achim Olaf Zacher0 said:
    Is there any possibility to switch one GIO exactly zzz µs after detecting a change on another GIO?

     Again you can write a NHET program to detect a change of state on one NHET input pin and assert an output on another NHET pin.

     

    Achim Olaf Zacher0 said:
    Is there any possibility to store the absolute CPU time of an event and start another event  relative to the first one? (sample code?)

      Can you not use the RTI to setup the compare interrupt?

  • 0 in reply to Charles Tsai
    Intellectual 260 points

    Hi Charles,

    searching the forum and the documentation I found
             _pmuGetCycleCount_()
    which might solve parts of my needs.
    Unfortunately it always returns zero.
    Is it still necessary to apply the patch from  http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/287375   ?

    I want to use it in Cortex R5F (TMS570LC4357)?

    Best Regards

    Olaf

  • 0 in reply to Achim Olaf Zacher
    TI__Expert 6985 points
    Olaf,

    You need to configure the PMU in HALCoGen to use counters other than the CPU cycle count.
    To us the CPU cycle count you still need to start the counter with the API provided by HALCoGen.
    Some code like the following should work:

    _pmuInit_();
    _pmuResetCycleCounter_();
    _pmuStartCounters_(pmuCYCLE_COUNTER);
    _pmuGetCycleCount_();
    _pmuGetOverflow_();

    However, please note that the PMU count's CPU cycles and will stop counting if the CPU is put into low power mode (wfi, wait for interrupt).


    As Charles mentioned you could write a NHET program to detect a pattern and switch an output accordingly. The NHET is designed to do these kind of stuff in a very deterministic way. The CPU however and especially in this part (cached) generally speaking isn't able to provide the same level of determinism.


    Your second use case should be fairly simple to implement with the NHET as Charles wrote. Detect an edge, start a counter and switch an output based on a compare value.


    I guess you asked about the PMU because of your third use case. Here I would rather try to use the RTI module to capture a counter value in HW. You can use the Interrupt (VIM) event capture feature for this (17.2.1.2 Capture Feature).
    Or again the NHET could be used for such a job.

    Best Regards,
    Christian
  • 0 in reply to Christian Herget
    Intellectual 260 points

    Thanks Christian,

    _pmuInit_();
    _pmuResetCycleCounter_();
    _pmuStartCounters_(pmuCYCLE_COUNTER);
    during initialization made it working.

    I expected the free running cycle counter to be running by default when enabled once in Halcogen. 

    Automatic stopping of the cycle counter could be helpful for performance estimation in debug mode? The result for a function call should be valid even if I run it single step in debugger?



    I was able to simulate some basic HET stuff in HET IDE.
    The real HET was always deactivated due to HET parity errors at address 0x60 (more than my HET code size). After temporarily disabling HET parity checking it was possible to execute the code.

    Setting VCLK2 to 100 MHz and Loop Resolution to 32 in Halcogen,
    I assumed to have 10ns HR HET resolution and 320 ns LRP.

    833,3333 µs / 320 ns = 2604,166

    With 2604 in a HET CNT instruction I expecteded aproximately 833 µs between periodic events but I found 1123 µs with oscilloscope. How can I explain the factor 1,3476? What is my mistake?

    With VCLK1 = 50 MHz and SCI4 Baud rate = 115200, there is no factor other than 1 between oscilloscope and TMS570. Serial communication with a 115200 baud terminal is possible.

    Best regards
    Olaf

  • 0 in reply to Achim Olaf Zacher
    TI__Guru 68920 points

    Olaf,

    Achim Olaf Zacher said:

    Setting VCLK2 to 100 MHz and Loop Resolution to 32 in Halcogen,
    I assumed to have 10ns HR HET resolution and 320 ns LRP.

    833,3333 µs / 320 ns = 2604,166

    With 2604 in a HET CNT instruction I expecteded aproximately 833 µs between periodic events but I found 1123 µs with oscilloscope. How can I explain the factor 1,3476? What is my mistake?


    Agree with your calculation of 833us.

    Assume you have confirmed you are actually running at 100MHz,

    with an LRP = 5 and an HRP = 0  so you have 0x500 in the het prescale register.

    So then ...   CNT does not directly toggle a pin.   So you cannot be measuring CNT itself with an oscilloscope.

    How is your pin being toggled?   That might be the missing puzzle piece.