Monday, December 24, 2012

Happy holidays!

Ho ho! A new version of SardineCAN is out!

Due to popular requests, I've added support for Lawicel CANUSB and CAN232 devices for both the Arduino firmware as well as to the Win32DLL. For more information about these devices, see
Manufacturer page and the Manual / Command set reference.

What does this mean?

- Owners of Lawicel CAN devices are able to use programs supporting J2534 protocol (such as Volvo VIDA) without any hardware modifications!
- Those who have taken the time to construct SardineCAN themselves, are able to use additional diagnostic programs such as CanHacker as well as numerous other programs that support the CANUSB protocol, since SardineCAN now emulates it by default.

I haven't got any Lawicel devices myself, so I can't be 100% sure that the protocol support works in all cases, but when testing it with CanHacker it seems to function just fine. Please let me know if you come across any problems!

I haven't yet merged the changes into the main branch, but will do that after I get positive feedback from users and make sure that these major changes don't break anything. Meanwhile, the CANUSB branches can be found here and here.

I've also been informed that there is a problem when opening the Visual Studio solution file with Express 2010 edition. Since I do the developing with the Visual Studio 2012 that uses a newer solution file format, earlier versions get confused and refuse to open it.  I heard that Express 2010 Service Pack 1 adds the capability to open 2012 solutions, so you should check it out (much easier than handling separate project files for different Visual studio versions..)





Thursday, December 13, 2012

Sardine CAN version 0.2 alpha now available!

Hello all,

Sardine CAN is now available as open source software, as promised some time ago. In the past few days I've been cleaning up the code and writing short pieces of documentation to help in installation, but to get more detailed view of the software, one must resort to reading comments that are peppered all over the source code.

Please note that this is still HIGHLY EXPERIMENTAL software and great care should be taken when using it beyond any test installation on your desktop, such as diagnosing your car or clearing error codes stored in ECUs. Flashing any ECUs or making any other bigger changes in your car is completely beyond the scope of Sardine CAN and even though it might be possible in theory, I wouldn't dare to try it. If you respect your daily commuter at all, please buy a commercial product for that purpose.
For basic diagnosing I do not anticipate any big problems, but still, should you decide to use Sardine CAN, it is done completely on your own risk. I won't be held responsible for any damage caused to you, your property or nearby persons by any attempts to use Sardine CAN in any other ways except than by looking at the source code. Sorry, one more addendum: Should you get a head ache or burst your brain aneurysm while reading the source code, I won't be held responsible. And no reading while driving!

That being said, installation should be quite straightforward. Just follow the installation instructions and you should be fine.

The code can be found in GitHub in HERE.  You need to download both repositories, the Arduino firmware and the Win32 DLL.  If you don't want to install Git (though highly recommended), you can download repositories as complete ZIP files.

So, what can you do with it?

I've been able to use it with VIDA to identify my car and all the various ECUs in the low-speed CAN bus. It can read and clear error codes stored in all the available modules. Also with VIDA it is possible to use various diagnostic commands to test ECU functionality (for example to activate wipers, power windows, test heater functionality etc) as well as read various status parameters available on each ECU. Remember, J2534 is just a pass-through protocol. All the functionality depends on the program using the J2534 interface.

Note that ISO9141 K-line initialization is not yet implemented, so at least in my Volvo S80 (year model 2002) it is not possible to plug this straight into OBD port, because the lack of initialization causes the diagnostic relay to stay closed and thus CAN bus pins on the OBD port remain floating. However any other CAN bus port can be used, such as RTI or AEM connector, or perhaps a connector in the audio module.

Do also note that Sardine CAN hasn't been tested on the high speed CAN bus yet, but the data rate is hard-coded to 125 KBit/s (speed of low speed CAN bus in my car). Also the PASS filter is hardcoded in Arduino firmware to accept diagnostic messages originating only from addresses of the form 0080xxxx, so if you have problems receiving messages from Arduino, please check with some other CAN reader the diagnostic addresses that ECUs use in your car - they might be different from those that are expected.

