• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Ford CANbus modules wake-up

Diver300

Well-Known Member
Does anyone know how the CANbus systems on Ford cars control the wake-sleep of the electronic modules?

Some modules on cars have no connections to the rest of the car other than a permanent 12 V supply and CAN, so they have to have some way to agree to go to sleep, in order to take just a few microamps, and to wake up to have the speed of response that they will need when operating.

I've seen how this works on Landrovers and Jaguar cars. The CANbus message IDs in the range 0x500 - 0x5FF are used to keep the bus awake and when those cease, each module stops transmitting, waits a second or so for any more messages in that range, and shuts down.

I think it's quite likely that Ford use something similar, but I wonder if anyone here knows for sure.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
Likely the same on Fords.
There is a lot of overlap between Ford and Jaguar / Land Rover, as Ford owned them for some time..

They definitely all used the same "VCM II" diagnostic interface as Fords for some years & I think Jaguar and Land Rover may still use the same Ford unit?
(Mazda also use that, they have a lot of technology cross-over with Ford as well).

I have a VCM II for my Ford, but not the JLR software.
 

Diver300

Well-Known Member
I agree that there are many similarities. The specific question is about the wakeup messages.

CANbus has several types of message. I think that the types are generally grouped into different ranges of IDs. There are the everyday messages, saying what the car is doing, like speed, engine speed, temperatures, accelerations etc. There are the event messages, like button pressed and certain alerts. There are the configuration messages, for stuff that doesn't change, like fuel type, LHD or RHD, number of doors etc. There are the diagnostic messages, for reading the DTCs, which is what is often read through the diagnostic interface, but in fact those signals are only present when codes are being read. These have higher number, so lower priority, IDs.

As well as all of those, there are the messages that I am looking at, which keep the modules awake or let them go to sleep to save power.
 

pyrocrazy130

New Member
I am interested in the wake up messages as well. I upgraded the power seats in my truck and the new Driver Seat Module is connected to the medium speed bus. As you said before there is only one Hot At All Times circuit that powers the module, according to the donor trucks wiring diagram. So i would like to create a module that will send the wake up messages when the Hot In Run circuit changes state. I purchased a 2ch CAN interface for a raspi and i have access to a functional truck of the same year as the donor truck. I am new to decoding these signals but I would be glad to give you some CAN dumps or other information. There is very little information on these systems so i would be glad to help out.
 

Diver300

Well-Known Member
Would you be able to get a log of the CANbus from the functional truck? If you can get a log of CAN bus waking up, and one of it shutting down, that would probably give a very good idea as to what the wake-up signals are.
 

pyrocrazy130

New Member
Yeah, I will let you know when I get the logs.

Quick update on the DSM, I finished making the adapter to connect the new wiring harness to the old and the DSM allows the seats to move without CAN communication. However I was not able to get the seat memory function to work. The old module(non-CAN) seemed to store the position data in itself, I assume the new module does the same. The old module also directly controlled the pedal position where as the new module communicates with the steering column module to command the pedal position. There is also an audible tone that is heard when setting the seat memory position on the new system which I believe is also commanded over CAN. Maybe there is an acknowledgement message sent by another module to allow the memory to be set. There was a feature that changed seat position based on 2 different keys used in the ignition, not sure if this feature was equipped in the donor truck but I suspect I can't get the memory functions to work because I don't have the correct communication to the module yet.

I am working on the A/C controls as well. I hooked up power to the module and it did nothing. So that module must need the wake up commands. Now that my seats move, even though they don't have memory, I'm going to make the A/C controls my primary focus.

I'll record separate sessions, concentrating on specific modules. Any guidance would be welcome since I am new to CAN bus sniffing.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
From my experience with Ford control modules, anything with any complexity may need programming to the vehicle VIN before it functions in a different vehicle...

Whilst that makes sense for security-related parts so the immobiliser cannot be simply bypassed - they also apply it to completely irrelevant items such as the Bluetooth audio module.

I'd not be at all surprised if it also applies to climate control, power seats and any other optional or "luxury" item, to try and prevent DIY replacement or upgrades.
 

Diver300

Well-Known Member
If you are reading the CANbus, make sure that your testing device isn't sending anything. Reading DTCs means that they need to be requesting data, so if that is happening, the car will stay awake.

