MCAL Error Management

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCAL Error Management

Jump to solution
1,502 Views
MateoSegura413
Contributor III

Context:

We are using the MCAL drivers with our own system, which does not AUTOSAR. I’m trying to understand exactly how we can handle errors from the MCAL layer using the following AUTOSAR modules:

  • Default Error Tracer (DET)
  • Diagnostic Event Manager (DEM)
  • Diagnostic Communication Management (DCM)

In the paper attached to this post “SDK/MCAL to Real Time Drivers”, the following statement is made in Section 3.6

“The RTD provide a “stub” implementation of these ASR modules, which can be used or overwritten by the customer application”

MateoSegura413_0-1657871795378.png

We are currently using the SDK version below:

MateoSegura413_1-1657871826863.png

In that folder, there are all the MCAL drivers offered by the platform, as well as the stub files for the DET & DEM modules (DEM example shown below)

MateoSegura413_2-1657871855777.png

These files have stub functions in them, as mentioned, but this raises several questions that we would like to ask:

Questions:

1.Do I have to implement these stub files & modules at all?

  • Since the MCAL API returns synchronous and asynchronous errors, couldn’t the application writer provide their custom error handling, or are the DET and DEM modules needed for this?

2. If I were to Implement these files, would I do so in the location of the stub files?

  • Let's say we want to update the MCAL driver version, how would these files not disappear on updates if they're implemented in the stub folder location?

 

Thanks in advance for your time and help!

0 Kudos
1 Solution
1,492 Views
namnguyenviet
NXP Employee
NXP Employee

Hello @MateoSegura413,

1. Some drivers would report errors through DEM/DET according to their AUTOSAR requirements. It's up to application layer to whether implement its own custom errors report mechanism, or take advantage of DEM/DET error reporting. I would suggest to use the DEM/DET error reporting, since these DEM/DET APIs provide hints of errors (e.g. in case of an inappropriate configuration structure is put into the function, an E_PARAM_POINTER will be reported to DET, with corresponding module ID)

2. Because DEM/DET are stubs in RTD package, eventually you wouldn't have to update them, or just would have to modify some minor changes regarding the file versions, if there are new upcoming release. You can even create your own DEM/DET drivers: it's not mandatory to implement directly inside the DEM/DET stub location.

Best Regards,

Nam

 

View solution in original post

0 Kudos
2 Replies
1,493 Views
namnguyenviet
NXP Employee
NXP Employee

Hello @MateoSegura413,

1. Some drivers would report errors through DEM/DET according to their AUTOSAR requirements. It's up to application layer to whether implement its own custom errors report mechanism, or take advantage of DEM/DET error reporting. I would suggest to use the DEM/DET error reporting, since these DEM/DET APIs provide hints of errors (e.g. in case of an inappropriate configuration structure is put into the function, an E_PARAM_POINTER will be reported to DET, with corresponding module ID)

2. Because DEM/DET are stubs in RTD package, eventually you wouldn't have to update them, or just would have to modify some minor changes regarding the file versions, if there are new upcoming release. You can even create your own DEM/DET drivers: it's not mandatory to implement directly inside the DEM/DET stub location.

Best Regards,

Nam

 

0 Kudos
1,485 Views
MateoSegura413
Contributor III

Thank you for your help Nam.

0 Kudos