Vida CEM swapping

[brobert]

It's interesting to issue the FF 86s manually and see what cadence is required to get through (using CanHacker or other CAN utility).
My bench CEM won't obey FF 86s unless I send the messages pretty fast (clicking away with the mouse).
I assume that it's due to bus contention as the CEM is a chatty unit.

For what it's worth, I always get an SRS DTC when I play in the car and issue FF 86 messages (via DiCE or the Teensy cracker).
VIDA seems to be the answer for clearing it but I read somewhere that these errors accumulate in the SRS module
There's also the issue of getting all the modules to resume normal operations (pulling the battery negative works but is always worrying).

B.R.

So it isn't just about sending the command and ensuring all modules have received it, it's about how fast it is sent? Is this why I got an SRS Airbag DTC?

My python code for RPI basically alternated between the buses and sent the FF 86 command for a second or two, spamming basically. This worked for me, but the SRS Airbag code got triggered and could not be easily cleared. Obviously python->socketcan->mcp2515->can bus is introducing a lot of latency.

As for knock off dice, some people have had no luck getting it to even work.

https://www.swedespeed.com/threads/conn ... st-8078413

[dikidera]

My car usually responds from the very first issuing of the FF86 command manually, however I did once experience an issue where it took 10 times of manually sending it but very fast, which was unexpected.

The SRS DTCs are particularly annoying, because not only do they appear, but with a red triangle and I had a tough time clearing them. There's also stern looks from my girlfriend on why the instrument cluster was lit like a christmas tree with a bunch of errors. This is why I am wary of trying out my custom tool on a friends' car.
In fact I am not sure if I managed to clear them as my car died due to unrelated circumstances.

I sent out CAN commands to the SRS, CEM, ECM, ABS and even DIM module to clear them. E.g C<x> 58 AF 11 for SRS, 40 AF 11 for CEM etc. And I remember this not working out well. The error is very persistent. Perhaps someone here knows why it's so difficult to clear and why it gets triggered so easily.

It's even more worrisome that you say they accumulate, so even we manage to clear it, a permanent one may appear and require say reprogramming of the SRS, ABS module?

[T5Luke]

You need to read the errors first to be able to clear

[dikidera]

Thanks for the information.

[brobert]

I need to stress that I'm not sure about the SRS module accumulating DTCs.
Perhaps the history of DTCs matters when it comes to a safety system?
The SRS module is the closest thing that we have to an aircraft black box recorder.
Anyway, I've read that once (mhhauto I think) so take it for what it's worth.

You should definitely keep your girlfriend away when playing with the car's electronics.
In my experience, it takes years to build a good impression and minutes to lose it!
ETA: My wife also maintains a permanent log of all my errors...

B.R.

My car usually responds from the very first issuing of the FF86 command manually, however I did once experience an issue where it took 10 times of manually sending it but very fast, which was unexpected.

The SRS DTCs are particularly annoying, because not only do they appear, but with a red triangle and I had a tough time clearing them. There's also stern looks from my girlfriend on why the instrument cluster was lit like a christmas tree with a bunch of errors. This is why I am wary of trying out my custom tool on a friends' car.
In fact I am not sure if I managed to clear them as my car died due to unrelated circumstances.

I sent out CAN commands to the SRS, CEM, ECM, ABS and even DIM module to clear them. E.g C<x> 58 AF 11 for SRS, 40 AF 11 for CEM etc. And I remember this not working out well. The error is very persistent. Perhaps someone here knows why it's so difficult to clear and why it gets triggered so easily.

It's even more worrisome that you say they accumulate, so even we manage to clear it, a permanent one may appear and require say reprogramming of the SRS, ABS module?

[dikidera]

Decided to rack my brain a bit more and here is what I found