Your log will read every module that is on the CANbus. The interesting things are working out which ID comes from which module and what those IDs mean.

If you have a module from a donor car and the VIN number is need, and you are simulating the CANbus using a Raspberry PI, you can also fake the VIN number on the CAN so that the module will continue to work.
 

Diver300

Well-Known Member
From my experience with Ford control modules, anything with any complexity may need programming to the vehicle VIN before it functions in a different vehicle...

Whilst that makes sense for security-related parts so the immobiliser cannot be simply bypassed - they also apply it to completely irrelevant items such as the Bluetooth audio module.

I'd not be at all surprised if it also applies to climate control, power seats and any other optional or "luxury" item, to try and prevent DIY replacement or upgrades.
There are two levels with programming the VIN. As you say, some modules are secured to the VIN and will only work when that matches. As you say, for some things that makes a lot of sense, for security or calibration reasons.

However, in my experience of the car industry, most modules are programmed with the VIN only as an electronic security marking. The modules can learn the VIN number of the car that they are on when told to do so, but only once. That can never be changed without completely reprogramming the processor, which can't be done over CAN. It would need the module opening and JTAG or similar to be used. The VIN becomes a fixed item, like the serial number. The stored VIN on most modules, like the serial number of the module, is just that, a number. The stored VIN in modules like this has no effect on the operation in a car, whether or not the VIN transmitted on the CANbus matches.

That is only done to make changing the identity of a car more difficult. All the modules can have the stored VIN read at any time, so if a car is cloned, and the master module with the VIN is changed or reprogrammed, and the physical VIN numbers changed, all the other module would have to be changed in order to hide the old identity. The idea is to make changing a car's identity cost more than buying a new one.

Of course, the technicians at the dealers will tell you that the module has to be programmed with the VIN, because they don't see any difference whether the module would work without programming or not. When they change a module, they plug in the diagnostic computer, it does what it needs to, and the VIN can be read from the new module. The technicians won't ever try an unprogrammed module, and even if it did work, they couldn't be sure that it would work in all conditions. All main dealer repairs are done with new parts, so it make no difference if a second-hand one would be fine, as they will never use it anyhow.

For the owner, programming of that type of module isn't needed. If it's a second-hand module, the VIN can't be reprogrammed, but that won't make any difference. If it's a new module, it will just read out a blank if the VIN is ever read. Either way, it will only be read if the car is suspected of being cloned, and one or two modules, out of 20 or more, showing no VIN or the wrong VIN is just evidence of repair not evidence of the entire car being cloned.
 

rjenkinsgb

Well-Known Member
Most Helpful Member
The modules can learn the VIN number of the car that they are on when told to do so, but only once. That can never be changed without completely reprogramming the processor, which can't be done over CAN.
From my experience with Ford modules, the Ford IDS system with the Bosch VMC II interface unit can reprogram used ones via the OBDII port; I've done it..

Edit -
And functionally, such as the Bluetooth module will _not_ work with a vehicle without the VIN programmed to match!

That's not just ID, it's to prevent DIY changes or repairs.
 
Last edited:

Diver300

Well-Known Member
From my experience with Ford modules, the Ford IDS system with the Bosch VMC II interface unit can reprogram used ones via the OBDII port; I've done it..

Edit -
And functionally, such as the Bluetooth module will _not_ work with a vehicle without the VIN programmed to match!

That's not just ID, it's to prevent DIY changes or repairs.
I agree that manufacturers are often using VIN coding to prevent DIY changes.

However, there can also be generic modules that need programming for the details of what is on the car. There might be a door module that fits various cars, each with different window characteristics, so the calibration is specific to a model, a model year, number of doors, hand of drive, and maybe even market that the car is used in. It saves a lot of spares holding to have one type of module that will do all the possible combinations, and just receives a calibration when it is fitted.

I don't think that module can generally be totally reprogrammed. In my experience there is always a primary bootloader, and some data, for instance the serial number of the module, that will not be accessible via CAN. The main application and any calibration etc will be programmable

I've come across modules that need a calibration specific to the application, that is allowed to be reprogrammed many times, while having a VIN storage that is only allowed to run once.
 

Latest threads

EE World Online Articles

Loading

 
Top