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

CC2650 RTOS Analyzer shows 100% CPU Load for simple application

Eric Wilbur
Intellectual 780 points

Other Parts Discussed in Thread: CC2650, SYSBIOS

I am working on the labs for the TI-RTOS workshop to include the CC2650 as a target. We walk users through each of the TI-RTOS modules - Hwi, Swi, Task, Queue, Mailbox. So I am working on the Swi lab.

I am using:

-CCS6.1..2

-RTOS version 2.16.0.08

-CC2650 Launchpad

-commented out the ROM definitions in the .cfg file so that UIA works properly, enabled Logs in BIOS-Runtime

-Load Buffer size (LoggingSetup) set to 512 bytes 

-power policy (.enablePolicy = FALSE) - this allows me to trigger an interrupt every 500ms without going into standby

I modified the "empty" driver project, removed Task, added a driverlib timer that triggers an interrupt every 500ms. The ISR posts a Swi which toggles the LED. The code builds fine and runs perfectly. The "toggle LED" function takes 31uS which I was able to measure on the Exec graph just fine - just like the other four architectures that are supported in this workshop.

However, the CC2650 reports 100% CPU load both in the CPU Load graph and the Live Session view.

Time not spent in IDLE? I know the Hwi is not being tracked. I don't track those on the other processors either. But the Swi runs and toggles the LED and it takes 31uS which is 1488 cycles running at 48MHz. Most architectures report about a 1% load in this lab. 100% shocked me.

Is CPU Load calculated differently on this device? Or am I doing something wrong?

Thanks,

  • 0
    TI__Mastermind 22760 points

    Hi Eric,

    The default TimestampProvider for CC26xx devices is the 32 KHz RTC timer.  This is too coarse for getting an accurate CPU load.  You can use the m3 TimestampProvider instead.  Just add the following code to your .cfg file:

    var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
    Timestamp.SupportProxy = xdc.useModule('ti.sysbios.family.arm.m3.TimestampProvider');

    Best regards,

        Janet

  • 0 in reply to janet
    Intellectual 780 points
    Thanks Janet.

    I noticed that when I added the device-specific Timestamp support in the std Timestamp module, "Use Clock's timer" was greyed out and checked which made me think that Timestamp was using Clock's timer which was RTC. But I wasn't sure. The fact that timestamp is using a 32kHz clock certainly explains the "zeroes" in the math. This was the same with MSP430 but we switched clocks to use SMCLK instead of ACLK on that target for the same reason.

    When using the Timestamp module on CC2650, there was no choice I could find in the GUI to switch clock sources. If I uncheck "Use Clock's timer", the only ID of a timer I can use is "Id 0". But then I get an error that says "no timers are available". So, it seems that the ONLY choice via the GUI is using the same clock source (RTC) for both Clock and Timestamp.

    I assume then, there is no way to add the code you mentioned to the .cfg file via the GUI, right? I will assume this is true and test it out.

    Does your suggestion then switch over to using SysTick at the rate of CPU Clock? I assume yes.

    When I used the script code you suggested, Timestamp_get32() worked perfectly and gave me proper results.

    Thanks Janet - much appreciated.
  • 0 in reply to Eric Wilbur
    Intellectual 780 points
    FYI - my CPU Load went down to ZERO vs. 100%. This is what I expected. I added a small load and it showed up as 1%. So in another post, this solved the 100% CPU Load issue.
  • 0 in reply to Eric Wilbur
    TI__Mastermind 22760 points
    Hi Eric,
    I wasn't able to configure the Timestamp provider through the GUI, so I don't think it is possible (or if it is, it is certainly easier to configure the script directly). Glad to hear your CPU load is as it should be now.
    Best regards,
    Janet
  • 0 in reply to janet
    Intellectual 780 points
    So when you add the code you suggested, which clock source is being used by Timestamp? Is it SysTick?

    Regarding the code vs GUI, that's fine. It is only one line of code and easy enough to teach to students.

    Thanks again Janet. As usual, you nailed it. ;-)

    I have another post out there asking about Clock vs Timestamp sources. You cleared up the Clock/Timestamp defaults, but there are other questions there I'm still curious about. In fact, once you answer the single question in this post, I will respond to the other one and answer myself.

    Thanks
  • 0 in reply to Eric Wilbur
    TI__Mastermind 22760 points
    Hi Eric,
    Yes, the m3 Timestamp provider uses the SysTick timer, running at the CPU frequency.
    Best regards,
    Janet
  • 0 in reply to janet
    Intellectual 780 points
    Thanks Janet. I will post my own answer to my other question then.

    In another post:
    e2e.ti.com/.../411592

    Scott Gary said "On CC26xx the kernel’s Clock module uses the RTC underneath (which stays alive across power saving modes). And if Timestamping is used in your app, the M3’s SYSTICK timer will be used for that. "

    When I read that, I was confused by the possible "combining" or "split" of the Clock and Timestamp clock sources. His post is a year old, but you may want to post something at the bottom of that thread because what you have said to me vs his statement contradict each other. It is possible that it WAS that way initially, but due to power issues, the decision was made to take out the script code you told me to use in future versions of TI-RTOS. So this conflict could be just a time thing and both are right.

    Also, when I post my answer to my own post on Clock vs Timestamp, please read it and verify it is true and right so that other users get it right when they read it.

    Thanks,