• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 742 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.

C6657 Timer Interval

Jun.Jang
Prodigy 80 points

Hi,

I'm trying to get around 33.3MHz HWI interrupt interval by using TIMER3 on my evm6657 board with SYS/BIOS.

The real goal of this test is getting minimum time interval to drive a GPIO high/low repeatively.

Firstly, I choose TIMER3 and set its registers to work as 64-bit timer in continuous mode, triggering every 5clock peroid, like below.

    a) TIMER3_PRDLO = 4;     (5-1)

    b) TIMER3_TCR = 0x00880088;

    c) TIMER3_INTCTLSTAT = 0x00010001;

    d) TIMER3_TGCR = 0x00000003;

    e) TIMER3 event (ID:68) connected to CPU Interrupt 5 on the app.cfg file and a HWI ISR handles this interrupt.

My board is using 1GHz CPU clock(default). According to datasheet, C6657 TIMER module run on 166.66 HHz interal system clock(from SYSCLK7, 1GHz / 6) and it has 6ns period. Therefore, by seting period(PRDLO) with 4, I expect to get 30ns((4+1) * 6ns).

I checked that HWI ISR is called in regular interval with TIMER3, very well. However, when I check HWI ISR calling interval , I always got over 732 cycles value(from Timestamp_get32()  in ISR). No matter that I put other values under 125 into PRDLO(peroid) register, the results always give me around 732~750 cycles. Based on 1GHz CPU clock(1ns), 732cycles means 732ns. The result is really far from what I expect.

I meassured cycle time at my HWI ISR by calling Timestamp_get32() function in Log_info1() function.  For this logging , LoggferBuf and Timestamp has been included in app.cfg(SYS/BIOS) and Build env is SYS/BIOS 6.35.4.50, PDK C6657 1.1.2.6 and XDCTools 3.25.3.72.

Is there any period limitation when using TIMER module under 1us interval or Am I missing something?

- Jun

  • 0
    TI__Genius 12065 points

    Jun,

    There might be some overhead introduced by the ISR context switching and BIOS API calling. 

    So are you able to compare the Timestamp_get32() for different Timer event intervals please, such as 30ns vs 90ns?

    If the delta between different Timer intervals makes sense to you, the fixed overhead introduced by ISR and API might be calculated as well. You may try to read CPU TSC registers (TSCL/TSCH) directly instead of using BIOS API to see if could save some cycles. But the ISR context switching overhead might be hard to remove and you have to do some testing to get the limitation. 

  • 0 in reply to Steven Ji
    Prodigy 80 points

    Steven,

    Thank you for your reply. Even though I know overhead from SYS/BIOS, it's such a huge overhead.

    At this time, I used a oscilloscope to measure GPIO15's frequency directly and eliminate both Timestamp_get32() and Log_info1() functions from my ISR.

    As we both know, TIMER module use 'CoreClock/6', 166.66MHz(6ns). Therefore, if I set 1 to TIMER3_PRDLO register, then TIMER should trigger interrupt on every 6ns. However, it seems that as long as I use TIMER module from SYS/BIOS, then I couldn't get under around 275ns time interval.(Yes, It has been improved than when I called SYS/BIOS APIs)

    Following your mention, I tryed 30ns and 90ns by setting TIMER3_PRDLO as '4' (means, 30ns = 6ns * (4 + 1)) and '14' with oscilloscope. And both results was around 276ns and setting TIMER3_PRDLO with less than '42'(240ns) makes same result, around 276ns.

    When I tested GPIO driving interval before BIOS_start(), I got 70ns. I'm not sure 100% that those API's overhead is almost 500ns, but it's really huge.

    - Jun