Vida CEM swapping

[nikemen]

No common ground between OBD connector and Teensy? The original schematic has it:

You're right. I don't know why the PCB hasn't that. I'll try bridging Teensy's pin 1 to OBD's 5.

[dikidera]

Constant reflashing will be hassle for certain things and I wonder if it isn't possible to add some detours to certain functions to modify critical constants.

Or perhaps use the User Break Controller to intercept certain memory addresses and overwrite the fetched data, creating an easily programmable area to modify certain data. We write a small kernel that resides in unused memory in the FLASH region.

The only issue I see there is latency and of course the limits of the UBC itself.

[Volvisti]

Hello, i managed to download the flash from my CEM (Volvo C30 2007), now i am on the hunt for info on how to change the car config? i searched the thread, but couldn't find anything, can someone please point me in the right direction? seems like i am either blind or there is no info? thanks!

[wxp73]

can someone please point me in the right direction?

From here: viewtopic.php?p=609357#p609357

[Volvisti]

Hello, i tried that application from luke, but it somehow only shows garbage. i checked the flash data, could find my vin number though. so the data seems to be ok.

[matija0610]

paste the file here and say what you need to change

[nikemen]

No common ground between OBD connector and Teensy? The original schematic has it:

I added the common ground, but no change, there is still no connection to the car.
Then I took a look at the repository again, and I found a schematic for the use of Bosch CF160 transceivers: no common ground nor any resistor there... so my setup is apparently OK, I can't imagine where the problem comes from.

[dikidera]

I just want to let people know, that sometimes DHA can be wrong. I've discovered a few variables that are wrong, missing or with wrong factors. It takes quite a lot of reverse engineering to get to the point where you can see these mistakes.

The other subject I want to touch on is again the transmission. Our 5-speed transmissions are driven by algorithms, models which:
A) Were developed in the 90s and are not as advanced
B) Expect that the condition of the gearbox will be immaculate the whole time. Perfect TC clutch, perfect friction plates. Non-sticking solenoids.
C) Approximate many physical phenomena without measuring most of them.

Because these algorithms were developed a time where compute power was not that great, the algorithms are sometimes very simple and not that accurate. I don't claim to understand them. This is why these gearboxes die all of a sudden and had no codes prior.

On the other hand we have the 6-speed TF80SC which features entirely different algorithms. The code is denser(by a factor of 4 at least), uses a lot of floating point math(the 5-speed does not) as such it probably has a better approximation of various physical phenomena, torque transfer etc. More is not always better, but in this case it probably is. I expect the 6-speed to be more durable and resist wear.

The adaptation algorithm for the 5-speed is very "simple", I am speaking from memory, but it's something along the lines of a static table of oil temp regions and gears. The oil temp regions are -15, 0, 15, 40, 65 and 110 if I remember correctly. Then these tables have a value between 0 and 4.

And depending on this value, the adaptation of one temp region and gear is added with that from another.

Now because there is no finer granularity here, when the transmission adapts a shift say at 100c, it will use that adaptive value at 65c because they are both of the same temp region, because, again, no finer granularity. What about that table and summation of the adaptations? It's static and not very adaptive.

The adaptations are also not grouped by RPM, no such concept.

Finally, the TCM firmware assumes that when it commands 70 psi of pressure for main lube, that it will in fact be 70 psi, but any sticking solenoids, pressure loss from internal leaks or not as good oil characteristics, it can all go downhill from there.

[dikidera]

I think I found a bug, but not sure



Why set the flag to 1 but then immediately overwrite it? It could potentially be read as 1 IF an interrupt is generated at just the right time but 12 instructions at 1-2 clock cycles, doesn't very plausible.

The code that reads this flag is an interrupt handler and may or may not be detecting a revolution change. And this flag determines which code path is executed in the handler. By always setting it to 0 the code path may not be executed.

[vtl]

I think I found a bug, but not sure



Why set the flag to 1 but then immediately overwrite it? It could potentially be read as 1 IF an interrupt is generated at just the right time but 12 instructions at 1-2 clock cycles, doesn't very plausible.

The code that reads this flag is an interrupt handler and may or may not be detecting a revolution change. And this flag determines which code path is executed in the handler. By always setting it to 0 the code path may not be executed.

Is it op src dst format or dst src? Also what does # and @ mean? # looks like an immediate, @ is a reference? It looks like a code typically generated by a very old gcc, 2.x or 3.x, before ~4.4 when it has got a new static single assignment optimizer.