• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 318 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.

AM263P4-Q1: CPU Load Calculation In No RTOS

Kier
Mastermind 8855 points
Part Number: AM263P4-Q1

Tool/software:

Hello,

I have a core that runs a control loop using an EPWM interrupt plus other interrupts and ISRs.

I would like to measure the time spent in idle (i.e. not in the ISRs or any other code) in order to calculate CPU load.

The idea was to use WFI to measure the uninterrupted time as follows:

/* Record when uC goes to idle using a free run timer. */
wfi_ticks_start = CycleCounterP_getCount32();

/* Wait here until an interrupt occurs. WFI: Wait-For-Interrupt. */
CSL_armR5SetWFIMode();

/* If here, an interrupt has occurred. */
wfi_ticks_end = CycleCounterP_getCount32();
        
wfi_ticks = wfi_ticks_end - wfi_ticks_start;

However, the value of wfi_ticks is too small to be plausible. I suspect that when in low power mode (WFI), the cycle counter is also stopped giving low return values for CycleCounterP_getCount32().

<Q> Does the clock source for CycleCounterP_getCount32() stop when WFI is executed?

Thank you.

  • 0
    TI__Expert 4230 points

    Hi Kier

    I was testing the WFI api on gpio_input_interrupt example, and it wasn't waiting for me to press the button.

    So I tested the API on Hello World example, so I know no interrupts are configured. However my program was not Waiting for any interrupt, that's why the CPU cycles seem so low.

    I verified this with CCS profiling as well, and it doesn't look like the program is really waiting for interrupts.

    Are you able to verify the working of CSL_armR5SetWFIMode() API in your program, else I would have a discussion with the dev team to figure out the bug!

    Regards,
    Akshit

  • 0 in reply to Akshit Pareek
    Mastermind 8855 points

    Hi Akshit,

    While waiting for confirmation of my question above, I went ahead and implemented a SysCfg Timer (RTI5) and used the free-running counter there. My thinking is that the peripherals are not affected by WFI. I am now getting reasonable results so, in my case, WFI does seem to work and it also seems to prove that cycle counter does not count up during WFI.

    I don't know if it helps but on some processors you may need to disable interrupts:

    HwiP_disable(); \
CSL_armR5SetWFIMode(); \
HwiP_enable();

    The explanation for this is here: https://stackoverflow.com/questions/23305953/why-do-we-need-to-disable-interrupt-before-wfi-in-arm-linux-cpu-idle

    Having said, the disable/enable interrupt did not seem to make any difference in my case!

  • 0 in reply to Kier
    TI__Expert 4230 points

    Hi Kier

    Thanks for this information, I am glad you were able to figure out a way using RTI counter to benchmark the idle time.

    I'll file a bug and investigate into the reasons for CycleCounterP not working during WFI.

    Let me get back to you on that!

    Regards,
    Akshit

  • 0 in reply to Akshit Pareek
    Mastermind 8855 points

    Hi Akshit,

    Akshit Pareek said:
    I'll file a bug and investigate into the reasons for CycleCounterP not working during WFI.

    I'm not sure it's a bug per se.

    But what is the answer to my initial question: Does the cycle counter increase in WFI mode? Please confirm or not.

  • +1 in reply to Kier
    TI__Expert 4230 points

    Hi Kier,

    Kier said:
    Does the cycle counter increase in WFI mode? Please confirm or not.

    You're right cycle counter does not increase during WFI mode.

    CycleCounterP_getCount32() is implemented in PmuP_armv7r_asm.S

    /* FUNCTION DEF: uint32_t CycleCounterP_getCount32(void) */
        .global CycleCounterP_getCount32
        .type CycleCounterP_getCount32,%function
        .section ".text.pmu","ax",%progbits
        .arm
        .align 2
CycleCounterP_getCount32:
        MRC     p15, #0, r0, c9, c13, 0  // read PMCCNTR
        bx      LR

    As can be seen above, this API reads PMCCNTR to get the current clock count.

    The clock source for PMCCNTR (which CycleCounterP_getCount32() reads) is the processor core clock.

    When WFI is executed, the processor core enters a low-power state. In this state, the core clock is typically gated (stopped) to save power. Since PMCCNTR counts core clock cycles, it will also stop incrementing while the core clock is gated.

    To correctly measure the time spent in WFI, you need a timer that continues to run even when the CPU core clock is stopped. This typically means using a peripheral timer (e.g. a SysCfg Timer (RTI) as you used) that is clocked by a system clock or an auxiliary clock source that remains active during WFI.

    Regards,
    Akshit

  • 0 in reply to Akshit Pareek
    Mastermind 8855 points

    Great answer. Thank you!