Even though the device works quite well in my car, I'm sure there are bugs and there will be problems, not to mention nuisances caused by missing functionality. Please don't hesitate to contact me, but in case you do, include all the necessary information (your car model and year, software used (Windows version etc)) as well as attach the log files related to the incident along with the description what happened. Also if you have any coding skills, I would be happy to receive patches and bug fixes and maybe even some code to implement functionality that is still missing.

Happy hacking!

Best regards,
Olaf

Tuesday, December 11, 2012

Anatomy of Ardic

Greetings from the non-insulated garage of my parents! I don't have any warm facilities to fix my car, so this will have to do. It was a nice warm day of -5 celsius when I decided that it is now or never (actually now or next summer) when I'm going to tear down the Ardic and see what's the problem.

Here's a nice post about removing and servicing Ardic. (Sorry, instructions only in Finnish).

Here's an explosion diagram of Ardic. Year is 2003, but seems to be identical to mine. Taken from Finnish Volvo forum, topic designated to Ardic problems..


Here's the big guy itself after removing the front bumper. Inferring from the rusted screws I would think this thing hasn't been serviced in years, maybe never during the 10 years this thing existed. There has been quite many previous owners and according to the owner history database, each of them had this car only little bit over 2 years.

After one hour of careful separation process in -6C, we can continue disassembly inside in room temperature! 



Glow plug, water pump and outer shell removed.


Testing the glow plug. Intact, as I suspected.

Inner shell shell removed, revealing chunks of soot attached to the walls 
Here's the combustion fan motor, working normally. Little bit to the left under the cap resides the flame sensor that is directed toward the combustion chamber. I managed not to take any pictures from right angle, but there was little bit of soot there as well, blocking the view of the flame and causing the main problem here. After some cleaning, the flame sensor reads ~8 Mohm when in dark and around 430 Kohm when teased with direct light from a flashlight.

Quite a bit of soot also under (actually over, since the unit seen here is held upside-down normally) the cup and the turbulator. There's a shadow under it too, but most of it is soot actually.

Here's the CPM. It's funny feeling seeing it now here, like meeting somebody in real life after you have spent weeks chatting online :)
We know each other so well already, so there was no need to be embarrassed. Let's take the cover off and look if there are any unhappy burned parts. None found.


Only after putting the whole thing together again and looking this image more carefully when uploading this picture, I noticed this burned looking solder joint little bit from the center to the direction of upper left corner. Weird, since the heater seems to be working now.  Maybe it was just the angle, light doing its tricks.
So, I cleaned the heater from all the soot and put the thing back together. Fingers crossed, I started the heater and behold, it works now! It seems that soot builds up as a result of imperfect combustion and eventually blocks the light/flame sensor. When this happens CPM thinks there's a problem with fuel delivery or some other functionality, and then stops the heater. Ardic does need service at least every two years, but some people service it annually, especially when there's a lot of short distance driving and the heater runs cold proportionally greater periods.

 I didn't touch the water pump since it seems to be working and I don't have any spare rubber parts should the pump need any of them changed after opening the thing to prevent leaks. Anyways, I'm going to buy a new pump next summer when I'm servicing this thing again, just in case. It's interesting to see how much soot buildup will occur during the winter months with my personal driving style and preferences. From there it will be possible to estimate how long a relatively safe service period would be. It would be possible perhaps to estimate this based on the voltage reading of flame sensor! Of course, this would require reaching a steady state, maybe after running the heater for one hour until all the temperatures reach equilibrium and then check the sensor voltage. The nearer it is to the 2.5 volt threshold (explained in previous post) when the heater is on, the more the there could be soot covering the eye of the flame sensor. I will have to check the reading soon when it is still clean.

UPDATE: The flame sensor voltage will fluctuate between 0.6 and 1.0 volts when the furnace has been cleaned. Boys, when it starts to climb over 2.0 volts near the 2.5V threshold, it's time to grab your wrenches and mops and start cleaning!

