Tg-0090 - 11 Tm4 Mcu Udsoncan Technical Guide

Technical Guide
TM4 MCU UDSonCAN
TG-0090_11 TM4 MCU UDSonCAN

Technical Guide
Product information
Product name: TM4 CO150 MCU
Version number: CO150-A1/CO150-A2
Embedded Bootloader version: 1.4.2.x
Embedded application software version: 2.4.x.x, 2.6.x.x, 3.4.x.x
Document information
Reference: TG-0090 TM4 MCU UDSonCAN Technical Guide
Release date: 2020-02-27
Version number: 11.0
Template information
Reference: IN-8014_4
CONFIDENTIAL Page 2 of 35 TG-0090_11 TM4 MCU UDSonCAN

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Table of contents
1 Introduction ........................................................................................................................ 5
1.1 Diagnostic setup ........................................................................................................ 5
1.2 Scope......................................................................................................................... 5
1.3 What’s new ................................................................................................................ 6
1.4 Definitions, acronyms and abbreviations .................................................................... 6
1.5 References................................................................................................................. 6
2 Communicating using UDSonCAN ..................................................................................... 7
2.1 UDS CAN communication configuration ..................................................................... 7
2.2 UDS sessions and security access ............................................................................ 7
2.2.1 Default diagnostic session ................................................................................... 8
2.2.2 Extended diagnostic session ............................................................................... 9
2.2.3 Programming diagnostic session ......................................................................... 9
2.2.4 Setting sessions and security access ................................................................ 10
2.3 Reading and clearing errors ..................................................................................... 11
2.3.1 DTC failures and associated corrective actions ................................................. 11
2.4 Reading and setting values over UdsOnCan ............................................................ 12
2.4.1 Reading or editing product identification information ......................................... 12
2.4.2 Reading and writing system parameters............................................................ 14
2.4.3 Reading diagnostic variables............................................................................. 16
2.4.4 Saving modified parameter values to NVM........................................................ 18
2.5 Resetting the system ................................................................................................ 19
2.6 Program the embedded application .......................................................................... 19
2.6.1 Reading the program file ................................................................................... 20
2.6.1.1 Reading the hardware number....................................................................... 21
2.6.1.2 Reading the code file ..................................................................................... 22
2.6.2 Establishing the programming session .............................................................. 23
2.6.3 Flashing the program file ................................................................................... 25
2.6.3.1 Erase segment .............................................................................................. 26
2.6.3.2 Programming segment................................................................................... 27
2.6.3.3 Validating segment ........................................................................................ 28
2.6.4 Launching the program ..................................................................................... 29
3 Customer service ............................................................................................................. 30
Appendix A UDS services implemented for MCU ............................................................. 31
Appendix B UDS routine identifiers................................................................................... 32
Appendix C UDS RID and DID in MCU Bootloader........................................................... 33
Appendix D User stories ................................................................................................... 34

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
List of tables
Table 1 Related document references ............................................................................. 6
Table 2 UDS Communication parameters ........................................................................ 7
Table 3 Default session – Security feature accessibility ................................................... 8
Table 4 Extended session – Security feature accessibility ............................................... 9
Table 5 Programming session – Security feature accessibility ......................................... 9
Table 6 Security access – sub-function .......................................................................... 10
Table 7 ECU part and serial numbers ............................................................................ 13
Table 8 Vehicle Identification Number (VIN)................................................................... 14
Table 9 System parameters (part I) ................................................................................ 14
Table 10 System parameters (part II) ............................................................................... 16
Table 11 Baud rate value definitions ................................................................................ 16
Table 12 MCU sensors .................................................................................................... 16
Table 13 Internal data ...................................................................................................... 17
Table 14 Manual control................................................................................................... 18
Table 15 Descriptions of the code file segments .............................................................. 22
Table 16 Implemented UDS services with sub-functions .................................................. 31
Table 17 Implemented UDS services – Brief description from ISO 14229 ........................ 31
Table 18 UDS routine identifiers ...................................................................................... 32
Table 19 UDS identifiers in the Bootloader ...................................................................... 33
List of figures
Figure 1 Typical setup - MCU using UDSonCAN .............................................................. 5
Figure 2 Examples of SecurityAccess request ................................................................ 11
Figure 3 Examples of ReadDTCinformation and ClearDiagnosticInformation .................. 12
Figure 4 Save NVM (RID 222) flowchart ......................................................................... 18
Figure 5 Flash process .................................................................................................... 19
Figure 6 Reading program file ......................................................................................... 20
Figure 7 Example of header in the .hex file with format = 1 ............................................. 21
Figure 8 Example of header in the .hex file with format = 2 ............................................. 21
Figure 9 Example code file .............................................................................................. 22
Figure 10 Establish programming session ......................................................................... 23
Figure 11 Flashing the program file ................................................................................... 25
Figure 12 Erase segment .................................................................................................. 26
Figure 13 Programing segment ......................................................................................... 27
Figure 14 Validating segment ............................................................................................ 28
Figure 15 Launch the program .......................................................................................... 29

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
1 Introduction
This guide describes how to communicate with TM4 Motor Control Unit (MCU) using Unified Diagnostic
Services over Controller Area Network protocol (UDSonCAN) in order to consult, edit or update embedded
vehicle system information.
Designed as an appendix to the MCU Operations and Maintenance Guide [1], this additional information is
specifically related to UDSonCAN and is aimed at developers of a UDS tester that would be used for End-
Of-Line testing or in-field diagnostics. This information includes how to use the UDSonCAN functions of the
MCU product; the main functions of the UDSonCAN interface and the message structure and sequences
that an external UDS-enabled device should transmit in order to use the MCU UDSonCAN interface.
The MCU UDSonCAN implementation is based on ISO-15765, ISO-14229-1 and SAE J2012; these
standards should be consulted for more detailed information on how to communicate with embedded
systems using UDSonCAN.
1.1 Diagnostic setup

The typical MCU diagnostic session involves a UDS tester device communicating with an MCU supporting
UDSonCAN.
Figure 1 Typical setup - MCU using UDSonCAN
1.2 Scope
This technical guide is divided as follows:
• Introduction – general information about UDSonCAN, definitions and document reference information.
• Communicating using UDSonCAN – how to interact with the UDSonCAN functionality.
• Customer service – TM4 customer service contact details.
• Appendices – give a resume of the services and specific sub-functions implemented by TM4, details of
the UDS routine identifiers and user stories.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
1.3 What’s new

This version of TG-0090 has been updated to describe a new .hex file header format containing a list of
hardware numbers, see Section 2.6.1.1.
1.4 Definitions, acronyms and abbreviations

AES Advanced Encryption Standard
CAN Controller Area Network communication protocol
CRBI Call Routine By Identifier
CRC Cyclic Redundancy Check
DID Data Identifier
DSP Digital Signal Processor
DTC Diagnostic Trouble Codes
ECU Electronic Control Unit (the MCU)
GD Graceful Degradation
MCU Motor Control Unit (it implements the UDS server)
NVM Non-volatile memory
RID Routine Identifier
UDS Unified Diagnostic System (ISO-14229)
UDSonCAN UDS over CAN bus (ISO-15765)
UDS tester device UDS-ready PC
VIN Vehicle Identification Number
1.5 References
Table 1 Related document references
Reference Title
[1] TG-0068 TM4 CO150-A2-M1 Operations and Maintenance Guide
[2] SC-6004E-0XX DTC Action Guide
[3] See note TM4 Error Codes and Corrective Actions
[4] IN-8013e MCU CAN Protocol v4.1 Specifications
MCU CAN Protocol v4.2 Specifications
Note: This html document is generated for each software version and made available with the software package at the
time of delivery.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2 Communicating using UDSonCAN