ROM:0007D378 off_7D378: .long dword_19C8+4, 0xFFFFE400, unk_FFFF9766, sub_D6D0
ROM:0007D378 ! DATA XREF: sub_AFE0+A↑o
ROM:0007D378 ! sub_B030+A↑o ...
ROM:0007D378 .long sub_D514, sub_D19C, loc_D4AE, loc_D49C, sub_D2F0
ROM:0007D378 .long loc_D21A, loc_D814, locret_D808, sub_D4F2, loc_D28E
ROM:0007D378 .long loc_D4B8, loc_D4CA, loc_D4DC, sub_D4FC, loc_D20A
ROM:0007D378 .long loc_D212, 0xFF00FF, dword_7D370
ROM:0007D3D0 off_7D3D0: .long dword_19FC+0xC, 0xFFFFE600, unk_FFFF9769, sub_D6D0
ROM:0007D3D0 ! DATA XREF: sub_AFE0+14↑o
ROM:0007D3D0 ! sub_B030+14↑o ...
ROM:0007D3D0 .long sub_D514, sub_D19C, loc_D4AE, loc_D49C, sub_D2F0
ROM:0007D3D0 .long loc_D21A, loc_D814, locret_D808, sub_D4F2, loc_D28E
ROM:0007D3D0 .long loc_D4B8, loc_D4CA, loc_D4DC, sub_D4FC, loc_D20A
ROM:0007D3D0 .long loc_D212, 0xFF00FF, dword_7D370+4, poweron, poweron

When I see where 7D378 is referenced, I see the following code

mov.l #off_7D378, r2
mov.l r2, @r15
mov.l @(0x14,r2), r3
jsr @r3
mov r2, r4

7D378 + 0x14 leads me to a subroutine

mov.l @(4,r4), r5
mov #0, r4
mov r5, r6
add #1, r6
mov.b @r6, r0
extu.b r0, r0
tst #2, r0
bt/s loc_D1B0
mov #1, r7

r4 + 4 = 7D378 + 4 = FFFFE400 <--- HCAN0 start.

mov.w #0x80, r6
mov #0x19, r0
mov.b @(r0,r5), r3
extu.b r3, r3
cmp/ge r6, r3

0x80 = 128. 0x19 + FFFFE400 = FFFFE419 = ERROR Counter TEC which yes, does contain values >=128 and so forth.

I don't want to draw definitive conclusions yet, but I may have found some opaque HCAN interface.

[xanthefin]

There is some funny business as SRS noted previously.. The triangle leds on DIM and SRS if there is any bad soldering can cause those fault codes where both claims "circuitry is broken". But in my case when went manually toggle it on off it worked after couple tries and ignition off back on (noticed SRS lights stayed actually on during cycle for some reasons..). And by toggling it on off it removed fault code too by itself. Later then it came back by itself. (fixed by soldering then after all).


Second part i take from my coworker whose lock for gas lid flap didn't work suddenly anymore but when he went to volvo dealer to diagnose and fix it.. they ended too manually toggle it on off and just claim "it works fine" and ever since been worked fine.

So my question.. do Volvo use in their code some flip flop desing? Like back to my SRS triangle on DIM module if SRS commands it on when its still on it notices it and says "its faulty!"?


For extra note of SRS modules.. if have 256 or 258 ending SRS box.. don't play too much with them as programming them is headache. Such corrupt masters when battery low.

[andrewgabler]

Accidentally posted a duplicate, sorry.

[andrewgabler]

Hi all, I am attempting to crack my CEM on the bench and I am running into issues getting the CEM CANBUS to turn on communicate with either my teensy and can transceivers or my arduino uno and canbus shield. My arduino sketch to log the canbus works fine through my cars OBD2 port, but when I hook it up to the CEM it reads nothing.

I have tried a number of different combinations of things.
SETUP
PIN 6 12v Ground
PIN 8 +12v
PIN 15 + 12v
PIN 16 + 12v
PIN 33 CAN Hs - H
PIN 48 CAN Hs - L
PIN 40 CAN Ls - H
PIN 55 CAN Ls - L

What am I missing to get the canbus network to wake up and at least be read from my canbus shield? Thanks!

[dikidera]

Just a thought, but 120 ohm terminator?