Sunday, December 9, 2012

FFffuuuuuuu......

Succession of failures. What an oxymoron.

A week ago I continued testing the ignition of parking heater with diagnostic commands. Last time I checked, it worked without the key in ignition using VIDA, so I took another shot with ELM327. No go. Ok, started injecting the periodic keep-alive message to CAN bus and tried again, but without any success. Then I put the key into position I, and what do you know, the heater started. It DOES need the key in the ignition after all, so there goes my plan to implement the remote control using the diagnostic commands. <insert swear words and cursing here/> My previous success with VIDA must have been because of some kind of inherent timeout in the CEM. Diagnostic codes and commands work for some period of time after the key is removed from the ignition, but after a while (maybe because of security reasons) the CEM stops responding to them.

There is a way to spoof the other modules into thinking that the key is in the ignition by overwriting the continuous status updates made by CEM about the key position, but there's no workaround when it comes to CEM itself. It would be like breaking into you own car. So I folded in front of this another unforeseen obstacle, took the path of less resistance and ordered the AEM module. It's going to cost little bit over 200 euros (including software updates to CEM and AEM itself), sure, but I didn't see any way beyond the key problem and I'd spent enough time tackling this one.

BTW. Guys in King of Thrones are wrong. The winter isn't coming. It's freaking already here! Few days ago the temperature went down to -22 celsius ( -7 fahrenheit)!  And that resulted in the next system failure...

The parking heater stopped working. The day before this total failure it already gave a hint for the upcoming problem. For some reason it hadn't reacted to previously set timer, but did go off when starting it manually.  Next day, I had set the timer again, but when I approached the car, I could see that everything was still frozen. Attempted starting the heater manually, and it did run for a minute or two, but then stopped again. Tried it for the third time, but the same thing happened.

Now after three unsuccessful start attempts the CPM goes into lock-down that can only be reset with VIDA or other expensive diagnostic device. Poor man's choice, Torque + ELM327 won't do, since they won't be able to query CPMs fault codes and reset them. So, my efforts developing the Sardine CAN and playing around with VIDA weren't total waste of time. Lucky me, except that I was visiting my parents' house and I didn't have the device with me, so I had to resort to firing up the engine in -22C since there isn't any additional heater installed in the car.

Except now the car would start. Motor would cough for a second or two, but then the start motor just continued to spin. Now I was starting to get pissed off.  This sounded more like a battery problem or frozen fuel lines, since a problem in either one of those could affect both the motor and the heater. There was no low voltage light on the DIM lit,  but I didn't have my multimeter to check the battery voltage. The artic diesel variety that is offered here in Northern Finland is supposed to handle at least -29C temperatures without gelling/waxing and clogging the fuel filter and the fuel lines. Anyway, I didn't have any way to pinpoint the problem at this stage. Luckily I managed to start the engine after covering it with blankets and letting two powerful heat blowers warm it up from below a bit. Even that took over 2 hours.

So I got home, connected my dear Sardine CAN, fired up VIDA and started snooping around. First, the fault codes:


Now this is interesting. There's no way simple fuel clogging problem would result fault codes piling up as they do in this list. Especially CEM-6C48 is meaningful in this context. It would indicate there was a communication problem between CEM and the transponder implanted in the ignition key. It could be caused by many different reasons (two different keys next to each other in the keychain, electrical interference, wrong key etc), but end result would be the same: Fuel delivery is inhibited to fuel injectors and motor wouldn't start. However this wouldn't have any effect on the heater, since its fuel input is controlled by heaters own fuel pump which is independent from any security measures related to engine. Anyways, fault codes this many in so many different modules would be unlikely to occur for reasons indicated in each fault code. There must have been some kind of electrical connectivity problem because of the weather, most likely in the CEM or one of its harnesses. If this ever happens again, I will have to dig into this, but for now, I reset the fault codes and wait if any of them should pop up again.