This section details the different UDS services available within the TM4 Motor Control Unit (MCU) product
as well as the message structure and sequences involved. For a full list of services and sub-functions
implemented for the MCU, see Appendix A.
Access to these services allows the user to:
• Read and clear error codes, refer to Section 2.3.
• Control session and security access settings, see Section 2.2.
• Program the embedded application, see Section 2.6.
• Set and read product identification information, see Section 2.4.
• Read and write TM4 parameters and diagnostic variables, see Section 2.4.2.
• Perform a system reset, see Section 2.5.
2.1 UDS CAN communication configuration

To communicate with the MCU using UDSonCAN, the UDS CANBUS parameters must be configured
properly and also according to the CANBUS physical bus connection.
Table 2 UDS Communication parameters
Name Default value Description
UdsRxAddress 0x0712 UDS request (receive client request)
UdsTxAddress 0x071A UDS response (send to client)
UdsCanPort 2 (CAN2) CAN bus number
Can1BaudRate 500 Baud rate (KBaud)
Can2BaudRate 500 Baud rate (KBaud)
These values are configurable; refer to Section 2.4.2 for the corresponding parameters.
Notes:
1 If more than one MCU is connected on the same CANBUS cable, UdsRxAddress and UdsTxAddress
values will be different on each MCU (and the baud rate will be identical).
2 It would be impossible to communicate via UDS using the wrong port, address or baud rate. For a first
test connection, set the tool according to the default parameter values and then change the parameters
according to your system needs. The new values will take effect after the next MCU boot-up.
2.2 UDS sessions and security access

In order to ensure that different types of personnel perform only the specific tasks they are authorized for, a
corresponding session and security setting must be established prior to those functions becoming available.
A specific pairing of session/security setting usually corresponds to one specific action to perform.
However, several actions and read-only parameters are accessible with no security.
As soon as a session other than Default is selected, a session timer is started (even if security access type
has not been chosen yet). A TesterPresent (3E hex) message will be periodically sent to the MCU in order
to keep the session active. The session will reset to Default if the MCU does not receive a TesterPresent
message for a period of 10 seconds. Any change to a session other than Default will reset the timer (like
the TesterPresent message does).

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Access to available diagnostic functionality and features is determined by two factors:

• Session type (Default, Extended or Programming);
• Security access type (Basic, Factory, VIN write or Advanced).
Note: Basic access level is available to all users; no security is needed.
The tables in the following sub-sections show detailed views of the available features corresponding to the
sessions and security access levels.
2.2.1 Default diagnostic session

This session level is there by default as the MCU is powered on and MCU keeps the default mode unless
another mode is requested by a diagnostic session control request (0x10).
This session allows anyone to read ECU part, serial and VIN numbers and also to read and clear DTC.
TM4 parameters are not accessible at all in this mode. The default session implements the minimum UDS
services available.
It is not possible to change the security access level in default mode.
Table 3 Default session – Security feature accessibility
Feature Type Security access
Basic Factory VIN write Advanced
Diagnostic session control UDS service Y n/a n/a n/a
Change security access rights UDS service n/a n/a n/a n/a
ECU reset UDS service Y n/a n/a n/a
Tester present UDS service Y n/a n/a n/a
Request upload UDS service N n/a n/a n/a
Transfer data UDS service N n/a n/a n/a
Request transfer exit UDS service N n/a n/a n/a
Read/Clear DTC DTC Y n/a n/a n/a
System parameters DID N n/a n/a n/a
ECU part and serial numbers DID R n/a n/a n/a
VIN number DID R n/a n/a n/a
Save to NVM RID N n/a n/a n/a
Enterboot mode (to flash) RID N n/a n/a n/a

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.2.2 Extended diagnostic session

Without entering secured access mode, the extended session does not allow anything other than the
default mode.
This session allows a secured client to write parameters, VIN, ECU part and serial numbers and
permanently save the data under the NVM (some of the DID are volatile system variables and are not
under NVM).
Table 4 Extended session – Security feature accessibility
Diagnostic session control UDS service Y Y Y Y
Change security access rights UDS service Y Y Y Y
ECU reset UDS service Y Y Y Y
Tester present UDS service Y Y Y Y
Request upload UDS service N Y N N
Transfer data UDS service N Y N N
Request transfer exit UDS service N Y N N
Read/Clear DTC DTC Y Y Y Y
System parameters DID N R R R/W
ECU part and serial numbers DID R R/W R R
VIN number DID R R R/W R
Save to NVM RID N Y Y Y
Enterboot mode (to flash) RID N N N N
2.2.3 Programming diagnostic session

Without entering secured access mode, the programming session in fact allows even less than the default
mode offers because the DTC are not accessible. In programming sessions, it is not possible to change
anything except the application code and to write some specific DIDs1.
This session allows a secured client to download the embedded application (re-flash the ECU).
Table 5 Programming session – Security feature accessibility
Diagnostic session control UDS service Y Y Y Y
Change security access rights UDS service Y Y Y Y
ECU reset UDS service Y Y Y n/a
Tester present2 UDS service Y Y Y Y
Request upload UDS service N N N N
Transfer data UDS service N N N Y
Request transfer exit UDS service N N N Y
Read/Clear DTC DTC n/a n/a n/a n/a
System parameters DID N R R R1
ECU part and serial numbers DID R R R R1
VIN number DID R R R R
Save to NVM RID N N N N
Enter boot mode (to flash) RID N N N Y
1 The ECU Hardware numbers 0x1456, DLSITE 0xF10A, PRGSHOP 0xF198 and the PDDID 0xF199 can
only by written in a Programming/Advanced session.
2 Once the download routine has been called, TesterPresent service is no longer available until the ECU
boots up again.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.2.4 Setting sessions and security access

Using the SecurityAccess (27 hex) service, the security concept uses a seed and key relationship. The
client requests the seed and then the MCU generates a seed and sends the value in response. The client
reads the seed, encrypts it using the key and responds by returning the encrypted seed number back to the
MCU, which is 4 bytes length. The server responds that the encrypted seed is valid and unlocks the
requested security level. Whenever the client successfully requests a new secured diagnostic session, the
previous session is no longer active.
The encryption key and encryption algorithms are known by both the customer and the MCU (server). At
boot-up the MCU reads the encryption key value in the NVM parameters. The MCU uses the Advanced
Encryption Standard (AES) as the encryption mechanism.
The encryption key3 is stored in the controller NVM parameters and can be modified by the customer. The
key is 128bits stored on 4 32bits parameters. For example, if we want to set the key to the string
“ABCDEFGHIJKLMNOP” (128bit number) we need to set the parameters as follows (character A is 0x41; B
is 0x42 and so on):
• UdsEncryptionKeyPart1 = 0x44434241 = 1145258561 in decimal
• UdsEncryptionKeyPart2 = 0x48474645 = 1212630597 in decimal
• UdsEncryptionKeyPart3 = 0x4C4B4A49 = 1280002633 in decimal
• UdsEncryptionKeyPart4 = 0x504F4E4D = 1347374669 in decimal
In this example, character A is the least significant byte of the key and character P is the most significant.
Table 6 Security access – sub-function
Access level Exchange type Sub-function
Factory Request seed 1
Factory Send key 2
Advanced Request seed 3
Advanced Send key 4
VIN write Request seed 5
VIN write Send key 6
Basic Not applicable4 0
3 Refer to Section 2.4.2 for information on how to read/write the UdsEncryptionKeyPartX values.
4 For a request to Basic access level, the MCU returns a positive response (no seed).

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Figure 2 Examples of SecurityAccess request
2.3 Reading and clearing errors

