An ECU can use a bootloader to manage supported software programming and a separate application for its normal vehicle functions. Moving between these stages is part of the software design. A controller that responds during programming is not necessarily running its normal application successfully.
Identify which stage still responds
Vector’s application-to-bootloader documentation describes coordinated transitions and the information passed between the two. For a repair enquiry, the practical point is to preserve the diagnostic log rather than reduce the result to alive or dead.
Record whether the tool could identify the ECU, enter the programming operation, transfer data, verify it and complete the return to normal operation. An interruption at one of those stages gives different evidence from a total absence of communication.
Recovery depends on the controller
The correct route depends on the hardware, software and failed operation. A generic donor file or an instruction intended for another ECU can remove useful original information. Keep the original unit and any unmodified records available.
Send AXION the full module label and operation history before arranging recovery work. We can confirm whether assessment is supported and what further information is needed. A bootloader response should be described accurately, without presenting it as proof that the whole controller has passed a functional test.
Arrange an assessment
For module programming and coding, send the vehicle details and fault report to AXION. We support enquiries from drivers and garages. Workshop, postal and remote options depend on the job and are confirmed before booking.
Technical reference
Read the supporting technical documentation. The referenced design or vehicle application defines its scope; it is not a universal repair procedure.
Related reading
MCU flash ECC faults and what a corrected memory read proves. Browse the automotive electronics repair library for other systems and symptoms.