Now that the fault code for heater (CEM-5F4F : Too many unsuccessful start attempts) was also been cleared, I was free to try starting up the heater, but with this time I had VIDA to guide me with troubleshooting.



Glow plug, combustion fan as well as water and fuel pumps were working normally, but the flame sensor read constant voltage. According to VIDA, voltages from 2.5 to 5.0 are interpreted as "no flame" and voltages below 2.5 volts mean there is a flame in the heater. The CPM waits for a while for the diesel to ignite, but after 1-2 mins it gives up, stops the heater and increments the error counter. So, either the flame sensor has broken down or is covered up, or the diesel fuel doesn't reach the heater. Anyway, the problem most likely isn't going to go away magically and repair shops usually ask between 400-600 euros + parts for the repair, so I think you're going guess where I'm going with this..

Next: Ardic tear-down!

Saturday, December 1, 2012

Success!


It's Saturday night and I feel like partying! :D  After countless hours and ~3500 lines of code later, I finally managed to connect VIDA successfully to Volvo, launch the diagnostic part related to Combustion Preheater Module and turn on the parking heater with my laptop!

Sorry about the poor image quality here:

Vida correctly identifies most of the vehicle features. Only transmission, steering and body style had to be manually entered. Reason for this can be seen in the next picture..
Sardine CAN is connected to low speed network, so all queries relating to CAN modules residing in high-speed network (such as Break Control Module,  Staareing Angle Sensor, Engine Control Module, Transmission Control Module as well as the high speed interface of Central Electronic Module) cannot be reached. For some reason messages from few low speed modules ( Upper Electronic Module, SRS, Rear Electronic Module) are not received correctly either. Accessory Electronic Module and Road Traffic Information module I don't have in my car.
When sniffing the CAN traffic while VIDA scans the modules and their diagnostic error codes, I can infer which module is being queried and which CAN identifier the module uses for replying. Note that this identifier differs from the one the module uses for normal inter-module communications.

Let's refresh our memories of the general format of module query (from past blog post):

000FFFFE CB xx B9 F0 00 00 00 00
          |  |  |  |
          |  |  |  |
          |  |  |  '---- Identify (?)
          |  |  '----------------- Read Data Block By Offset
          |  '-------------------- Module id (list below)
          '----------------------- Message length

00 0F FF FE: The identifier VIDA (or any other diagnostic module) uses for messaging.
Message length: High nibble seems to be always 'C' in command message. Low nibble: Bit 3 is always on. Bits 0-2 is the actual message length (excluding the first byte). Hence A=2, B=3, C=4, D=5, E=6, F=7

I found this command set somewhere on Swedespeed car forum:

A1 No Operation Performed (keep alive)
A3 Security Access Mode 
A5 Read Current Data By Offset 
A6 Read Current Data By Identifier
A7 Read Current Data By Address 
A8 Set Data Transmission
A9 Stop Data Transmission
AA Dynamically Define Record
AB Read Freeze Frame Data By Offset
AC Read Freeze Frame
AD Read Freeze Frame By DTC
AE Read DTC
AF Clear DTC

B0 Input Output Control By Offset
B1 Input Output Control By Identifier
B2 Control Routine By Offset 
B4 Define Read Write ECU data 
B8 Write Data Block By Offset 
B9 Read Data Block By Offset 
BA Write Data Block By Address
BB Read Data Block By Address 


