• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 349 subscribers
  • Views 11398 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Cortex-A7 generic timer

hostia

Hi ARM expert,

    I am trying to use generic timer, but seems the generic timer wasn't enabled. My steps are:

  1. Set CNTFRQ with 1MHz
  2. Set CNTP_CVAL with 100
  3. set CNTP_CTL with 0x00000001

   4. Read CNTP_CTL in a loop, wait for bit 2 of CNTPCTL to be 1, and then break.

  I expected that it would delay 100us and then break the loop, but the bit 2 of CNTPCTL was never to be 1. I read the CNTPCT, the number was always 0 while I expected the number should increment.

    I also set CNTP_TVAL with 100, and expected it would decrements to 0 after about 100us, but i read the CNTP_TVAL, the number didn't change, it was always 100. 

    I think i must make some makes during init generic timer, but i reviewed RM, seems there is nothing should be done except i have done.

    For the CNTFRQ, I saw the description: "Typically, the system drives the system counter at a fixed frequency and the CNTFRQ register must be programmed to this value during the system boot process." Feel confusion if the number pushed to CNTFRQ should related the real frequency ARM core running? For example, the ARM run with 480MHz, does this frequency affect the CNTFRQ setting? Or i can push any value, such as 1Hz, or 1MHz to CNTFRQ?

  • 0 Arm Employee Badge

    It might help to take a step back, and start with how the Generic Timer works.

    GT.png

    What you have in the core is set of comparators.  These compare the value in a register (e.g. CNTP_CVAL) against the system count.  It is the system count value that gets reported in CNTPCT.  The system count is not generated by the processor, but by a system component.  This component provides a fixed frequency count, which is distributed to all the different cores in the system.  Giving them a common reference.

    CNTFRQ is intended to report the frequency of the count, it does not in any way control/configure the frequency.  The SoC's firmware would initialize the Counter Module (or whatever name that SoC gave to the thing generating the count), and set CNTFRQ to report the frequency.  Software higher up in the software stack, such as the OS, can use CNTFRQ to get the frequency.

    If CNTPCT is not incrementing, it usually means you haven't set up the Counter Module yet.

  • 0 in reply to Martin Weidmann

    Hi Martin,

        I really misunderstood the generic timer before, thanks for your reply!!

        For the CNTFRQ register, seems it is no useful if no other program need know the current frequency of counter. I means the counter and timer can work well even if didn't configure CNTFRQ register. Is it right?

  • 0 Arm Employee Badge in reply to hostia

    Sort of.  The question is how would you know what the frequency was.

    For firmware, this is SoC/board specific.  Therefore "knowing" what the frequency is doesn't tend to be a problem.

    For an OS, you might have one binary which can run on a number of different platforms or on the same platform in a number of different configurations.  So it's helpful to have a standardized to report to higher level software the frequency.  That's what CNTFRQ is intended for.