The user does not need to be in a secured session to read errors (DTCs and associated subtype)
generated by the system. DTCs can always be read and cleared, except in Programming mode. Errors are
cleared from MCU memory using the ClearDiagnosticInformation (14 hex) service. All subsequent DTCs
are stored until the next time the log is cleared.
Notes:
1 Both the application software and the Bootloader software implement, read and clear DTC. But if there
are DTC errors while in the Bootloader, they will always re-appear even after a
ClearDiagnosticInformation command.
2 The ReadDTCinformation (19 hex) command returns a list of DTCs starting with the most recent.
3 The only supported DTC status is « testFailedSinceLastClear » (bit5).
4 If a DTC error occurs suddenly causing the MCU to be reset without completing a clean shutdown
sequence (using a real key stroke or the resetKeyOffOn command, for example), then the error that
caused the MCU to be reset will not be saved in NVM.
2.3.1 DTC failures and associated corrective actions

For each error raised by the MCU software embedded in the MCU system, a UDS DTC identifier (DTC ID)
is combined with a DTC subtype. Each DTC/subtype combination has a list of proposed actions [3] to help
you correct the issues that have caused the error. Refer to the DTC Action Guide appropriate to the TM4
product version you are using [2].
Note: UDSonCAN supports SAE J2012 MAR2013 DTC Standard using 3 byte format identifier (0x00 list
from J2012-DA). It uses some of the PXXXX (powertrain: b7-b6 is [0, 0]) and the UXXXX (network and
vehicle: b7-b6 is [1, 1]) DTC ranges.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Figure 3 Examples of ReadDTCinformation and ClearDiagnosticInformation
2.4 Reading and setting values over UdsOnCan

The ReadDataByIdentifier (22 hex) service allows you to read values of varying lengths associated with a
unique identifier between 0 and 65535.
Once a secured session has been established, the WriteDataByIdentifier (2E hex) service allows you to
modify a value for data identified by its unique ID.
There are different categories of information that can be read or set: Product identification information
(including VIN) and system parameters are stored in NVM with the same UDS routine. The single action of
writing in data is not enough to permanently save it. See Section 2.4.4 for information on how to save in
NVM.
Note: When you modify the parameters of the MCU, the embedded application verifies that the value
provided by the UDS service is within the acceptable range. In the event that the value is out of range, the
current/original value will be maintained but a positive response is still returned. It is the client’s
responsibility to verify that the data has really been changed.
2.4.1 Reading or editing product identification information

MCU publishes a variety of identification information (refer to as ECU part and serial numbers and VIN).
This information requires an extended session type and a factory access level to be modified, except for
several parameters related to programming5. However, they could be read within any type of session
including none-secured.
The data contents of String are left justified. For instance, if the MCU_VINDID (0XF190) is (only) « ABCD »,
the CANBUS data will be F1 90 41 42 43 44 00 00, etc..
Table 7 lists the available ECU part and serial number information with UDS ID, read/write access rights
and descriptions.
5DLSITE 0xF10A, PRGSHOP 0xF198 and the PDDID 0xF199 are read-write access in
Programming/Advanced or Extended/Factory sessions.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Table 7 ECU part and serial numbers

Type: F32 (except for strings)
Access: R/W
Security type: Factory (R), Advanced (W)
Session type: Extended
Name UDS ID Type Write Session/ Description Owner

Security
MOTSNDID6 0xF1F0 String(10) N/A Motor serial number TM4
SSMOTHWNDID6 0xF1F1 String(20) N/A Motor part number TM4
VMMOTHNDID6 0xF1F2 String(20) N/A Motor model number TM4
CUSTMOTSNDID 0xF100 String(32) Extended/Factory Customer motor serial Customer
number
CUSTSSMOTHWNDID 0xF101 String(32) Extended/Factory Customer motor part Customer
number
CUSTVMMOTHNDID 0xF102 String(32) Extended/Factory Customer motor model Customer
number
VARIANT_DATASET 0xF105 String(10) Extended/Factory Customer defined Customer
DLSITE 0xF10A String(32) Programming/ Downloading site Depends on
Advanced or who flashes
Extended/Factory application*
BSDID 0xF180 String(22) N/A Boot software number TM4
VMECUSVNDID 0xF189 String(32) Extended/Factory MCU vehicle Customer
manufacturer software
number
ECUSNDID 0xF18C String(10) N/A MCU serial number TM4
VMKAPNDID 0xF18E String(32) Extended/Factory MCU customer part Customer
number
VMECUHNDID 0xF191 String(32) Extended/Factory MCU vehicle Customer
manufacturer hardware
part number
SSECUHWNDID 0xF192 String(20) N/A MCU part number TM4
SSECUHWVNDID 0xF193 String(20) N/A MCU model number TM4
SSECUSWVNDID 0xF195 String(20) N/A MCU software version TM4
SNAMEENGDID 0xF197 String(64) N/A TM4 system name TM4

E.g.:
MCU_INVHP2HV_0206_
TM4_MP340_240_F
PRGSHOP 0xF198 String(6) Programming/ Programming shop code Customer
Advanced or
Extended/Factory
PDDID 0xF199 BCD(4) Programming/ Last reprogramming date Depends on
Advanced or YYYY MM DD who flashes
Extended/Factory application*
6 Not supported in non-TM4 motors.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
The VIN requires a VIN write security access level in order to set the string values.
Table 8 Vehicle Identification Number (VIN)
Name UDS ID Type Write Description Owner
Session/
Security
MCU_VINDID 0xF190 String(18) Extended/ VIN Customer
VIN write
2.4.2 Reading and writing system parameters

MCU publishes a variety of system parameters that allow the user to configure the system. This information
requires an extended session type and an advanced access level to be modified. They cannot be read
without a secured access. All parameters could be written with the corresponding secured access. Refer to
the Section 2.2 for more information on access.
All of the parameters are accessed using IEEE float format.
Table 9 System parameters (part I)
Type: F32
Access: R/W
Name UDS ID Description

