Profiling on baremetal embedded systems (ARM)

Question

I am wondering how you profile software on bare metal systems (ARM Cortex a8)? Previously I was using a simulator which had built-in benchmark statistics, and now I want to compare results from real hardware (running on a BeagleBoard-Xm).

I understand that you can use gprof, however I'm kind of lost as that assumes you have to run Linux on the target system?

I build the executable file with Codesourcery's arm-none-eabi cross-compiler and the target system is running FreeRTOS.

Lotze

Answer 1

Closely evaluate what you mean by "profiling". You are indeed operating very close to bare metal, and it's likely that you will be required to take on some of the work performed by a tool like gprof.

Do you want to time a function call? or an ISR? How about toggling a GPIO line upon entering and exiting the code under inspection. A data logger or oscilloscope can be set to trigger on these events. (In my experience, a data logger is more convenient since mine could be configured to capture a sequence of these events - allowing me to compute average timings.)

Do you want to count the number of executions? The Cortex A8 comes equipped with a number of features (like configurable event counters) that can assist: link. Your ARM chip may be equipped with other peripherals that could be used, as well (depending on the vendor). Regardless, take a look at the above link - the new ARMs have lots of cool features that I don't get to play with as much as I would like! ;-)

Heiduc

I was thinking if it was possible to use any profiling tool like gprof to gather information about various data like clock cycles, call graphs, time spent in each function, amount of calls. However im glad if i can get how many clock cycles it takes to run the application from start to finish. The link you gave me was nice, I will look into that, Thx! – Lotze

Hi, I got the clock cycle counter working, however I'm wondering if it's possible to time a function with the PMU (performance monitor unit)? I also have a flyswatter 2 debugger, maybe that can be used for something? Do I need to buy a data logger or oscilloscope to time hardware? I have never used any of those, and they are pretty expensive! – Lotze

Here is a reasonably priced logic analyzer. It worked well enough for me: nci-usa.com/frame_products_overview.htm. Some of the PMU stats can be exported to the ETM - from there it may be possible to access them using Flyswatter's JTAG interface. (I'm just guessing). – Heiduc

For simple function call timing, you might consider writing using the PMU's clock counter. Save the clock count at the top of the function, then compare it at the end of the function. This should give you a reasonable estimate of the clock counts that occurred in between. I wouldn't expect the overhead of monitoring the clock count register to affect your function timing in any significant way. – Heiduc