And here's the list of all modules that were queried and identified on Volvo S80 MY02.
CAN diag Id    ID  Description 
00 80 00 03 :: 40  CEM, Central Electronic Module 
                   (also answers queries related to CPM(heater)
00 80 00 09 :: 51  DIM, Driver Information Module
00 80 08 01 :: 48  SWM, Steering Wheel Module
00 80 10 01 :: 29  CCM, Climate Control Module
00 80 00 11 :: 43  DDM, Driver Door Module
00 80 00 81 :: 45  PDM, Passenger Door Module
00 80 01 01 :: 2e  PSM, Power Seat Module
00 80 04 01 :: 46  REM, Rear Electronic Module
00 80 02 01 :: 58  SRS, Air bag
00 80 20 01 :: 47  UEM, Upper Electronic Module
00 80 00 05 :: 60  AUM, Audio Module
00 80 00 21 :: 64  PHM, Phone Module

These module were queried but didn't reply:
ID  Description
50  CEM, Central Electronic Module (Hi-speed interface)
01  BCM, Break Control Module (hi-speed network)
52  AEM, Accessory Electronic Module 
11  ECM, Engine Control Module (hi-speed network)
28  SAS, Steering Angle Sensor (hi-speed network)
6e  TCM, Transmission Control Module (hi-speed network)
62  RTI, Road Traffic Information module



And here's the sweet sight of hard reverse engineering work coming finally to fruition! Only coolant water temp and heater work status are being correctly queried though. Few software glitches still remain, but I don't care about that for now, since the thing I've been hunting for past few weeks has been now identified! Yes, the command for starting the heater :)

Turn on the diesel heater:
00 0f ff fe | cf 40 b1 5f 3b 01 01 84 
And the reply:
00 80 00 03 | cc 40 f1 5f 3b 00 00 00 


Turn off diesel heater:
00 0f ff fe | cf 40 b1 5f 3b 01 01 80 
Reply:
00 80 00 03 | cc 40 f1 5f 3b 00 00 00 


Now, this seems weird, since I had already tried this command before and it didn't work! It is one of the possible permutations of the message I was advised to try earlier by Swedish hackers (thanks again guys!), and I'm quite sure I tried this one before. There are few possible explanations:

1) I somehow managed to screw up sending the message using ELM327 (with its yucky AT command set), but now when using the MCP2515 based Arduino CAN shield the message is constructed correctly.
2)  ECU needs something else in addition to the command message itself. When looking at the message log, I see VIDA sending the following message every 1-5 seconds:
00 0f ff fe | d8 00 00 00 00 00 00 00
Could this be some kind of keep alive message needed by ECU?

Also VIDA keeps querying following stats every 3-4 seconds and their presence could be necesssary (although unlikely):

Cmd:   00 0f ff fe | cd 40 a6 1a 04 01 00 00
Reply: 00 80 00 03 | cd 40 e6 1a 04 1e 00 00 
The 6th databyte of reply seems to coincide with ignition key lock status:
1e = ignition II, 1d=radio (ignition I), 1c=off, 18=key out

Cmd:   00 0f ff fe | cd 40 a6 1a 02 01 00 00 
Reply  00 80 00 03 | cd 40 e6 1a 02 60 00 00 
The sixth databyte of reply fluctuates between 5d and 62, and could be the battery voltage. If we assume bits 0-2 consist of fractional part and bits 3-8 the integer part, then the values here would be interpreted as 11.625 and 12.25, and would fit well in our hypothesis. Actually a battery charger was connected during testing, so voltage over 12 volts would not be strange here.

VIDA needs the key to be in ignition II position in order to launch the heater section, but I did try switching the key position and it didn't have any effect on the result itself: Heater can be turned on with diagnostic command even when key is not in the keylock! This is actually quite a relief - spoofing the keylock position in the remote heater starter would require quite a bit of more work, but luckily this doesn't seem to be needed. However what is little bit alarming, is that any indication on the heater status is NOT shown on DIM, nor does the manual on/off functionality on the control stalk work when turning on the heater using this diagnostic command. Thus I will have to put some other kind of stop functionality and warning system in place when designing the box.

Still this isn't a fully functional J2534 device yet: It doesn't support ISO9141 or any other kind of protocols apart from CAN and ISO 15765, nor does it work when connecting it to OBD port, since it's missing the K-line initialization and keep-alive messaging to keep the diagnostic relay open on CAN bus pins. Maybe I will add some more functionality later, but for now, I'm quite happy with the results that I got. Also, no more Win32 programming for a while :)