ReverseRotationDirection 0x140E Refer to TM4 technical documentation [1]
PositiveTorqueMax 0x140F Refer to TM4 technical documentation [1]
NegativeTorqueMax 0x1410 Refer to TM4 technical documentation [1]
TorqueRamp 0x1411 Refer to TM4 technical documentation [1]
SpdFwdMax 0x1412 Refer to TM4 technical documentation [1]
SpdFwdTracStartDerating 0x1413 Refer to TM4 technical documentation [1]
SpdFwdTracEndDerating 0x1414 Refer to TM4 technical documentation [1]
SpdFwdRegenStartDerating 0x1415 Refer to TM4 technical documentation [1]
SpdFwdRegenEndDerating 0x1416 Refer to TM4 technical documentation [1]
SpdBwdMax 0x1417 Refer to TM4 technical documentation [1]
SpdBwdTracStartDerating 0x1418 Refer to TM4 technical documentation [1]
SpdBwdTracEndDerating 0x1419 Refer to TM4 technical documentation [1]
SpdBwdRegenStartDerating 0x141A Refer to TM4 technical documentation [1]
SpdBwdRegenEndDerating 0x141B Refer to TM4 technical documentation [1]
PhaseSequence 0x141C Refer to TM4 technical documentation [1]
Can1BaudRate 0x141D Refer to Table 11 Baud rate value definitions.
Refer to TM4 technical documentation [1]
HighPrioBaseAddress 0x141E Refer to TM4 technical documentation [1]
LowPrioBaseAddress 0x141F Refer to TM4 technical documentation [1]
OdinCan1BaseAddress 0x1420 Refer to TM4 technical documentation [1]
CtrlCanPortNumber 0x1421 Refer to TM4 technical documentation [1]
TM4 Motor phase7 0x1422 Refer to TM4 technical documentation [1]
SpeedControlKp 0x1423 The value will be multiplied by a factor of 2EXP10 (1024).
SpeedControlKi 0x1424 The value will be multiplied by a factor of 2EXP15 (32768).
Can2BaudRate 0x1425 Refer to Table 11 Baud rate value definitions.
OdinCan2BaseAddress 0x1426 Refer to TM4 technical documentation [1]
PhaseCableReversed7 0x1427 Refer to TM4 technical documentation [1]
7 Not applicable if Remy motor.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide

UdsCanPort 0x1428 UdsOnCAN communication port. 1 or 2 (default)
UdsRxAddress 0x1429 UdsOnCAN rx address value (default 0x712)
UdsTxAddress 0x142A UdsOnCAN tx address value (default 0x71A)
SpeedRamp 0x142F Refer to TM4 technical documentation [1]
TempCoilHigh1 0x1430 Refer to TM4 technical documentation [1]
TempCoilHigh2 0x1431 Refer to TM4 technical documentation [1]
TempCoilMax 0x1432 Refer to TM4 technical documentation [1]
NbMotorTempSensor 0x1433 Refer to TM4 technical documentation [1]
RemyMotorPhase.Offset 0x1434 Refer to TM4 technical documentation [1]
ExtensionBaseAddress 0x1435 Refer to TM4 technical documentation [1]
ActiveDetectTempPhaseConnect 0x1436 Refer to TM4 technical documentation [1]
J1939Use 0x1437 Enable J1939 communication. 0 is disabled (default).
J1939EcuInstance 0x1438 J1939 instance value.
J1939IdentityNumber 0x1439 J1939 identity value.
MCU J1939SourceAddress 0x143A Inverter J1939 source address value.
VMU J1939SourceAddress 0x14D4 The controlling device J1939 source address value.
Damping enable 0x14C0 Enable damping. 0 is disabled. Default is disabled.
Damping minimum speed 0x14C1 Damping minimum speed in RPM. Default is 12.
Damping maximum torque 0x14C2 Damping maximum torque in Nm. Default is 25.
Damping speed 1 0x14C3 Damping speed 1 in RPM. Default is 475.
Damping speed 2 0x14C4 Damping speed 2 in RPM. Default is 1900.
Damping factor 1 0x14C5 Damping factor 1. Default is 20.
Damping factor 2 0x14C6 Damping factor 2. Default is 5.
PosSensorReverseFromRotor 0x14C7 Used to reverse the position sensor ramps relative to
positive rotor rotation.
CreepTorque Communication GD 0x14C8 Creep torque that is applied in such a way to maintain a
speed of 1/10 of the configured maximum speed during
communication faults.
TorqueRampDownTime Communication GD 0x14C9 Time required in ms to reach the creep torque from the
maximum positive torque of the system.
TorqueRampUpTime Communication GD 0x14CA Time required in ms to reach the maximum positive torque
of the system starting from the creep torque.
TotalToleranceTime Communication GD 0x14CB Time allowed before reaching the limp home mode starting
from the moment the fault occurs.
LimpHomeMaxTorque Communication GD 0x14CC Maximum torque allowed after reaching the limp home
timeout when a communication fault occurs.
SpeedRampUpTime Communication GD 0x14CD Used in speed mode, maximum time allowed to reach the
maximum speed of the system starting from 0 RPM after a
communication fault.
Operational Communication GD 0x14CE Set to 1 to activate the communication GD or 0 otherwise.
TorqueRampDownTime Position sensor GD 0x14CF Time required to reach 0 Nm from the maximum positive
torque.
TorqueRampUpTime Position sensor GD 0x14D0 Time required to reach the maximum positive torque of the
system starting from 0 Nm.
TotalToleranceTime Position sensor GD 0x14D1 Time allowed while a position fault persists before raising a
system error.
TorqueRampUpTimeSpeedMode Position sensor GD 0x14D2 Time required to reach the maximum positive torque of the
system starting from 0 Nm when in speed mode.
Operational Position sensor GD 0x14D3 Set to 1 to activate the position sensor GD or 0 otherwise.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Table 10 System parameters (part II)

Type: unsigned int 32bits
Access: R/W

UdsEncryptionKeyPart1 0x142B UdsOnCAN encryption value part 1 (32 bits integer)
UdsEncryptionKeyPart2 0x142C UdsOnCAN encryption value part 2 (32 bits integer)
UdsEncryptionKeyPart3 0x142D UdsOnCAN encryption value part 3 (32 bits integer)
UdsEncryptionKeyPart4 0x142E UdsOnCAN encryption value part 4 (32 bits integer)
Note: maximum value of UdsEncryptionKeyPartX is 0x7FFFFFFF.

Table 11 Baud rate value definitions
Baud rate (KBaud) Value
125 16
250 17
500 18
1000 19
2.4.3 Reading diagnostic variables

Use the ReadDataByIdentifier (22 hex) service with the IDs described in the following tables to read
diagnostic variables on the controller. The read values are in float format.
Table 12 MCU sensors
Type: F32
Access: R
Security type: Other than Basic
Session type: Extended and Programming
Name UDS ID Range Description

VAux 0x140B 0.0+V Auxiliary battery voltage (12V).
VBat 0x140C 0.0+V High-voltage battery voltage.
IBat 0x144F High-voltage battery current (A)
ChassisFault 0x1450 0 → OK Digital input of the chassisFault hardware status.
1 → Problem
McuIgnition 0x1451 0 → Ignition Digital input enable signal (active low).
1 → no ignition
EmergencyStop 0x1452 [0, 1] Digital output of the EmergencyStop hardware signal.
The meaning of the digital output value depends on the
version of the board used in the VMU.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Table 13 Internal data

Type: F32
Access: R
Security type: Other than Basic
Session type: Extended and Programming
Name UDS ID Unit Description

