Home Learning Paths ECU Lab Assessments Interview Preparation Arena Pricing Log In Sign Up

DiagnosticSessionControl (SID 0x10)

Cdsc_handler.c
/* UDS 0x10: DiagnosticSessionControl — switches ECU diagnostic session */
/* Called via DCM callback in AUTOSAR bootloader */

#include "Dcm.h"
#include "Dcm_Cbk.h"

/* Session IDs */
#define SESSION_DEFAULT      0x01u
#define SESSION_PROGRAMMING  0x02u
#define SESSION_EXTENDED     0x03u

/* DSC response: 0x50 + subFunction + P2 (2 bytes) + P2* (2 bytes, in 10ms units) */
typedef struct {
    uint8_t  sid_resp;      /* 0x50 */
    uint8_t  session_type;  /* echo of requested sub-function */
    uint16_t p2_ms;         /* 50 ms default */
    uint16_t p2star_10ms;   /* 5000 ms default → 500 in units of 10 ms */
} DscResponse_t;

Std_ReturnType Dcm_DSC_Handler(const uint8_t *req, uint16_t req_len,
                                 uint8_t *resp, uint16_t *resp_len)
{
    uint8_t session = req[1];  /* sub-function byte */

    switch (session) {
        case SESSION_DEFAULT:
            /* Always accessible from any session */
            Dcm_SetActiveSession(SESSION_DEFAULT);
            /* Clear security level: level 0 (no access) */
            Dcm_SetSecurityLevel(0u);
            break;

        case SESSION_EXTENDED:
            /* Extended: accessible from default or programming */
            Dcm_SetActiveSession(SESSION_EXTENDED);
            break;

        case SESSION_PROGRAMMING:
            /* Programming: only from Extended Session */
            if (Dcm_GetActiveSession() != SESSION_EXTENDED) {
                resp[0] = 0x7Fu; resp[1] = 0x10u; resp[2] = 0x25u;  /* NRC 0x25: wrong session */
                *resp_len = 3u;
                return E_NOT_OK;
            }
            /* Set boot flag: next reset will stay in PBL reprog mode */
            BootFlags_Set(REPROG_MAGIC);
            Dcm_SetActiveSession(SESSION_PROGRAMMING);
            break;

        default:
            resp[0] = 0x7Fu; resp[1] = 0x10u; resp[2] = 0x12u;  /* NRC 0x12: subFunctionNotSupported */
            *resp_len = 3u;
            return E_NOT_OK;
    }

    /* Positive response */
    resp[0] = 0x50u; resp[1] = session;
    resp[2] = 0x00u; resp[3] = 0x32u;  /* P2 = 50 ms */
    resp[4] = 0x01u; resp[5] = 0xF4u;  /* P2* = 500 × 10ms = 5000 ms */
    *resp_len = 6u;
    return E_OK;
}

ECUReset (SID 0x11) in Bootloader Context

Reset TypeSub-FunctionBehaviourBootloader Use
Hard Reset0x01Full power-cycle equivalent (POR)Force PBL to re-evaluate boot decision
Key Off-On Reset0x02Simulates ignition cycleReset all volatile state; used for NvM flush
Soft Reset0x03Software reset (NVIC SystemReset on ARM)Quick restart; boot flags preserved
Enable Rapid Shutdown0x04Signal to enter rapid power-offProduction programming; not typical in bootloader

Service Availability by Session

UDS ServiceDefaultExtendedProgramming
0x10 DSCAll sub-functionsAll sub-functionsOnly 0x01 (→ Default)
0x11 ECUReset0x01, 0x03AllAll
0x27 SecurityAccessNot availableLevel 1 onlyLevel 1 + Level 2
0x28 CommunicationControlNot availableAvailableAvailable
0x31 RoutineControlNot availableSome routines0xFF00 erase, 0xFF01 check
0x34 RequestDownloadNot availableNot availableAvailable (with Security Level 2)
0x36 TransferDataNot availableNot availableAvailable (after 0x34)
0x37 RequestTransferExitNot availableNot availableAvailable (after 0x36)
0x3E TesterPresentAvailableAvailableAvailable (mandatory for keepalive)
0x22 ReadDIDAvailableAvailableLimited (essential DIDs only)

Summary

Session management is the gateway to reprogramming: the programming session (0x10 0x02) is only accessible from the Extended Session, which in turn requires the Level 1 security key. This two-step session escalation ensures that a simple power-on-diagnostic-request cannot accidentally trigger a reprogramming sequence. The ECUReset (0x11 0x03) at the end of the reprogramming sequence causes the ECU to restart, which triggers PBL, which reads the boot flags (cleared by the SBL after successful programming), validates the new application CRC, and jumps to it — completing the update cycle.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

  • Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
  • Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
  • Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

  • Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
  • Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
  • Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

  1. Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
  2. Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
  3. Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
  4. Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.

← PreviousHands-On: Basic Bootloader SkeletonNext →SecurityAccess: Seed-Key Exchange