1. Meaning of the Error
This error occurs when the content of Data1 (the first byte) of the response (busy frame)
to the command frame sent from the programmer does not match the command
number sent from the programmer (i.e., not normal data).
Usually, the busy frame is specified to return (echo back) the same value as the received
command number. Therefore, an error is determined at the moment a data mismatch is
detected.
2. Causes and Countermeasures
(1) Abnormal response / Malfunction on the ECU (target) side
Cause:
- Possibility that the WCP expansion area or RAM work area (stack, heap, global variables, etc.)
is corrupted by the behavior of the customized IBL/WCP or user application, causing
the WCP to not operate correctly, or overlapping areas on the RAM (memory configuration
abnormality).
Countermeasure:
- Check the linker map (memory allocation) of the IBL/WCP and user application to confirm
and correct any overlapping areas on the RAM.
- Build the modified program and program it into the target (write the IBL and user application
using a serial programmer, etc.), and replace the BTP file in the YIM folder for the WCP. Execute reprogramming again to see if the error is resolved.
<Notes on Source Code Modification and Customization>
If the source code provided by us is modified by the customer, it will be out of our support warranty.
Please evaluate and implement it under your own responsibility. If we accept a request for analysis,
actual expenses corresponding to the investigation engineering man-hours will be charged.
In addition, modifications involving device (microcomputer) changes are generally subject to separate
billing for Micom Pack development costs.
(2) Interference from other CAN nodes (Specific to actual vehicle / vehicle environment)
Cause:
- A case where data is transmitted from a node that is not the target of programming on the
vehicle CAN network (e.g., FI ECU), and the WCP recognizes the packet as an "undefined command
(illegal command)" and returns an error response (such as FEh).
Countermeasure:
- Execute programming in a standalone environment (only the ECU to be programmed) and
check if the error does not occur, to isolate the presence or absence of interference from other nodes.
- Temporarily disconnect other CAN nodes that are causing data interference from the network
when executing reprogramming.
- If other CAN nodes cannot be disconnected in the actual vehicle environment, modify the WCP side
to filter unnecessary IDs and control it so that it does not return an error response.
(3) Common items for confirmation and countermeasures
- Collecting CAN communication logs and protocol analysis
- Collect the CAN communication log (including time data) at the time of error occurrence and
check whether transmission and reception are performed in accordance with the UCOP protocol
specifications. Verify normality on the log by checking if Data1 with the same command number
is correctly returned in response to the command transmission.
* When collecting logs, it is mandatory to set the CAN logger (protocol analyzer) itself so that
it does not overwrite the ACK slot (Listen Mode / do not return ACK).
- Rechecking the YIM folder (setting files)
- Considering the possibility that the contents of the BTP file, etc., in the folder are corrupted,
try replacing it with a clean YIM folder whose normal operation has been confirmed in a desktop
environment, etc. Execute again after replacing the YIM folder to check if it is not an error caused
by the setting files.
- Checking the version of the Definition Program file (.CM)
- If the version of the Definition Program file (.CM) you are using is old, replace it with the latest one
and check the operation.
- Latest Definition Program release versions:
- FCX839-S2: Ver17.03
- FCX839-S3: Ver17.00
- NAPYDC839G: Ver15.06