ACT v2 for PSA Group Vehicles: ECU Backup, Coding, Search and Programming Tasks

When performing ECU (Electronic Control Unit) programming, coding matching, and diagnosis on vehicles from the PSA Group (like Peugeot and Citroën), professional diagnostic equipment (such as the ACT v2 PSA-specific tool) and strict operating procedures are crucial. A key task when uploading new calibration files, replacing control units, or encountering unknown codes is to perform ‌backup, search, and compatibility testing‌ of the vehicle's original coding configuration. This follows the standardized operational logic behind many professional tools.

‌Core Operational Process Explained (Based on Technical Documentation)‌

‌Initial Startup and Preparation‌

Start the dedicated automotive diagnostic/programming application (e.g., the relevant module within the ACT v2 software suite) and connect to the vehicle. The focus is on confirming communication has been established with the target ECU (such as the engine, transmission, or body control module).

‌Critical Step: Using Backup in Conjunction with the Search Engine‌

The documentation explicitly states that the core of the operation is ‌using the "BACKUP" function in combination with the ECU search engine‌, particularly suitable for operations on systems like ‌gearbox, tires, and brakes‌.

"YOU USE BACKUP WITH ECU-SEARCH ENGINE COMBINATION GEARBOX TIRES BRAKES"

Before making any changes, be sure to perform a complete backup of the existing configuration. This is the foundation for subsequent coding matching and testing.

‌Accurately Selecting Test Bytes‌

The key to coding tests lies in the ‌rules for byte selection‌:

• ‌Order‌: Follow the ‌direction of the left-to-right selection order‌ (Note-direction of the left-to-right selection order).
• ‌Combination Logic‌: For byte groups representing the same system (e.g., multiple bytes in the engine section, usually highlighted in the same color), ‌you can select only 1 CHECKBOX per test cycle‌. This is because valid coding combinations are limited.
• 
  

"In sections with the same color e.g. engine-you can select only 1 CHECKBOX because engine encoding can be FF FF F7 or FF F7 FF But there is no encoding FF F7 F7 - such a search does not make sense!!"

For example, engine encoding might be FF FF F7 or FF F7 FF, but a combination like FF F7 F7 would never occur. Incorrect selection will lead to meaningless, lengthy searches.

‌Coding Compatibility Search Process‌

After completing byte selection, you can initiate the ‌search for configurations compatible with the new calibration file‌.

• ‌Security Access (SEED Login)‌: After starting, the system usually initiates a SEED login (security access). If the first key does not match, a re-login with a second key may be required.
• 
  

"After the start, the SEED login will start appearing in the send window... After a successful login, further backups will be sent with a jump of 1 in the next selected bytes"

• ‌Iterative Testing‌: After a successful login, the tool will use the backup data and traverse all possible byte combinations ‌by incrementing the subsequent selected bytes one by one‌. For example, if 4 bytes are selected, it will test all 8-bit combinations on each of the other 3 selected bytes (total of 4 bytes).
• ‌Duration‌: This process may last ‌up to 30 minutes‌. For complex systems like the engine subjected to triple testing, it can take up to ‌1.5 hours‌ (three cycles).

During the search, all matching coding configurations are detected and moved to a results window. After the operation is complete, you can save the results to a text file for review.

‌Important Scenario: Handling Coding After Uploading a New Calibration File‌

The documentation specifically explains how to proceed when the coding field is empty after uploading a new calibration file (.ulp):

• ‌Standard Case‌: After uploading a new file, if the coding field appears empty (all FF), you can apply your own coding or another usable coding from a reliable database.
• ‌Specific Case of Unknown Body Coding‌: ‌Searching for body coding only makes sense under specific conditions: namely, when direct upload of a .ulp file has cleared the encoding and we do not know the original value of the body coding.‌

"Searching the body coding only makes sense after direct upload .ulp when the encoding is cleared and we do not know the body encoding value."

• ‌Crucial Reason‌: Body coding is critical because it usually becomes ‌tied to the specific calibration file used‌ after programming and cannot be changed once bound.

"...the programmed body is tied to the calibration used and is not subject to change."

• ‌Solution‌: When the coding is unknown and needs to be matched, the operator needs to ‌select the body and three other key bytes‌ in the selection bar and then ‌enter the presumed values of these bytes into the coding bar in the order from left to right‌ to initiate a search for compatible configurations.
• 
  

‌Conclusion‌

Using ALicar ACT v2 or similar advanced tools for ECU programming in PSA Group vehicles is a task that demands high precision and adherence to procedure. The keys to success are: ‌strictly following the 'backup first, operate later' principle‌, ‌deeply understanding byte selection logic to avoid invalid searches‌, and ‌correctly handling special scenarios like unknown coding (especially the immutable binding of body coding)‌. The general operational logic outlined above, based on technical manuals, forms the foundation for ensuring that the ECU programming process is efficient, safe, and successful.