All OSEK AUTOSAR implementations include structures that describe current state of the OS (current task, current ISR...). This structure is place 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:
RUNNINGTASK[1] = "OS_kernel_ptr[1]->taskCurrent";
RUNNINGTASK[2] = "OS_kernel_ptr[2]->taskCurrent";
RUNNINGISR2[1] = "OS_kernel_ptr[1]->isrCurrent";
RUNNINGISR2[2] = "OS_kernel_ptr[2]->isrCurrent";
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.
You need to find the symbol (or memory location) that this pointer points to:
1.Start the application and run until the point where the OS is initialized.
2. 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.
3. Open the View menu / Symbol Browser / Variables.
4. Sort the variables by address.
5. Search for the symbol (structure) that is the closest match to the address you found.
6. Expand the structure with a double-click and look for the element with the address you found earlier.
7. Use this variable to replacethe pointer which was initially specified as RUNNINGTASK/RUNNINGISR. From above example that would be:
RUNNINGTASK[1] = "(OS_kernelData_core1).taskCurrent";
RUNNINGTASK[2] = "(OS_kernelData_core2).taskCurrent";
RUNNINGISR2[1] = "(OS_kernelData_core1).isrCurrent";
RUNNINGISR2[2] = "(OS_kernelData_core2).isrCurrent";
8. Save the changes to the ORTI file.
Sorry this article didn't answer your question, we'd love to hear how we can improve it.
Note: This form won't submit a case. We'll just use it to make this article better.
{{ topic.Content }}