-
Hello, I've been gradually delving deeper into this project. I referred to a previous discussion at this link and am trying to integrate the features I have in mind based on that discussion. After applying the TestApp from the link, I modified the Execution Management to run the TestApp instead of the Extended Vehicle. Upon running the TestApp, I encountered an error that hadn't appeared before. The error is as follows: Upon investigation, I found that this error occurs when the DebouncingStatus detected by the Diagnostic_manager for an event (named mEvent in the code) changes to the value kFinallyDefective.
However, I have been unable to identify what influences the GetDebouncingStatus of this event. The only change I made to the code was replacing the ExtendedVehicle with the TestApp from the link, but I don't understand how this could affect mEvent. I would appreciate any insights you might have. I am attaching the relevant code separately. Thank you as always.
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
The DM has a SD client to discover your TestApp. There is a standard At the first stage of debugging, you can put a breakpoint on |
Beta Was this translation helpful? Give feedback.
The DM has a SD client to discover your TestApp. There is a standard
Monitor
mechanism on DM that checks if the SD was successful or not. If within 6 seconds (by default) the TestApp is discovered via SOME/IP SD, the SD is reported as successful. Otherwise, theMonitor
sets theEvent
tokFinallyHealed
which leads to the reported DTC.At the first stage of debugging, you can put a breakpoint on
void DiagnosticManager::checkServiceDiscovery()
function to see if the FSM state changes toSdClientState::ServiceReady
/SdClientState::ServiceSeen
or not. If yes, then you can increase theTIME-FAILED-THRESHOLD
value on DM ARXML to something higher than6000
. If not, then you need to check whether the