Profiling on C28x Targets
From Texas Instruments Wiki
- 1 Introduction
- 2 Profiling Data Collection
- 3 Profiling Solutions for C28x Targets
- 4 Accessing the Profile Clock via Scripting
- 5 Profiling in Sys/BIOS
- 6 Frequently Asked Questions
- 7 Enabling Profile Data Collection
- 8 Other Resources
- For a C28x target, profiling data collection is not enabled in Code Composer Studio by default.
- This article describes how to enable profiling data collection if desired, and suggests solutions for profiling without using the Code Composer's data collection.
Profiling Data Collection
- Code Composer Studio's profiling data collection is described in this wiki article. This resource is not enabled for the C28x based MCUs by default. This is because most profiling activities on C28x devices are for code in flash. The hardware function profiling is breakpoint based, so it is not very useful for code within flash due to limited hardware breakpoint resources.
- If code is based in RAM, then the profiling data collection can be enabled and tried (see Enabling Profile Data Collection at the end of this article). It should be noted that this is not tested on C28x targets and is a use at your own risk feature.
Profiling Solutions for C28x Targets
- Here is a list of other solutions that can be used to profile functions within Code Composer Studio:
- Option1 - Profile Clock
- The profile clock uses silicon resources to count cycles between two breakpoints.
- When using the profile clock in flash, it is important to free-up as many hardware breakpoints as possible. On c28x you have two analysis resources available at one time. One resource can be used as a hardware breakpoint, watchpoint, or counter. The other one can only be used as a hardware breakpoint or watchpoint. In order to profile, you need to use the analysis counter which uses up one of your resources so now you only can set one hardware breakpoint. Code Composer Studio will by default set a breakpoint for C I/O (printf etc) and the end of program marker. When profiling, make sure the following options are unselected so the breakpoints will not be used up by these options:
- Program load options:
- Under Program/Memory Load: Uncheck "Halt at program termination"
- Under Program/Memory Load: Uncheck "Enable C I/O function use"
- Optional: Select "Remember my settings" at the bottom of the configuration screen.
- To setup the profile clock:
- In the debug perspective go to
- Run to a breakpoint at the start of the function.
- Double click on the clock - this will clear its value.
- Run to a breakpoint at the end of the function
- The clock will display the delta.
- Option 2 - CPU Timer
- Another option customers like to use is to start a CPU timer counting at the SYSCLKOUT frequency.
- Read the clock before the call
- Read the clock after the call
- Subtract the two to get a delta
- Option 3 - GPIO Pin
- Another option is to use a GPIO pin:
- Pull the pin low/high before the function
- Pull it high/low after the function
- Read the delta on a scope
Accessing the Profile Clock via Scripting
- The following script may aid in accessing the profile clock through scripts in CCS 5.x.
- Please see the script comments for a description of what it is doing. It should be modified for the project specific symbols.
- More information on DSS scripting can be found here:
Profiling in Sys/BIOS
- SYS/BIOS provides a 'Timestamp_get32()' API that can be used to benchmark code. To use this API, you will need to modify your target code to include these APIs. This is similar to the CPU timer method mentioned above.
- In your app.cfg:
Timestamp = xdc.useModule('xdc.runtime.Timestamp');
- In the app.c file:
#include <xdc/runtime/Timestamp.h> UInt32 t0, t1; t0 = Timestamp_get32(); algo(); t1 = Timestamp_get32(); time = t1 - t0;
- The API function Timestamp_getFreq() can be used to get the frequency of the Timestamp counter.
Frequently Asked Questions
Q: Cycle counts for 'step-by-step' and 'run to line' do not match?
- When single stepping, each instruction goes through the whole pipeline. And then on the next step, the next instruction will go through the whole pipeline, etc. There is no potential for a resource conflict between two instructions since each instruction goes all the way through the pipeline by itself.
- If you run or run to line, however, there is the potential for pipeline stalls.
- Consider the case where your code is in the same block as data. If you try to read data you can not fetch an opcode at the same time and there will be a stall. Same thing for trying to read and write on the same pipeline cycle.
- There are other things that can stall the pipe like CPU register conflicts but these are less obvious to spot.
- Refer to this wiki article for more information C28x Pipeline Conflicts.
Enabling Profile Data Collection
- As mentioned previously, this functionality is disabled in Code Composer for the C28x by default. This is because the C28x has limited hardware breakpoints which are required when using this feature in flash. If you are executing from RAM, you may find it useful. Note: function profiling for C28x is not officially supported (untested).
- To enable HW function profiling with CCSv4 for C28x:
- Browse to <INSTALL DIR>\ccsv4\DebugServer\bin\win32\SerializedProfileActivities
- Open 'ProfileFunctionsHW.prof_ini' in a text editor
- Under the list of ISA, add 'TMS320C28' to the list
- Save file and restart CCSv4
- The 'ProfileFunctionsHW.prof_ini' should now look something like:
[Name] Profile all Functions for CPU Cycles [Events] dataclass.pcdt.events.Cycles dataclass.pcdt.events.CPU Cycles dataclass.pcdt.events.cycle.Total [EventClasses] pcdt [ISA] TMS320C28 TMS320C56 TMS320C55 TMS320C621x TMS320C641x TMS320C671x TMS470R1 TMS470R2 TMS470R3 TMS470Rd TMS470Re .....
To discuss technical questions, the E2E Community is a great resource. Visit e2e.ti.com.
Forums on the E2E site include:
and many more...