MCU motor rotation number (lower 0X1403 Rotation Total number of motor rotations seen by the MCU since its
32 bits) production. Will be converted to the 32 lower signification bits of a
64bits value.
MCU maximum speed 0X1404 Rad/s Maximum motor speed seen by the MCU since its production.
MCU Total ON time 0X1405 Second Total time in seconds the MCU has been ON since its production.
Motor maximum torque 8 0x1406 Nm Maximum motor torque for that motor.
Motor maximum speed 8 0x1407 RPM Maximum motor speed for that motor.
Motor maximum torque ramp 8 0x1408 Nm/s Maximum torque ramp for that motor.
Motor maximum speed ramp 8 0x14D5 Rpm/s Maximum speed ramp for that motor.
MCU CAN version major 9 0X1409 - Major part of MCU CAN control protocol version.
MCU CAN version minor 9 0X140A - Minor part of MCU CAN control protocol version.
MCU motor rotation number 0X140D Rotation Total number of motor rotations seen by the MCU since its
(upper 32 bits) production. Will be converted to the 32 upper signification bits of a
64bits value.
Operational mode 0x143E - Same values as 0x144E OperationalModeCC, refer to Table 14
Manual control.
Sequencerstatus 0x143F - SAFE_MODE = 0,
INITIALIZATION = 1,
INITIALIZATION_RESET = 2,
INIT_PEAK_DETECT = 3,INIT_TRACTION_CONTROL = 4,
INIT_TRACTION_CONTROL_WAIT = 5,
TRACTION_CONTROL = 6,
CALIBRATION = 7,
SHUTDOWN = 8,
SHUTDOWN_SAVE_SAV_INFO = 9,
SHUTDOWN_SAVE_SAV_INFO_WAIT = 10,
SHUTDOWN_SAVE_SYSFILE = 11,
SHUTDOWN_SAVE_SYSFILE_WAIT = 12,
COOLING = 13,
WAIT_FOR_COOLING = 14,
READY_TO_POWER_OFF = 15,
RESET = 16, FAILURE = 17
wMecMes 0x1440 Rad/s Motor speed
Bootloader major 0x1441 - Major part of the Bootloader software version.
Bootloader minor 0x1442 - Minor part of the Bootloader software version.
Bootloader delivery 0x1443 - Delivery number of the Bootloader software version.
Bootloader changelist 0x1444 - Build number of the Bootloader software version.
Application identification 0x1445 Application project identification (projectId).
Application delivery 0x1446 - Delivery number of the application software version.
Application changelist 0x1447 - Build number of the application software version.
Application major 0x1454 - Major part of the application software version.
Application minor 0x1455 - Minor part of the application software version.
ECU hardware number 0x1456 - Control board hardware version. Used to determine if an
application software can run on this controller or not.
ECU active software type 0x1457 - The program currently running: 0 = Bootloader, 1 = application.
8 Only applicable to TM4 motors.

9 If the protocol version has not yet been selected by the vehicle, the returned values will be 0xff.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Table 14 Manual control

Type: F32
Access: R/W
Name UDS ID Range Description

SpeedCommand 0x143B Rpm Refer to VmuCommand2 [4].
TorqueCommand 0x143C Nm Refer to VmuCommand2 [4].
EnableManualControl 0x143D 0 → Disable It activates the manual control.
1 → Enable
MaxDischargeCurrent 0x1448 A Refer to VmuCommand1 [4].
MaxChargeCurrent 0x1449 A Refer to VmuCommand1 [4].
OperationalRequest 0x144A - Refer to VmuCommand1 [4].
MaxBatteryVoltage 0x144B Volt Refer to VmuCommand1 [4].
MinBatteryVoltage 0x144C Volt Refer to VmuCommand1 [4].
CommandMode 0x144D - Refer to VmuCommand2 [4].
OperationalModeCC 0x144E - Refer to VmuCommand2 [4].
CalibrationRequest 0x1453 0 → no request It starts the calibration process.
1 → Request
2.4.4 Saving modified parameter values to NVM

After modifying one or many parameters, call the Save NVM routine (RID 222) to save the changes to
NVM10. For a complete list of UDS routine identifiers, see Appendix B.
Figure 4 Save NVM (RID 222) flowchart
10The majority of the parameters and variables will take effect on the application only after an ECU re-boot
(any type of re-boot).

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.5 Resetting the system

Use the ECUReset (11 hex) service to perform one of the following three types of system reset.
• 01: hardReset – this simulates the power supply being cut.
• 02: keyOffOnReset – this simulates turning the vehicle on and off with a key.
• 03: softReset – this forces an immediate restart of the program.
Notes:
1 ECUReset returns an error if the torque is greater than 10 Nm or the speed is greater than 100 RPM.
2 The keyOffOnReset process:
a Saves various data to NVM (DTC, SAV counters, etc.) and then returns the 0x78 code until the
system is able to shut down.
b Bypasses the manual mode.
c Cannot be interrupted, even if another command requiring a response is received; this will only
cancel the transmission of the 0x78 code, but the KeyOffOnReset process will continue until
complete.
2.6 Program the embedded application

The high-level steps required to flash software and reprogram the embedded application are shown in
Figure 5.
Figure 5 Flash process
Start
Read program file
Establish
Programming session
Flash program file
Launch program
End flash
The Flash process is made up of several steps and segments described in the flowcharts in the following
sections:
1 Reading the program file, see Section 2.6.1.
2 Establishing the programming session, see Section 2.6.2.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
3 Flashing the program file, see Section 2.6.3.

a Erasing segment, see Section 2.6.3.1
b Programming segment, see Section 2.6.3.2.
c Validating segment, see Section 2.6.3.3.
4 Launching the program, see Section 2.6.4.
2.6.1 Reading the program file

The software package to program is composed of one file. This is a standard .hex file which contains the
actual program code and also the hardware number. The hardware number represents the board type or a
list of board types on which the program code is allowed to run.
Figure 6 Reading program file
Read software number and

validate it is the right one
Read and remember the

HardwareNumber

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.1.1 Reading the hardware number

An ASCII text header is added at the beginning of the .hex file. This header contains the header format and
the hardware number.
• When the header format is 1, it means only one hardware number is supported (see Figure 7).
• When the header format is changed to 2, it means that a list of one or more hardware numbers is
supported; multiple hardware numbers are then separated by commas only with no spaces
(see Figure 8).
Figure 7 Example of header in the .hex file with format = 1
#------------------------------------------
# HeaderFormat = 1
# HardwareNumber = 12
#------------------------------------------
:020000040008F2
:10000000EFBEB8A985FDA3A5C399805BAFB112452A
:1000100020B377A4FBCD4BAF4657AAA25642657CCE
…
Figure 8 Example of header in the .hex file with format = 2
#------------------------------------------
# HeaderFormat = 2
# HardwareNumber = 12,13
#------------------------------------------
:020000040008F2
…
HeaderFormat: This is the version of the header format. This number will be incremented if
the format changes.
HardwareNumber: This number or list of numbers represents the controller PCB numbers on
which this software can operate. Those number will have to be sent to the
Bootloader during the flashing process to unlock the flashing operation.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.1.2 Reading the code file

