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

9.3.2.3.6 Boot Software Programming Routines. 
The boot software programming routines are those
hardware specific routines needed to program the ECU permanent memory. Examples include memory erase,
memory write, routines to turn programming voltage on or off, and checksum calculation routines. These
routines provide pass or fail indications back to the boot software programming executive so that it can make a
decision whether or not to continue the programming event.
At the end of writing/erasing a section of memory, the memory that has been erased/written to shall be
checked to ensure that it was done successfully. The success or failure of the erase/write operation(s) shall be
communicated back to the programming executive. The programming executive shall then interface with the
diagnostic service manager and the message handler to communicate the result to the programming tool in the
form of a TransferData ($36) positive response message or through a negative response ($7F) message
including the appropriate response code (other than response code $78).
Although the programming routines can technically either reside in the boot software or in the routine section of
the programming Utility File, it is recommended that these routines be stored in the Utility File to minimize the
size of the boot software.
If the programming routines are stored in the Utility File and more than one supplier of permanent memory
exists for that type of programmable ECU, then the Utility file shall contain all of the programming routines for
all types of permanent memory allowed.
9.3.2.3.7 Boot Software General Requirements. 
All ECUs operating out of boot memory shall be able to
receive diagnostic messages using the AllNodes request CANId with AllNodes extended address. SPS
Programmable ECUs with preprogrammed permanent diagnostic CAN Identifiers (SPS_TYPE_A or
SPS_TYPE_B) shall also be able to receive messages addressed with its PTP request CANId. SPS_TYPE_C
ECUs (which do not have preprogrammed permanent diagnostic CAN Identifiers) shall respond to requests
sent with the SPS_PrimeReq ($0xx) CANId once diagnostic responses have been enabled.
An ECU shall be capable of using the same diagnostic CAN Identifiers for the duration of a programming
event. This means that an ECU which is fully programmed at the beginning of a programming event
(SPS_TYPE_A ECU), shall use its permanent diagnostic CAN Identifiers during the programming event even if
the boot code only contains the SPS_Prime CANIds. To accomplish this, the permanent diagnostic CAN
Identifiers must be provided to the boot software from the normal operational software when program control is
transferred back to the boot software. The boot software is not required to retain the permanent diagnostic
CAN Identifiers passed from the operational software if the programming event is interrupted prior to its
completion and the ECU has performed a software reset (this is valid if the boot software only supports the
SPS_Prime CAN Identifiers).
The boot software shall be protected. The boot software can be protected via hardware (e.g., via settings in a
control register which prevents certain sectors of the memory from being erased or written to) or software (e.g.,

---

25.06.2020
WORLDWIDE ENGINEERING STANDARDS General Motors Local Area Network Enhanced Diagnostic Test Mode Specification
https://translate.googleusercontent.com/translate_f
226/298
February 2010
Page 254 of 336
--``,,``````,``,,``,,,`,`,`,,-`-`,,`,,`,`,,`---