Learning by examples is always a good jumpstart. So here i attach a CAN-log made with CANhacker (one of my favorite tools) from a Ford AFS module programming (Firmware update) session. I've done it with UCDS on the desk. So only the module and the programmer is involved in the communication. This was my setup:
hardwareaufbau_update.jpg
This is was the module looks like:
afs-modul_7s71-13k031-af.jpg
Inside, we find good old pals, like the "NEC 70F3231" (position IC1):
afs-modul_7s71-13k01-af_component-side.png
afs-modul_7s71-13k01-af_solder-side.png
I bet the 8pin unpopulated header on the left of IC8 is an programming interface for the module. Most vendors use such headers in the development phase or for initial programming.
But, let's inspect the CAN-log as we want to learn about programming by CAN, not by serial:
The relevant CAN-IDs inside the logfile are 0x734 (this is OBD-ID of the AFS module) and 0x73C (this is the dynamic OBD-ID of the programmer). On the beginning of the file you can see how the UCDS is scanning the bus for modules until it gets an positive response from the AFS module.
Lets start with the first valid communication. I've therefore picked the start from the log with an arbitrary length:
Code: Select all
...
07,861 734 8 02 10 02 00 00 00 00 00
07,877 73C 8 06 50 02 00 19 01 F4 00
08,890 734 8 02 27 01 00 00 00 00 00
08,891 73C 8 05 67 01 03 22 43 00 00
08,893 734 8 05 27 02 E9 AF D1 00 00
08,895 73C 8 02 67 02 00 00 00 00 00
08,957 734 8 10 0B 34 00 44 FF FF D9
08,958 73C 8 30 00 00 00 00 00 00 00
08,960 734 8 21 50 00 00 01 86 00 00
08,961 73C 8 04 74 20 00 82 00 00 00
08,969 734 8 10 82 36 01 85 0D 81 3F
08,970 73C 8 30 00 00 00 00 00 00 00
08,975 734 8 21 01 00 45 3F 00 00 41
...
Because CAN is message oriented, the first thing the UCDS (we call it "programmer") do is to send this to the bus:
Code: Select all
07,861 734 8 02 10 02 00 00 00 00 00
The first column is the timecode, we can ignore, next comes the message-ID of the CAN frame. The AFS module will receive this, because it knows itself by this ID. The message is set to a length of 8 bytes, indicated by the 3rd column value. As we see, the remaining is payload (data) for the CAN protocol and so we are switching to OSI layer 7 here.
The payload seems to be padded to 8 bytes using zeros, which is very common. The first payload byte is protocol specific and denotes the number of bytes, the following message will use. This can be more than one CAN frame can carry, but more to this later. Here we have 2 bytes and so in fact this is the message we should care is:
From the docs we know that UDS uses a "request / response" method for communicating. So this first one must be a request from the programmer to the module. The docs telling us, that each request contains the "Service Identifier" (SID) first and, depending on it's type, parameters for it. Now we are looking for the SID "10", what it means and what params it takes. The service 0x10 is known as "
DiagnosticSessionControl" and is used to open a special session with the module. The next byte is the only parameter for this and tells with subfunction to use. The docs tell us that 0x02 is for "
programmingSession".
In the next line we find the response of this request (for simplicity i only quote the real payload):
As per the docs, all request messages must have set Bit 6 of SID to 0 and all positive response messages must have set Bit 6 to 1. So with request SID of 0x10 (binary is written 0b0001 0000), the positive response SID is 0x50 (0b0101 0000). The SID code of 0x7F is reserved to denote a negative response.
In the next Byte the called function is repeated: 0x02. As of the standard, the response usually end here, but there are some extra bytes. Currently i have no clue what they mean. The standard allows sending n'th params. Maybe this is Ford specific or any kind of entrophy.
UCDS told us that there must be 3 files downloaded to the module:
ucds_afs_firmware_downloaded.png
It was pretty easy to get those files using the download-URL
http://www.ucdsys.ru/calibration/
After unziping and extracting the binary part of it, i had the 3 files UCDS would upload, and also the order they should appear in the log. A simple textsearch for the first and last 4 bytes shows me where the data gets send to the module:
"7S7T-14C087-AB" starts at logline 131 and ends at 1019
"7S7T-14C084-AK" starts at logline 1042 and ends at 19878
"7S7T-14C399-AC" starts at logline 19893 and ends at 20262
A closer inspection of the sending process shows the beauty of transport segmentation protocol of CAN, defined in ISO 15765-2. As you know a standard CAN frame can contain up to 8 Bytes of payload. To send larger ammounts of data, multiple, consecutive frames are necessary, spreading the data over the frames (called "segmentation"). The ISO defines an easy way to do this with less overhead.
All the CAN messages inbetween are needed for setup the module for updating. Removing the data transmittion itself dramatically reduces the communication log.
You do not have the required permissions to view the files attached to this post.