The rest of the .hex file contains the software within a standard Intel HEX format. The file contains several
code segments composed of an extended address record followed by several data records. Each segment
is 0x10000 bytes long except the last one. Here is an example of a code file:
Figure 9 Example code file
:020000040008F2
:10002000BB39C5ED905354D5EBEFF3C5F14B8BF8CD
:1000300051C5D18C870466D1DD43A0C8D1EA82EADC
:100040004A903975065308CB4C84D6F7918C3A15F3
:10005000A5045AE49D3208DC9EEF24B5A42B3D2074
…
:10FFD00008700C0B8463832CB8D2409D7926FC708A
:10FFE00077889EB488147B5DFAC9824EE940E12D82
:10FFF0007B736D7C1E60861352284379F2BC5738A0
:020000040009F1
:100000004981D8B131C2C3B5C5A6C0F3A8AB025C63
:1000100020A167A4FFF21DFE42681BB451D774CD26
:100020005A9419B4707A53B60E7F0A2510E6540913
…
:10CEA0003EED71AA70AC05ACE52D0C7C9333925F1E
:10CEB000300B5F180CB49B61C5FBDF5E9A56A283F2
:08CEC0003FB4F8216EC51F7993
:00000001FF
Table 15 Descriptions of the code file segments

__ Start code: Indicates the beginning of a record line.
__ Byte count: Number of data byte in the record.
__ Load offset: Not used, will always be 0000.
__ Address: Low part of the 32bits address for the first data byte in this record. For example,
the address for byte EF (in red) is 0x00080000; the address of byte 51 (in red) is
0x0009001C.
__ Record type: 00 = Data record
01 = End of file record
04 = Extended linear address record
__ Data: In a data record, the data part represents the code to be programmed.
In an extended linear address record, the data part represents the high part of the
32bits address for the following data records.
__ Checksum: Sum of all the bytes in the line except “:” and the checksum.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.2 Establishing the programming session

To put the system in programming mode, a specific sequence of commands needs to be sent. The
following diagram shows this sequence with CAN trace examples for a software supporting hardware
number 12,13 flashed on PCB 13.
Figure 10 Establish programming session
712 02 10 02 00 00 00 00 00 Programming
Select programming session 71A 04 50 02 00 00 00 00 00 Ok
712 02 27 03 00 00 00 00 00 Request advanced access

Set security access to Advanced 71A 06 67 03 xx xx xx xx 00 Send seed
712 06 27 04 yy yy yy yy 00 Return encrypted seed
71A 02 67 04 00 00 00 00 00 Accepted
Start routine 712 04 31 01 02 2E 00 00 00 Start routine EnterBootMode

71A 04 71 01 02 2E 00 00 00 Routine started
EnterBootMode (0x022E)
Routine status 712 04 31 03 02 2E 00 00 00 Routine status?

71A 05 71 03 02 2E 02 00 00 Routine 01 = in process
EnterBootMode 02 = Ok
04 = Not Ok
In process Result No
Error
Ok?
Yes
Wait 500 ms
712 02 10 03 00 00 00 00 00 Programming
Select Programming session 71A 04 50 03 00 00 00 00 00 Ok
712 02 27 03 00 00 00 00 00 Request advanced access

Set security access to Advanced 71A 06 67 03 xx xx xx xx 00 Send seed
712 06 27 04 yy yy yy yy 00 Return encrypted seed
71A 02 67 04 00 00 00 00 00 Accepted
ReadDataByIdentifier 712 03 22 14 57 00 00 00 00 Read ActiveSoftwareType

71A 07 62 14 57 00 00 00 00 Float value 00000000 = 0, Bootloader
ActiveSoftwareType (0x1457) Float value 0000803F = 1, Application
Result No
Error
Bootloader?
Yes
WriteDataByIdentifier 712 07 2E 14 56 00 00 40 41 Write HardwareNumber 12

Float value 00004041 = 12
HardwareNumber (0x1456) 71A 03 7F 2E 31 00 00 00 00 Condition not correct, means
this HardwareNumber is not valid,
flashing not allowed
712 07 2E 14 56 00 00 50 41 Write HardwareNumber 13
Float value 00005041 = 13
Result No 71A 03 6E 14 56 00 00 00 00 Positive response,
Error HardwareNumber accepted, flashing
Ok? allowed
Yes

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Four steps are required to put the controller in programming mode:

1. Run the EnterBootMode (0x022E) routine that will cause the controller to exit the main application
program and execute the Bootloader program already included in the controller.
Important note: To execute this command, the programming session and advanced access level
needs to be selected. You then have 100ms to request the run routine result and get confirmation
(OK) that the command was accepted (motor speed and torque are low enough). Only after the
routine completes with success in the allotted timeframe will the application begin running the
Bootloader program.
2. Wait around 500 ms to let the Bootloader program initialize. At this point, access permissions have
been cleared. Select the extended session and the advanced access level.
3. Using ReadDataByIdentifier, read the ActiveSoftwareType (0x1457) to see if the controller is really
running the Bootloader program. When reading this identifier, the controller will answer 0 for
Bootloader and 1 for main application. At this point if the answer is not 0, there is a problem, restart
the procedure from the beginning.
4. To unlock the Erase, Program and Verify features, the Bootloader needs to know the
HardwareNumber of the program to write. Using WriteDataByIdentifier, try all the HardwareNumber
found in the list at the beginning of the .hex file until a positive answer is received. If one of the
numbers receives a positive answer, it means the package is OK to run on this controller and the
flashing features are unlocked. No need to write the other numbers, you can proceed to the next
steps. If the answer is “Condition Not Correct” for all the items in the list, it means this software
package is not valid for this controller and the erasing, programming and verifying features are not
allowed.
Notes:
1 Refer to Appendix C for more information on the RID and DID accessible in the Bootloader.
2 In the case there is no application code, the same sequences have to be performed in order to put the
controller in programming mode.
3 EnterBootMode (0x022E) returns an error if the:
• torque is greater than 10 Nm or
• speed is greater than 100 RPM or
• NVM is still in the process of being saved.
4 The Clear DTC event is automatically saved in NVM in the Event Logger before moving on to the
Bootloader.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.3 Flashing the program file

The Flash process is done by reading a code segment from the .hex file, erasing the required memory
range, programming the code segment in memory and then verifying if the programing operation worked
correctly. This process is repeated until all the segments have been programmed.
Figure 11 Flashing the program file
Get code segment from .hex file
Erase segment
Program segment
Verify segment
Yes More segments

to write?
No

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.3.1 Erase segment

This process will erase sufficient flash memory in the controller to program the current data segment. The
erase address is written in the “Extended linear address record” (high address part) and the length is the
size in bytes of the data segment to program. If the flashing features were not unlocked by writing the
HardwareNumber, the controller will return “Condition not correct” to the start routine request.
Figure 12 Erase segment
Start
Start routine 712 10 0C 31 01 02 28 00 08 Start routine EraseFalsh

71A 30 08 00 00 00 00 00 00 Flow ctrl wait 0ms between msg
EraseFlash (0x0228) 712 21 00 00 00 01 00 00 00 Address = 0x00080000
Length = 0x00010000
71A 04 71 01 02 28 00 00 00 Routine started
Routine status 712 04 31 03 02 28 00 00 00 Routine status?

71A 05 71 03 02 28 01 00 00 Routine in process (01)
EraseFlash ...
712 04 31 03 02 28 00 00 00 Routine status?
71A 05 71 03 02 28 02 00 00 Routine completed ok (02)
Error
Ok?
Yes
End

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.3.2 Programming segment

