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

Cycle count in cortex m3

Note: This was originally posted on 10th December 2009 at http://forums.arm.com

Hi all,
I am new to cortex m3...
For my application I need to calculate the number of cycles for a particular function....
I set the debug options as high optimization level and optimize for time....

How can I calculate the MIPS/cycles manually for a particular function.
Please suggest me a solution...

Thanks in advance.
Krish.
  • Note: This was originally posted on 10th December 2009 at http://forums.arm.com

    Thanks for the reply....
    does armulator serve my purpose?
    If so how to start with realview debugger?(any settings).

    The low tech solution:

    Run it in a loop a _lot_ of times.
    Use a stop watch.
    ((Seconds * MHz) / Loops) = cycles per loop.
  • Note: This was originally posted on 11th December 2009 at http://forums.arm.com

    Thanks Marcus,

    so we can access the DWT only by connecting the board?
    I tried like this but did not work....

    int count = 0;
    int *DWT_CPICNT = (int *)0xE0001008; //address of the register
    *DWT_CPICNT = 0; // reset the counter
    .......
    ......
    count = *DWT_CPICNT;

    can you please suggest me how to access the DWT unit without the board?

    Thanks & regards,
    Krish.
  • Note: This was originally posted on 12th December 2009 at http://forums.arm.com

    Thank you very much.....

    I am really very happy for the support from you all.....

    Thanks Marcus and Joseph.....

    I'll try it and get back to you.......

    Thanks....
    Krish
  • Note: This was originally posted on 10th December 2009 at http://forums.arm.com

    The low tech solution:

    Run it in a loop a _lot_ of times.
    Use a stop watch.
    ((Seconds * MHz) / Loops) = cycles per loop.
  • Note: This was originally posted on 10th December 2009 at http://forums.arm.com

    If so how to start with realview debugger?(any settings).

    The ISSM for Cortex-M3 is semi-accurate. It models an ideal memory sub-system. Not sure about the pipeline accuracy, but I guess CM3 is simple enough.

    If you are really concerned about accuracy, get a cheap eval board and read the cycle count register in the DWT unit.

    Regards
    Marcus
  • Note: This was originally posted on 11th December 2009 at http://forums.arm.com

    so we can access the DWT only by connecting the board?
    I tried like this but did not work....

    Not sure if this part of DWT is modelled in ISSM. Did you follow the initialisation procedure in the Cortex-M3 TRM?

    Regards
    Marcus
  • Note: This was originally posted on 11th December 2009 at http://forums.arm.com

    Hi Krish,

    I few things you need to do:
    1. Define the registers as "volatile", and "unsigned"

    2. Enable TRCENA bit in DEMCR (0xE000EDFC, bit 24) before using DWT

    3. You should use DWT's Cycle Count Register (0xE0001004) for timing measurement.
    The CPI counter is only 8-bit, and need to have trace support to detect the number of time it overflow.
    While the DWT Cycle Count Register is 32-bit.

    4. You need to enable the Cycle Count counter.

    So based on the code you have prepared, it can be modified to:
    int count = 0;
    volatile unsigned int *DWT_CYCCNT = (int *)0xE0001004; //address of the register
    volatile unsigned int *DWT_CONTROL = (int *)0xE0001000; //address of the register
    volatile unsigned int *SCB_DEMCR = (int *)0xE000EDFC; //address of the register

    *SCB_DEMCR = *SCB_DEMCR | 0x01000000;
    *DWT_CYCCNT = 0; // reset the counter
    *DWT_CONTROL = *DWT_CONTROL | 1 ; // enable the counter
    .......
    ......
    count = *DWT_CYCCNT;

    I haven't test this code in hardware but it should work.... :-)
    The ISSM might not have the detail model of debug components, so it is best to do the timing measurement on actual hardware, either on actual microcontroller or on our FPGA prototyping system.

    Note that if the debugger you are using is trying to use this counter at the same time (e.g. if you have got some sort of profiling feature turn on in your debug environment), you might find incorrect profiling result by doing this.

    regards,
    Joseph