DET Overview

Micael Coutinho, • autosarbswdet
Back

There is nothing more frustrating than debugging a module on a giant architecture, such as Autosar. Learn how the Development Error Tracer (DET) helps

Picture this: you are assigned a task to configure an Autosar module, such as CAN-TP (we already covered it here. If you want to learn about it, read our article CAN-TP Overview (opens in a new tab)), and after your initial configuration, you flash your code and it does not work! It could be worse, it is very common to get a software reset. Nonetheless, where do you start debugging in the giant codebase that is Autosar? Probably enabling the DET (Development Error Tracer) is your best bet. We already gave a very subtle definition on the DET, in our article What are DEM, DLT, DCM and DET (opens in a new tab), but today we will go a bit further.

So, what does the DET add to the table? Basically, it consists of a cluster for all runtime errors detected in the Autosar modules. It provides some basic error information, but that in most cases is enough for you to know the next steps to get it fixed, or, at least, know where to start. The error information provided consists of:

To use the DET on a specific module, you just have to enable development error detection for the module and you are good to go! They are not enabled by default, as too much information is also overwhelming and difficult to find problems on. It is something you need to keep in mind: you should only enable DET for modules you are starting on or experiencing issues! In the end, you will remove it anyway, as it is a development module. Now, there are two questions that need answer: how do we see the errors and are we allowed to add customized errors for our own components? Let's tackle these one by one:

How do we see the Errors?

You have some options when it comes to seeing the DET errors. You can set a breakpoint on the error reporting API, use hooks and instrument some variables to log the errors in a RAM buffer or send the errors via a communication interface, through the DLT (Diagnostic Log and Trace). We'll cover this module in greater detail someday.

Let's focus on the APIs available: there are 3 types of errors that can be reported: DevelopmentError, RuntimeError and TransientFault. Each of them can have its own hook configured and implemented by the user, allowing for some extra flexibility. These APIs have the same function signature, so, we'll analyse one of them:

Where to find the Service ID, as per Autosar Specification { w: 816, h: 551 }

Where to find the Service ID, as per Autosar Specification

Next, the InstanceId. This parameter is dependent on the number of instances of your module. It is usually set to 0, as most of the time you only have 1 instance of each module. And to the last one, ErrorId, it's usuallly found under Error Classification for each module. Taking the PDUR as an example again:

Where to the Error ID, as per Autosar Specification { w: 788, h: 583 }

Where to find the Error ID, as per Autosar Specification

Regarding the hooks, they contain the same function signature, so you receive the same data as the error reporting function, and can act upon it. Just be careful, as these hooks can be called anywhere, including interrupts.

Are we Allowed to add Customized Errors for our own Components?

The answer is a resounding yes. The moduleId can go up until 65535. In a BSW module, you can use the error reporting functions described before, where above the RTE you have a DET service port, containing all the client-server interfaces for you to communicate the errors. If you don't know about interfaces and ports, it's a good time to check our article Types of Interfaces and Ports (opens in a new tab), to learn how this all works.

Alright! That is all for today. We hope this article made you comfortable with the DET concepts. It's a very useful module, and, in my opinion, it's not properly exploited by us, end users the Autosar layered architecture. Make sure you stay tuned for more articles to come, by subscribing to our weekly mailing list, as there is a lot more to come!

Author: Micael Coutinho (opens in a new tab)

References:

© AutosarToday —@LinkedIn