This process will program a data segment in the controller flash memory.
The first step is to send a request to download data in a certain range and configure the transfer. If the flash
memory was not erased, the controller will return “Request out of range”. If the flashing features were not
unlocked by writing the HardwareNumber, the controller will return “Condition not correct”. If the conditions
are OK, the controller will answer with a positive response. The positive response includes the number of
bytes to use for the data block length (2 bytes) and the maximum block size (9 bytes for address and
control + 96 data bytes). The number of data bytes sent can be smaller than 96 but must be multiple of 4.
Once the request is acknowledged, the transfer can begin. Data transfer messages are sent until the entire
data segment is transferred. For example, if a data segment is 0x10000 bytes long, 682 data transfers of
0x60 bytes are required plus one transfer of 0x40 bytes to finish the segment.
During the transfer, the sender should calculate the checksum of the data sent (not including the 9 control
bytes of transfer messages). This checksum stands on 16 bits (2 bytes) and is a simple sum of the data.
This information will be used in the next validation operation.
When the segment is transferred completely, a transfer exit request is sent to terminate the transfer.
Figure 13 Programing segment
Start
712 10 0B 34 00 44 00 08 00 Request download (0x34)

Send request download data format = 00 (only supported)
4byte address, 4byte length
command 71A 30 08 00 00 00 00 00 00 Flow ctrl wait 0ms between msg
712 21 00 00 01 00 00 00 00 start address = 0x00080000
Length = 0x00010000
71A 04 74 20 00 69 00 00 00 Accepted, 2byte block length
MaxBlockLength (9+0x60 data bytes)
712 10 68 36 01 00 08 00 00 Data transfer (0x36)

Transfer data 71A 30 08 00 00 00 00 00 00 Flow ctrl wait 0ms between msg
712 21 00 60 EF BE B8 A9 85 Send 0x60 data bytes
712 22 FD A3 A5 C3 99 80 5B
…
712 2E EF 24 B5 A4 2B 3D 20
71A 02 76 01 00 00 00 00 00 Success for block 1
Yes More data in

segment?
No
712 01 37 00 00 00 00 00 00 Request transfer exit (0x37)

Request transfer exit 71A 01 77 00 00 00 00 00 00 Success
End

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.3.3 Validating segment

This process will validate that the checksum of the data segment sent is equal to the checksum of the data
programmed in the controller flash memory. The sender will start the validation routine and send the
segment address, size and checksum. If the flashing features were not unlocked by writing the
HardwareNumber, the controller will return “Condition not correct”. If flashing features are unlocked, the
controller will read the specified range, calculate the checksum and compare to the value received. During
calculation the routine status is in process (1), if the checksum matches, the routine status will become OK
(2) and if the checksum does not match, the status will be not OK (4).
Figure 14 Validating segment
Start
Start routine 712 10 0E 31 01 02 2D 00 08 Start routine Validate

71A 30 08 00 00 00 00 00 00 Flow ctrl wait 0ms between msg
ValidateTransfer (0x022D) 712 21 00 00 00 09 00 00 97 start addr = 0x00080000
712 22 8B 00 00 00 00 00 00 end addr = 0x00090000
Checksum = 0x978B
71A 04 71 01 02 2D 00 00 00 Routine started
Routine status 712 04 31 03 02 2D 00 00 00 Routine status?

71A 05 71 03 02 2D 01 00 00 Routine in process (01)
ValidateTransfer (0x022D) ...
712 04 31 03 02 2D 00 00 00 Routine status?
71A 05 71 03 02 2D 02 00 00 Routine completed ok (02)
Error
Ok?
Yes
End

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
2.6.4 Launching the program

Once the entire program is transferred, the sender must issue a command to instruct the Bootloader to
launch the new application software. This is done by running the LeaveBootMode routine (0x022F). Once
the routine state is OK, wait around 500 ms for the main application to initialise and the controller should
now be running the application software. This can be verified by reading the DID 0x1457.
Figure 15 Launch the program
Start routine 712 04 31 01 02 2F 00 00 00 Start routine LeaveBootMode

71A 04 71 01 02 2F 00 00 00 Routine started
LeaveBootMode (0x022F)
Routine status 712 04 31 03 02 2F 00 00 00 Routine status?

71A 05 71 03 02 2F 02 00 00 Routine 01 = in process
LeaveBootMode 02 = Ok
04 = Not Ok
Error
Ok?
Yes

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
3 Customer service
For further technical assistance, please contact TM4 Customer Service:
Email: tm4customersupport@dana.com

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Appendix A UDS services implemented for MCU

The following table gives a resume of the services and specific sub-functions implemented by TM4 along
with the security session type required to access the service.
Table 16 Implemented UDS services with sub-functions
ISO-14229 Service name and sub-functions supported by TM4
DiagnosticSessionControl (10 hex) service:

01 defaultSession
02 programmingSession
03 extendedDiagnosticSession
ECUReset (11 hex) service:
01 hardReset
02 keyOffOnReset. Note that the result of this command depends on the system condition.
03 softReset
SecurityAccess (27 hex) service
01 requestSeed (Factory security)
02 sendKey (Factory security)
03 requestSeed (Advanced security)
04 sendKey (Advanced security)
05 requestSeed (VIN write security)
06 sendKey (VIN write security)
TesterPresent (3E hex) service. Note that this service is not supported in the bootloader mode condition.
ReadDataByIdentifier (22 hex) service. Note that multiple read identifiers are not supported.
WriteDataByIdentifier (2E hex) service
ClearDiagnosticInformation (14 hex) service. Note that some DTCs raised by the bootloader could not be cleared.
ReadDTCInformation (19 hex) service:
02 reportDTCByStatusMask
RoutineControl (31 hex) service
RequestDownload (34 hex) service
TransferData (36 hex) service
RequestTransferExit (37 hex) service
Table 17 Implemented UDS services – Brief description from ISO 14229

Service Description
DiagnosticSessionControl The client requests to control a diagnostic session with a server.
ECUReset The client forces the server to perform a reset.
SecurityAccess The client requests to unlock a secured server.
TesterPresent The client indicates to the server that it is still present.
ReadDataByIdentifier The client requests to read the current value of a record identified by a provided dataIdentifier.
WriteDataByIdentifier The client requests to write a record specified by a provided dataIdentifier.
ClearDiagnosticInformation Allows the client to clear diagnostic information from the server (including DTCs, captured data,
etc.).
ReadDTCInformation Allows the client to request diagnostic information from the server (including DTCs, captured
data, etc.).
RoutineControl The client requests to start/stop a routine in the server or requests the routine results.
RequestDownload The client requests the negotiation of a data transfer from the client to the server.
TransferData The client transmits data to the server.
RequestTransferExit The client requests the termination of a data transfer.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Appendix B UDS routine identifiers

Table 18 UDS routine identifiers
Name UDS ID Session/ Parameter type Routine response Description
Access type
SaveParam 0x0222 Extended/all Void OK:2h Save non-volatile
except default. NOK:4h parameter in permanent
InProgress:1h memory.
EnterBootMode 0x022E Programming/Ad Void OK:2h Beginning of
vanced NOK:4h reprogramming. Force
InProgress:1h device to stay in
Bootloader.
LeaveBootMode11 0x022F Programming/Ad Void OK:2h End of reprogramming
vanced NOK:4h process. Launch the
InProgress:1h application program.
11 Only in the Bootloader program.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Appendix C UDS RID and DID in MCU Bootloader

