Страница 1 мировой engineering стандарты общая спецификация

Page 253
GM WORLDWIDE ENGINEERING STANDARDS
GMW3110
9.3.2.3.3 Boot Software Message Handler. 
The boot software message handler is responsible for
transferring information between the programming tool and the boot software programming executive. Included
in this component of the boot software are the CAN driver, the CAN hardware message filtering logic, support
of the Network Transport Layer, and high speed support for SWCAN ECUs.
The Network Layer supported in the ECU boot software shall maximize the size of the network layer buffer and
minimize the size of the network layer parameter ST
min 
to maximize the efficiency of data block transfers. The
ECU shall allocate some or all of its RAM resources used for normal operation for the network layer buffer
when operating out of the boot code. The value of ST
min 
during normal operation can be different than the
value used during programming.
The CAN hardware message filtering logic in the boot software shall meet the requirements specified in
paragraph 9.2 - Requirements for All ECUs to Support Programming.
9.3.2.3.4 Boot Software Programming Executive and Program Loader. 
The boot software programming
executive coordinates the sequence of events during a programming session. The programming executive has
knowledge of the memory map including the allowed application program area, RAM location, and logic for
handling flash sectors (if applicable).
The programming executive keeps track of the various software and calibration modules, their starting
address, length, and checksum. The executive interfaces with the boot software diagnostic service manager
and the boot software message handler to verify incoming data from the programming tool and to provide
responses to the programming tool. The executive handles transferring the programming routines to RAM and
interfaces with the programming routines to transfer the software and calibration modules to permanent
memory.
During the download of a data file (operational software or calibration data) the programming executive
interfaces with the programming routines to verify the successful erase/write performed on a section of
memory, The programming executive shall also perform a verification of successful programming at the
conclusion of each downloaded software or calibration module (data file) by calculating a running checksum or
CRC as a module is being downloaded. When the last TransferData request of a module has been processed
(confirmation from the programming routine that the data was successfully written to permanent memory), the
programming executive shall compare the checksum or CRC against the value in the product memory file
header (refer to paragraph 9.3.3.1). If the calculated value does not match the value in the product memory file
header, a negative response shall be sent indicating a programming fault (Negative response code $85
General Programming Failure). The method used to calculate the checksum or CRC of the data files shall be
specified in a CTS, SSTS, supplemental diagnostic specification, or bootloader specification referenced by
either the CTS or SSTS.
The programming executive is also responsible for performing compatibility checks (if required) to ensure that
the operational software will work with the bootloader and that each calibration data file is compatible with the
operational software that is programmed in the ECU. Performing compatibility checks prevents the possibility
of continuous running resets due to a mismatch in the data files (e.g., calibration file size changes due to
software change and programming done with new software module and old calibration file) which can leave
the part unrecoverable. The programming executive performs the compatibility checks using the DCID values
as defined in paragraph 9.3.3.1. For an operational software file the DCID in the data file header is compared
against a constant stored in the bootloader. If the two compatibility values do not match, the data file is not
downloaded to permanent memory. For calibration data files the DCID is compared against a corresponding
value in the operational software header (e.g., DCID_am1) and if the two do not match the data file is not
downloaded to permanent memory. Any compatibility check failure shall result in a negative response
message with response code $85 General Programming Failure. The appropriate CTS, SSTS, supplemental
diagnostic specification, or bootloader specification referenced by either the CTS or SSTS shall document
whether or not compatibility checks are required for a particular ECU and any additional requirements relative
to their values or implementation.
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---

---

25.06.2020
WORLDWIDE ENGINEERING STANDARDS General Motors Local Area Network Enhanced Diagnostic Test Mode Specification
https://translate.googleusercontent.com/translate_f
225/298
© Copyright 2010 General Motors All Rights Reserved
February 2010
Page 253 of 336
When the programming executive detects the end of the programming event (e.g., a service $20 request is
received or a P3
C 
timeout occurs), it shall inform the message handler to reset back to the normal baud rate (if
applicable for SWCAN) and trigger a software reset. The executive also interfaces with the power
management component of the boot software to allow an ECU to run out of the boot software to enter a low
power state if a programming event has not begun within 1 minute of a wake-up or power being applied to the
ECU.