1、 Bootloader with reprogramming functionality for electronic control units in vehicles: Analysis, design and Implementation David Pehrsson Jess Garza EXAM WORK 2012 ELECTRICAL ENGINEERING This thesis work is performed at Jnkping University, School of Engineering, within the subject area Electrical En
2、gineering. The work is part of the two year masters degree programme with the specialization in Embedded Systems. The author is responsible for the given opinions, conclusions and results. Examiner: Shashi Kumar Supervisor: Alf Johansson Scope: 30 credits (second cycle) Date: 2012-12-18 i Acknowledg
3、ements We would like to thank everyone at QRTECH for the help they have given us and we would especially like to thank Andreas Kck for the technical support he provided when we needed it. We will also like to thank Lars Carlsson on QRTECH for all the help regarding the master thesis. We would also l
4、ike to thank the teachers at JTH, Alf Johansson and Shashi Kumar for their support. Abstract ii Abstract In an automotive context todays need of testing functions while in factory, correcting faults in the workshop or adding extra value in the aftermarket makes it very important to easily be able to
5、 download new software to the electronic control units in vehicles. In the platform for standard automotive software development called AUTOSAR, two known protocols are presented to specify the procedure on how to implement this download operation: Unified Diagnostic Services (UDS) and the Universal
6、 Measurement and Calibration Protocol (XCP). However the part of the UDS and XCP standards that is about reprogramming is not completely a part of the AUTOSAR standard yet. In this thesis, UDS and XCP have been compared to evaluate which of the two that has most support in AUTOSAR today and are most
7、 likely to be fully integrated into AUTOSAR in the future. Since UDS already has support in AUTOSAR for some of the functions needed for reprogramming and because of the fact that UDS is a part of the extensively used On-board Diagnostic standard (OBD-II), UDS is chosen to be the most suitable proto
8、col for implementing reprogramming functionality according to AUTOSAR. A bootloader with the ability to download data has been developed using only relevant functions from UDS and following the AUTOSAR specifications where it is applicable. Sammanfattning iii Sammanfattning Fr att kunna testa fordon
9、sfunktioner i fabriken, tgrda mjukvarufel under service eller fr att uppgradera fordonet med nya funktioner r det viktigt att kunna ladda ner ny mjukvara till fordonets styrsystem. Den standardiserade mjukvaruplattformen fr fordonsindustrin, AUTOSAR, innehller tv protokoll som bda specificerar hur m
10、jukvara kan laddas ner: Unified Diagnostic Services (UDS) och Universal Measurement and Calibration Protocol (XCP). Tyvrr r de delarna av UDS och XCP som beskriver mjukvarunerladdning inte en del av AUTOSAR n. I det hr examensarbetet har UDS och XCP jmfrts fr att utvrdera vilken av de bda som i dags
11、lget har strst std fr nerladdning av mjukvara i AUTOSAR och vilken som troligast kommer att bli en del av AUTOSAR i framtiden. Eftersom AUTOSAR redan stdjer ngra av de funktioner i UDS som behvs fr nerladdning av mjukvara samt p grund av att UDS r en del av branschstandarden fr fordonsdiagnostik OBD
12、-II, har UDS valts som den mest lmpade att i dagslget anvndas fr att implementera nerladdning av mjukvara enligt AUTOSAR. En bootloader som stdjer nerladdning av mjukvara via UDS har sedan implementerats enligt AUTOSAR-specifikationen s lngt som mjligt. Keywords iv Keywords AUTOSAR UDS XCP Bootloade
13、r Reprogramming ECU Software Downloads CAN Table of Contents v Table of Contents 1 Introduction . 1 1.1 BACKGROUND . 1 1.2 PURPOSE AND RESEARCH QUESTIONS 1 1.3 DELIMITATIONS 2 1.4 OUTLINE . 2 2 Theoretical background 3 2.1 BOOTLOADER 3 2.2 CONTROLLER AREA NETWORK . 5 2.2.1 Concept of CAN 5 2.3 AUTOS
14、AR . 6 2.4 UNIFIED DIAGNOSTIC SERVICES (UDS) 9 2.4.1 Relationship between UDS and AUTOSAR 14 2.4.2 An UDS use case: Flash Reprogramming 19 2.5 UNIVERSAL MEASUREMENT AND CALIBRATION PROTOCOL (XCP) 20 2.5.1 Packets 21 2.5.2 Security . 22 2.5.3 Flash programming 22 2.5.4 Flash memory access 23 2.5.5 Re
15、lationship between XCP and AUTOSAR 25 2.6 ODEEP QR5567 DEVELOPMENT PLATFORM 28 2.6.1 MPC5567 29 3 Method and implementation 30 3.1 BOOTLOADER FUNCTIONALITY . 30 3.1.1 Setup of MCU (Primary Bootloader) 30 3.1.2 Reprogramming of MCU (Secondary Bootloader) . 34 3.1.3 Creating the bootloaders 34 3.2 USE
16、 OF UDS . 35 3.3 UDS MESSAGES 35 3.3.1 Frames 35 3.3.2 Implemented UDS services . 36 3.4 TOOLS USED . 57 3.4.1 Arctic Studio . 57 3.4.2 PEEDI . 58 3.4.3 SRecord . 59 3.4.4 CANalyzer and CANcaseXL . 60 4 Findings and Analysis . 63 4.1 COMPARISON BETWEEN UDS AND XCP . 63 4.2 INITIALIZATION AND STARTUP
17、 65 4.3 COMMUNICATION . 65 4.3.1 Data flow through layers 65 4.3.2 Data flow through layers, Example: . 67 4.3.3 Diagnostic Sessions 69 4.4 REPROGRAMMING 74 5 Discussion and conclusions . 75 5.1 INCONSISTENCIES IN AUTOSAR REGARDING OPERATION OF THE BOOTLOADER 75 5.2 RESULTS OF IMPLEMENTING ACCORDING
18、 TO AUTOSAR . 77 5.3 CONCLUSIONS . 78 5.4 FURTHER RESEARCH . 78 Table of Contents vi 6 References 79 List of Figures vii List of Figures FIGURE 1 - EXAMPLE OF BOOTSTRAP OVERVIEW 4 FIGURE 2 - CAN FRAME LAYOUT 5 6 FIGURE 3 - OVERVIEW OF AUTOSAR 7 FIGURE 4 - MAIN SOFTWARE LAYERS IN THE AUTOSAR ARCHITEC
19、TURE 8 8 FIGURE 5 - LAYER DIVISION OF THE BSW LAYER 8 9 FIGURE 6 - THE MODULES THAT RESIDES IN THE LAYERS 8 9 FIGURE 7 - UDS NETWORK 11 FIGURE 8 - THE CLIENT AS AN OFF-BOARD TESTER. 11 FIGURE 9 - UDS ALSO DEFINES A SECURITY LAYER IN ORDER TO ENCRYPT DATA. 13 FIGURE 10 - POSITION OF THE DCM MODULE IN
20、 THE AUTOSAR ARCHITECTURE 16 FIGURE 11 - INTERACTION BETWEEN DCM AND OTHER MODULES 18 FIGURE 12 - XCP FRAME 21 FIGURE 13 - COMMUNICATION OBJECTS BETWEEN MASTER AND SLAVE 22 FIGURE 14 - ABSOLUTE ACCESS MODE IN XCP 24 FIGURE 15 - FUNCTIONAL ACCESS MODE IN XCP 25 FIGURE 16 - XCP IN AUTOSAR 26 FIGURE 17
21、 - ODEEP QR5567 DEVELOPMENT PLATFORM 28 FIGURE 18 - DIAGNOSTIC SESSION TRANSITIONS 37 FIGURE 19: VIEW OF PEEDI DEVICE 58 FIGURE 20: LAYOUT OF CONNECTIONS FOR COMMUNICATING WITH PEEDI AND TARGET 58 FIGURE 21: MAIN WINDOW IN CANALYZER VER.7.5.66 60 FIGURE 22: CANCASEXL DEVICE AND INTERFACE CABLE 61 FI
22、GURE 23: NETWORK HARDWARE CONFIGURATION WINDOW 61 FIGURE 24: MEASUREMENT SETUP CONFIGURATION WINDOW 62 FIGURE 25: CAPL BROWSER 62 FIGURE 26 - COMMUNICATION BETWEEN CANTP, PDU ROUTER AND DCM MODULES. 68 FIGURE 27 - PROGRAM FLOW WHEN THE ECU IS IN THE DEFAULT SESSION 69 FIGURE 28 - PROGRAM FLOW WHEN T
23、HE ECU IS IN THE EXTENDED SESSION. 70 FIGURE 29 - PROGRAM FLOW WHEN THE ECU IS IN THE PROGRAMMING SESSION, PART 1 71 FIGURE 30 - PROGRAM FLOW WHEN THE ECU IS IN THE PROGRAMMING SESSION, PART 2 72 FIGURE 31 - PROGRAM FLOW WHEN THE ECU IS IN THE PROGRAMMING SESSION, PART 3 73 FIGURE 32 - SCOPE OF THE
24、MCU DRIVER SPECIFICATION 36 76 List of Tables viii List of Tables TABLE 1: DIAGNOSTIC SPECIFICATIONS APPLICABLE TO THE OSI LAYERS 10 TABLE 2 - SERVICES PROVIDED BY DIFFERENT FUNCTIONAL UNITS DEFINED IN THE UDS STANDARD APPLIED TO THEIR RESPECTIVE USE CASES. 14 TABLE 3 - OSI MODEL 15 TABLE 4 - BOOT M
25、ODES 30 TABLE 5 - RCWD LOCATIONS 31 TABLE 6 - FRAME LAYOUT 35 TABLE 7 - DIAGNOSTIC SESSION CONTROL REQUEST MESSAGE LAYOUT 38 TABLE 8 - DIAGNOSTIC SESSION CONTROL RESPONSE MESSAGE LAYOUT 39 TABLE 9 - CONTROL DTC SETTINGS REQUEST MESSAGE LAYOUT 40 TABLE 10 - CONTROL DTC SETTINGS RESPONSE MESSAGE LAYOU
26、T 41 TABLE 11 - COMMUNICATION CONTROL REQUEST MESSAGE LAYOUT 42 TABLE 12 - COMMUNICATION CONTROL RESPONSE MESSAGE LAYOUT 43 TABLE 13 - SECURITY ACCESS REQUEST MESSAGE LAYOUT 44 TABLE 14 - SECURITY ACCESS RESPONSE MESSAGE LAYOUT 46 TABLE 15 - REQUEST DOWNLOAD REQUEST MESSAGE LAYOUT 47 TABLE 16 - REQU
27、EST DOWNLOAD RESPONSE MESSAGE LAYOUT 48 TABLE 17 - TRANSFER DATA REQUEST MESSAGE LAYOUT 49 TABLE 18 - TRANSFER DATA RESPONSE MESSAGE LAYOUT 50 TABLE 19 - REQUEST TRANSFER EXIT REQUEST MESSAGE LAYOUT 52 TABLE 20 - REQUEST TRANSFER EXIT RESPONSE MESSAGE LAYOUT 52 TABLE 21 - ROUTINE CONTROL REQUEST MES
28、SAGE LAYOUT 53 TABLE 22 - ECU RESET REQUEST MESSAGE LAYOUT 54 TABLE 23 - ECU RESET RESPONSE MESSAGE LAYOUT 55 TABLE 24 - COMPARISON OF FUNCTIONS BETWEEN UDS AND XCP 64 List of Abbreviations ix List of Abbreviations AUTOSAR Automotive Open System Architecture BAM Boot Assist Module CAN Controller Are
29、a Network ExtRAM External Random Access Memory MCU Microcontroller Unit MMU Memory Management Unit PBL Primary Bootloader PCI Protocol Control Information SID Service Identifier PDU Protocol Data Unit CANTp CAN Transport Protocol RCHW Reset Configuration Half Word ROM Read-Only Memory SBL Secondary
30、Bootloader SPE Signal Processing Extension SRAM Internal Static Random Access Memory UDS Unified Diagnostic Services XCP Universal Measurement and Calibration Protocol DCM Diagnostic Communication Manager PPC PowerPC EABI Embedded Application Binary Interface Tx Process of data transmission Rx Proce
31、ss of data reception Introduction 1 1 Introduction 1.1 Background Within the automotive industry there is a recurrent need of loading new application software to the embedded units responsible of vehicle functions, whether it is under development, during maintenance or as a post-sales upgrade. For t
32、his to be possible it is required that these embedded units (also known as “ECU”) support reprogramming through a standard communication interface such as CAN, FlexRay, LIN, Ethernet, etc. In recent years, several car manufacturers, suppliers and tool developers have adopted a standard for the manag
33、ement of vehicle functions within both future applications and standard software modules; such standard is named AUTOSAR (Automotive Open System Architecture). One case of software module management is precisely the area of ECU reprogramming. The AUTOSAR standard, however, does not exactly specify h
34、ow to download a new application program to a target processor within a vehicles Electronic Control Unit (ECU). AUTOSAR supports two standards for diagnostic and calibration of vehicle parameters (UDS and XCP, respectively) which can also provide resources for reprogramming an ECUs processor. An ana
35、lysis of compatibility between each of those standards and AUTOSAR will be done for selecting the best of both. Such selection will lead to the development of a bootloader that will support system start-up and software functionality for reprogramming the QR5567 platform via the standard communicatio
36、n interface CAN. This development shall meet the requirements imposed by AUTOSAR where it is applicable. The functionality of the bootloaders will provide a solution that can be applied to load and start software onto the platform QR5567, which can then be used for further prototyping. This developm
37、ent will intend to satisfy the need expressed above since its operation can emulate the process of reprogramming a cars ECU while still during development in the factory, or while correcting a failure in a service workshop or even when some extra functionality is provided in the aftermarket. 1.2 Pur
38、pose and research questions The purpose is to analyse the communication protocols XCP and UDS from an AUTOSAR perspective to determine which one is most suitable to use for reprogramming of an ECU that are developed according to AUTOSAR. After the analysis is done a bootloader that supports the more
39、 appropriate standard is to be implemented on the development platform QR5567 according to the AUTOSAR specifications as far as possible. Introduction 2 1.3 Delimitations In the analysis of communication protocols UDS and XCP only functions regarding reprogramming will be covered, other part of UDS
40、and XCP will not be taken into consideration when comparing them. Only relevant parts regarding reprogramming of AUTOSAR will be implemented. This report will only focus on CAN as the communication interface, even though other communication interfaces are supported in hardware, and XCP, UDS and AUTO
41、SAR. 1.4 Outline The first part of the report, theoretical background, covers the bootloader concept and the concepts and the standards CAN, AUTOSAR, UDS and XCP. The next part, Method and implementation, describes the features of UDS from an AUTOSAR perspective and how UDS and AUTOSAR are used in t
42、he implementation. In the third part, Findings and Analysis, the outcome of the functions of the software that has been implemented is presented. The last part, Discussion and Conclusions, includes a comment on the coverage of bootloaders provided by AUTOSAR, summarizes the work and proposes how it
43、can be further developed. Theoretical background 3 2 Theoretical background 2.1 Bootloader Among the multiple conceptions that exist regarding the definition of a bootloader one common approach is that it is considered to be a fixed piece of software or firmware residing at least partially in the no
44、n-volatile memory area of a microprocessor, such as ROM or Flash. The “firm” condition of the bootloader is based on the idea that once designed and developed its not supposed to be object of many changes or maintenance during the processor lifetime as an application program would eventually undergo
45、. The different views that exist towards the features and operation that a bootloader should perform are often motivated, for instance, by the following factors: The resources eventually needed by a running application (time, memory, interrupts) The resources supported by each specific MCU (types of
46、 memories, access to special function registers, interrupt stack). The amount of memory available for storing initialization code. Despite these variations its a common practice to implement the bootloader in such a fashion that it starts running right after power-up, whether coming from a system so
47、ftware reset, external induced reset (incoming signal or command via communication interface or event-sensed configured), manual reset or by just applying power supply to the processor to turn it on. Usually embedded processors fetch and execute code from the reset vector at a defined address in ROM
48、 or Flash, to further jump to another section of memory where the initialization code resides. This is done to keep the reset vector small. Whether it is due the requirements imposed by an application or the capabilities of a specific processor, at its core some of the most basic and generally agree
49、d functionalities of a bootloader are: Minimal hardware initialization. Especially since its the first code the CPU executes upon power up. It might include: o Enabling access to / initializing internal RAM o Default initialization of MCU system clock for provision of timebase and prescalers. o Setting up Phase Lock Loops (PLLs) o Initialization of base addresses for Interrupt and Exception Trap Vector Theoretical background 4 o Initialization of user stack pointer o Initialization of cache and/or external memory if such memory type