In the MCU Bootloader software, the only RID and DID accessible are listed in the following table.
Table 19 UDS identifiers in the Bootloader
Name UDS ID Type Read/Write
EnterBootMode 0x022E Routine NA
LeaveBootMode 0x022F Routine NA
RequestDownload 0x34 Service NA
TransferData 0x36 Service NA
RequestTransferExit 0x37 Service NA
HardwareNumber 0x1456 Data RW
ActiveSoftwareType 0x1457 Data R
BSDID 0xF180 Data R
PDDID 0xF199 Data RW

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
Appendix D User stories

These user stories are aimed at software developers of a UDS tester. They capture some scenarios of what
a user does or needs to do as part of his or her job related to using an UDS diagnostic tool for road vehicles
in the context of interacting with a TM4 motor drive.
• Maintenance and repairs: Garage owners; mechanics;
• Car factory: Workers; technicians; quality workers;
• Motor control unit factory (TM4): Technicians; quality workers;
• Advanced configuration: Field engineers; engineers/integrators.
These user stories are given as examples with the intention that UDS tester software developers will then
create their own scenarios.
A.1 Maintenance and repairs

As a garage owner, I want to know the VIN, ECU part and serial numbers to validate the guarantee and
check for some recall actions.
As a specialized mechanic, I want to read DTC, check the troubleshooting guide and apply the related
action for this vehicle. I want to clear the DTC afterward in order to know if a fault has appeared again the
next check. In order to be sure that I can’t delete parameter values or modify any important configuration, I
don’t want permission that gives me access to anything else.
A.2 Car factory

As a worker at the car factory (or de-contenting station12), I have to check if the drives we have in stock
require an embedded application code update. If so, I re-flash the application onto the drive and give the
unit to the right assembly line station to be integrated into the vehicle.
As a technician on a car factory line, I am responsible for configuring the parameters and integrating all the
electrical powertrain components. For instance, the CANBUS addresses of all the ECU on the network will
be configured to ensure that the communication is functioning correctly. Not all vehicles have the same
ECUs. Basically, I need to access everything except the part and serial numbers that I don’t want to change
at all.
As a quality worker on a car factory line, I am at the very end of the line. I have to read all the part numbers
on the vehicle. I have to program the VIN number on, for example, the drive.
A.3 Motor control unit factory (TM4)

As a technician on a drive factory line, I have to program the model and serial numbers of each drive and
read them back afterwards.
As a quality worker on a drive factory line, I am at the very end of the line. I have to configure the
parameters for that specific drive that will be shipped to a specific customer.
12Specialized factory that removes the conventional power-train of the vehicle to install the electrical
powertrain components.

© Dana TM4 inc., 2014-2020 2020-02-27
Technical Guide
A.4 Advanced configuration

As a field engineer, I want to set some motor parameters that will fix a problem we noticed on some
vehicles. I do not know exactly which software version is on this drive and I have to update the application
software if necessary. In order to be sure that I do not delete the ECU parts and VIN numbers, I do not want
the write permission for this kind of action.
As an engineer and integrator, on my motor test bench I want to apply manual control commands (e.g.
Torque command) on the system running on a controlled environment. I want to be able to access all
possible configuration parameters.

© Dana TM4 inc., 2014-2020 2020-02-27

Tg-0090 - 11 Tm4 Mcu Udsoncan Technical Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tg-0090 - 11 Tm4 Mcu Udsoncan Technical Guide

Uploaded by

Copyright:

Available Formats

Technical Guide

TM4 MCU UDSonCAN

TG-0090_11 TM4 MCU UDSonCAN

CONFIDENTIAL Page 2 of 35 TG-0090_11 TM4 MCU UDSonCAN

CONFIDENTIAL Page 3 of 35 TG-0090_11 TM4 MCU UDSonCAN

CONFIDENTIAL Page 4 of 35 TG-0090_11 TM4 MCU UDSonCAN

1.1 Diagnostic setup

CONFIDENTIAL Page 5 of 35 TG-0090_11 TM4 MCU UDSonCAN

1.3 What’s new

1.4 Definitions, acronyms and abbreviations

CONFIDENTIAL Page 6 of 35 TG-0090_11 TM4 MCU UDSonCAN

2 Communicating using UDSonCAN

2.1 UDS CAN communication configuration

2.2 UDS sessions and security access

CONFIDENTIAL Page 7 of 35 TG-0090_11 TM4 MCU UDSonCAN

Access to available diagnostic functionality and features is determined by two factors:

2.2.1 Default diagnostic session

CONFIDENTIAL Page 8 of 35 TG-0090_11 TM4 MCU UDSonCAN

2.2.2 Extended diagnostic session

2.2.3 Programming diagnostic session

CONFIDENTIAL Page 9 of 35 TG-0090_11 TM4 MCU UDSonCAN

2.2.4 Setting sessions and security access

CONFIDENTIAL Page 10 of 35 TG-0090_11 TM4 MCU UDSonCAN

Figure 2 Examples of SecurityAccess request

2.3 Reading and clearing errors

2.3.1 DTC failures and associated corrective actions

CONFIDENTIAL Page 11 of 35 TG-0090_11 TM4 MCU UDSonCAN

Figure 3 Examples of ReadDTCinformation and ClearDiagnosticInformation

2.4 Reading and setting values over UdsOnCan

2.4.1 Reading or editing product identification information

CONFIDENTIAL Page 12 of 35 TG-0090_11 TM4 MCU UDSonCAN

Table 7 ECU part and serial numbers

Name UDS ID Type Write Session/ Description Owner

SNAMEENGDID 0xF197 String(64) N/A TM4 system name TM4

6 Not supported in non-TM4 motors.

CONFIDENTIAL Page 13 of 35 TG-0090_11 TM4 MCU UDSonCAN

2.4.2 Reading and writing system parameters

Name UDS ID Description

7 Not applicable if Remy motor.

CONFIDENTIAL Page 14 of 35 TG-0090_11 TM4 MCU UDSonCAN

Name UDS ID Description

CONFIDENTIAL Page 15 of 35 TG-0090_11 TM4 MCU UDSonCAN

Table 10 System parameters (part II)

Name UDS ID Description

Note: maximum value of UdsEncryptionKeyPartX is 0x7FFFFFFF.

2.4.3 Reading diagnostic variables

Name UDS ID Range Description

CONFIDENTIAL Page 16 of 35 TG-0090_11 TM4 MCU UDSonCAN

Table 13 Internal data

Name UDS ID Unit Description

8 Only applicable to TM4 motors.

CONFIDENTIAL Page 17 of 35 TG-0090_11 TM4 MCU UDSonCAN

Table 14 Manual control

Name UDS ID Range Description

2.4.4 Saving modified parameter values to NVM

CONFIDENTIAL Page 18 of 35 TG-0090_11 TM4 MCU UDSonCAN

2.5 Resetting the system

2.6 Program the embedded application

Read program file

Flash program file

CONFIDENTIAL Page 19 of 35 TG-0090_11 TM4 MCU UDSonCAN

3 Flashing the program file, see Section 2.6.3.

2.6.1 Reading the program file