winIDEA Help

In this topic:

•Requirements

•Configuration steps

 

 

Introduction

Symbols specified as RUNNINGTASK, RUNNINGISR2 are used to show the OS state during debug when the CPU is stopped. OS Profiling, however, can be implemented in two different ways. Either through:

•data trace (if supported by the MCU) or

•instrumentation trace (OTM, ITM, SofTrace, User Trace Port...)

 

By default data trace is used for OS Profiling, the only prerequisite is to have RUNNINGTASK, RUNNINGISR2, specified as simple variables (not pointers to these variables). If your ORTI file uses vs_SIGNAL specifications, these specify the instrumentation trace method that will be used for trace (instead of data trace). In such cases you need to make sure that the application is correctly instrumented.

 

All OSEK implementations include structures that describe the current state of the OS (current task, current ISR...). This structure is placed in a fixed memory location and it's address needs to be known in advance in order to trace it.

ORTI generators often specify a pointer to this structure, which can easily be followed by OS awareness plugins, but unfortunately can not be directly traced.

 

An example of such ORTI configuration would be:

 

In this case the RUNNINGTASK / RUNNINGISR are given as pointers, which can not be resolved by the trace engine and therefore can not be used for OS signaling.

To circumvent this limitation, you need to find the symbol (or memory location) that this pointer points to.

 

 

Requirements

•Established debug connection

•ORTI description file

 

 

Configuration steps

 

Pay attention to the address the RUNNINGTASK / RUNNINGISR pointer points to by inspecting the correlating variable in the watch window (e.g. OS_kernel_ptr[1]->taskCurrent). In our case this was 0x51800840.