I read it as "instead of".
My reply doesn't make any sense if not.
Vida CEM swapping
-
dikidera
- Posts: 1304
- Joined: 15 August 2022
- Year and Model: S60 2005
- Location: Galaxy far far away
- Has thanked: 67 times
- Been thanked: 175 times
I tested around 10 versions of my TCM map changes. I have to say, they did not have the result I expected, which was to reduce the bumps, odd shifting of sticky solenoids.
That being said I have more or less identified the main loop of the TCM, I know how it roughly executes things. I know which interrupts are called for the input shaft speed sensors and output shaft speed sensor(and how they average out the values to get an actual rev per minute as well particular logic which took me a while to understand, which was the bias towards the very old and the very new values(the weights). Based on the patents and the algorithm inside I have figured out what variation in revs(as well as input shaft variations) are.
I correlated a cluster of RAM addresses which are responsible for holding the intermediate to last pressures before they are sent out to the three linear solenoids. Each cluster of RAM addresses contains specific values in time, depending on the role of the three linear solenoids, which changes based on which gear it is. One cluster for instance shows pressures(more or less raw values) and in fact the entire Clutch Fill time + ramp rate + final clutch clamp pressure when shifting from 2nd to 3rd while the RAM address next to it is the disengagement side pressure(this disengagement side pressure is the one causing shift flaring when it's lower than it needs be or slow), but change role as say shifting from 3rd to 4th.
The cluster is huge but roughly follows this pattern.
PA - pressure engagement
PB - pressure disengagement
+ a small set of correction pressures related to the ramp rates fill times etc.
Actually it's mostly SLS and SLU doing the heavy lifting while SLT moderates the overall main supply pressures to SLS and SLU.
But we are visual creatures. Below is a graph of a shift from 2nd to 3rd(the bumpiest of all in any bad shifting AW55) with RAW pressures. These pressures are passed through a normalization function to convert a pressure to current via special calibration tables and then to a PWM signal duty cycle.

The image is self explanatory, except it contains pressures which have been smoothed(from tiny adjustments factors not shown) and temperature compensated. SLS is the entire Clutch Fill time + ramp rate(according to target shift time) with a final spike upwards(not correctly shown here because of graph) which is the clutch hold pressure at least for the moment of final engagement
Lets look at it from the point of view of the RAW values

The teal color line is the disengagement pressure, the red line is SLT supply pressure and the green-ish line is engagement pressure with the final spike I said, which in my case was 122.6 PSI of hold pressure before dropping to a more normal value.
And here is a more squished version showing something more outlined. Including the rpm drop as the gear ratio changes(this drop is the target speed) + the red perpendicular lines showing time.

That being said I have more or less identified the main loop of the TCM, I know how it roughly executes things. I know which interrupts are called for the input shaft speed sensors and output shaft speed sensor(and how they average out the values to get an actual rev per minute as well particular logic which took me a while to understand, which was the bias towards the very old and the very new values(the weights). Based on the patents and the algorithm inside I have figured out what variation in revs(as well as input shaft variations) are.
I correlated a cluster of RAM addresses which are responsible for holding the intermediate to last pressures before they are sent out to the three linear solenoids. Each cluster of RAM addresses contains specific values in time, depending on the role of the three linear solenoids, which changes based on which gear it is. One cluster for instance shows pressures(more or less raw values) and in fact the entire Clutch Fill time + ramp rate + final clutch clamp pressure when shifting from 2nd to 3rd while the RAM address next to it is the disengagement side pressure(this disengagement side pressure is the one causing shift flaring when it's lower than it needs be or slow), but change role as say shifting from 3rd to 4th.
The cluster is huge but roughly follows this pattern.
PA - pressure engagement
PB - pressure disengagement
+ a small set of correction pressures related to the ramp rates fill times etc.
Actually it's mostly SLS and SLU doing the heavy lifting while SLT moderates the overall main supply pressures to SLS and SLU.
But we are visual creatures. Below is a graph of a shift from 2nd to 3rd(the bumpiest of all in any bad shifting AW55) with RAW pressures. These pressures are passed through a normalization function to convert a pressure to current via special calibration tables and then to a PWM signal duty cycle.

The image is self explanatory, except it contains pressures which have been smoothed(from tiny adjustments factors not shown) and temperature compensated. SLS is the entire Clutch Fill time + ramp rate(according to target shift time) with a final spike upwards(not correctly shown here because of graph) which is the clutch hold pressure at least for the moment of final engagement
Lets look at it from the point of view of the RAW values

The teal color line is the disengagement pressure, the red line is SLT supply pressure and the green-ish line is engagement pressure with the final spike I said, which in my case was 122.6 PSI of hold pressure before dropping to a more normal value.
And here is a more squished version showing something more outlined. Including the rpm drop as the gear ratio changes(this drop is the target speed) + the red perpendicular lines showing time.

-
Yariy
- Posts: 41
- Joined: 1 July 2024
- Year and Model: XC90
- Location: Moskow
- Has thanked: 13 times
- Been thanked: 10 times
Hello. I have been studying CEMB until 2004. Does anyone know how Vida rewrites the configuration area when it is necessary to change the vehicle configuration? The configuration area of the 28f400 flash is the 8000 - 20000 hex addresses. This area contains identification data (8000), configuration
(8100), unknown to me are (8200) and (10000). To change the bytes in this area, you must first erase the entire area. You need to count it before erasing it. Identification data (8000) and configuration data (8100) can be read via CAN, but how can data be read at addresses (8200) and (10000) and what do they store? I have not found any functions using Ghidra that can transfer data from addresses (8200) and (10000). If anyone is interested, I'm attaching an incomplete CEMB schema and the Ghidra script (splitting the dump into blocks, assigning register names to addresses).
(8100), unknown to me are (8200) and (10000). To change the bytes in this area, you must first erase the entire area. You need to count it before erasing it. Identification data (8000) and configuration data (8100) can be read via CAN, but how can data be read at addresses (8200) and (10000) and what do they store? I have not found any functions using Ghidra that can transfer data from addresses (8200) and (10000). If anyone is interested, I'm attaching an incomplete CEMB schema and the Ghidra script (splitting the dump into blocks, assigning register names to addresses).
- Attachments
-
- MC68376_Volvo_CEMB creating blocks.rar
- (12.75 KiB) Downloaded 78 times
-
Schematic_CEMB_MC68376_2025-03-11.pdf- (189.17 KiB) Downloaded 111 times
-
dwappertam
- Posts: 9
- Joined: 2 January 2025
- Year and Model: 2001 S60 P2
- Location: On this planet
- Has thanked: 3 times
-
dikidera
- Posts: 1304
- Joined: 15 August 2022
- Year and Model: S60 2005
- Location: Galaxy far far away
- Has thanked: 67 times
- Been thanked: 175 times
I replaced my transmission but the new one is not much better than the old one, sadly. At times it shifts better, at times its like the old one.
So I decided I am experimenting. I think I found what I am considering to be the clutch fill pressures. But rather than reflashing the TCM I decided I will do fast ram patching.
I chose an almost arbitrary value and got this graph

The graph is mighty different from that one without RAM patching, we no longer have the nice characteristic curve, in fact there was supposed to be a drop to -17,78 psi(yes I know a negative value sounds counter-intuitive but it is how it works in the code) but here it's gone. I would say this RAM variable affects much more than I'd like and affected the curve too greatly. The black line underneath the green-ish one is the actual commanded pressures, we can see the curve is still alright, meaning that it is further pre-processed from the RAW value of the green line.
As for shifting, well...I can't say it was better, according to the logs however it was faster though I did not really feel that. The dashed line is the torque limit request, that one was usually there for a longer period of time, now reduced to around 150ms.
So I decided I am experimenting. I think I found what I am considering to be the clutch fill pressures. But rather than reflashing the TCM I decided I will do fast ram patching.
I chose an almost arbitrary value and got this graph

The graph is mighty different from that one without RAM patching, we no longer have the nice characteristic curve, in fact there was supposed to be a drop to -17,78 psi(yes I know a negative value sounds counter-intuitive but it is how it works in the code) but here it's gone. I would say this RAM variable affects much more than I'd like and affected the curve too greatly. The black line underneath the green-ish one is the actual commanded pressures, we can see the curve is still alright, meaning that it is further pre-processed from the RAW value of the green line.
As for shifting, well...I can't say it was better, according to the logs however it was faster though I did not really feel that. The dashed line is the torque limit request, that one was usually there for a longer period of time, now reduced to around 150ms.
-
dwappertam
- Posts: 9
- Joined: 2 January 2025
- Year and Model: 2001 S60 P2
- Location: On this planet
- Has thanked: 3 times
T5Luke wrote: ↑15 Sep 2022, 13:51 CEM Data Manager.jpg
I made this long ago for my self. It works, for me and i hope for anyone who needs it to copy his own CEM. For just changing config, better take the other tool and write only the config to your cem by dice...
viewtopic.php?t=85611&start=2270
The +5V over 1K resistor is only needed if you want to write complete cem, the bootloader is is in area 0x0 - 0x3FFF. Without pulling this point to +5V you cant erase or write this area. I took this resistor just for protection, today i don't use it anymore and put this pin directly to arduinos 5V pin. But be carefull if you pull it to gnd you will notice some smoke and your cem won't work anymore...
To read:
select port, click connect, click read complete, wait till all data runs through this window, it takes around 6min. When it stopped click save to file and you will get your bin.
To erase:
click on unlock write mode, and click on all erase blocks one after one on the right side to erase all areas on the new cem.
To write:
click on open binary, select the file you want to write, click write complete.
On arduino you need the firmware from ardubdm.bin, I lost my original sketch i have 0.9.6 here and i know i flashed 0.9.8 to my arduino. I should have it on some harddisk somewhere when i find it i will post here. But i was able to make a dump of my working arduino and you can flash this soft to your arduino by write.bat.
Edit write.bat to the matching port of your arduino:
COM.jpg
and run it to flash the correct firmare onto your arduino.
I know reading takes about 6mins and writing about 90mins and the gui doesnt update right by writing but it works and it is for free..
As always have fun with it and use or reuse this for your own projects.
I tried it last night , it did not show me any reading data not with the manager or aurduino and puttu, i started but hangs , i havr tried it with bdm pins and verified that the pins were correct, when i remove the pins and just start it with out the pins register ,by touching the pins .
When i put the pins back and start it same story hangtime. But wierd enough when i remove the bkgd pin it start to register some what data , just not right one and hangs after a minute or 2. I tried the same on my resently bought cem (same cem hw and soft.) it works for a second and hangs, ... Whqt can i do about it ... And why does it start to give wierd info when removing the bkgd pin .?
Stil i am thankfull for this method and hope that i will succeed someday.
Best regards.
-
vtl
- Posts: 4723
- Joined: 16 August 2012
- Year and Model: 2005 XC70
- Location: Boston
- Has thanked: 114 times
- Been thanked: 603 times
You are able to patch it in run time, because TCM copies the tables from slow flash to RAM?dikidera wrote: ↑17 Mar 2025, 01:32 I replaced my transmission but the new one is not much better than the old one, sadly. At times it shifts better, at times its like the old one.
So I decided I am experimenting. I think I found what I am considering to be the clutch fill pressures. But rather than reflashing the TCM I decided I will do fast ram patching.
I chose an almost arbitrary value and got this graph
The graph is mighty different from that one without RAM patching, we no longer have the nice characteristic curve, in fact there was supposed to be a drop to -17,78 psi(yes I know a negative value sounds counter-intuitive but it is how it works in the code) but here it's gone. I would say this RAM variable affects much more than I'd like and affected the curve too greatly. The black line underneath the green-ish one is the actual commanded pressures, we can see the curve is still alright, meaning that it is further pre-processed from the RAW value of the green line.
As for shifting, well...I can't say it was better, according to the logs however it was faster though I did not really feel that. The dashed line is the torque limit request, that one was usually there for a longer period of time, now reduced to around 150ms.
-
dikidera
- Posts: 1304
- Joined: 15 August 2022
- Year and Model: S60 2005
- Location: Galaxy far far away
- Has thanked: 67 times
- Been thanked: 175 times
I am able to patch it because the TCM executes the code in discrete steps per tick. E.g one iteration of main loop, it prepares the data from maps, then as it continues it reaches the code for CAN processing where my RAM patching CAN command is executed, in the next main loop iteration, it calls the same functions as before, but with different arguments, denoting the current step, and uses the prepared data from before. A single function can be called 4 or 5 times depending on however many steps it has to complete.vtl wrote: ↑21 Mar 2025, 11:06You are able to patch it in run time, because TCM copies the tables from slow flash to RAM?dikidera wrote: ↑17 Mar 2025, 01:32 I replaced my transmission but the new one is not much better than the old one, sadly. At times it shifts better, at times its like the old one.
So I decided I am experimenting. I think I found what I am considering to be the clutch fill pressures. But rather than reflashing the TCM I decided I will do fast ram patching.
I chose an almost arbitrary value and got this graph
The graph is mighty different from that one without RAM patching, we no longer have the nice characteristic curve, in fact there was supposed to be a drop to -17,78 psi(yes I know a negative value sounds counter-intuitive but it is how it works in the code) but here it's gone. I would say this RAM variable affects much more than I'd like and affected the curve too greatly. The black line underneath the green-ish one is the actual commanded pressures, we can see the curve is still alright, meaning that it is further pre-processed from the RAW value of the green line.
As for shifting, well...I can't say it was better, according to the logs however it was faster though I did not really feel that. The dashed line is the torque limit request, that one was usually there for a longer period of time, now reduced to around 150ms.
I am able to fast RAM patch because of this small peculiarity.
For instance the Clutch Fill function when upshifting is executed at least 3-4 times, with each execution further setting bit flags on which step it is. I thought the clutch fill function also controlled how long the hydraulic chamber is filled, but it seems to only control the fill pressure. When the function is called with a different argument to end fill phase is controlled by somewhere else in main loop.
Also, in my logging of commanded current vs feedback current, I have seen instances where the feedback current is much higher than the commanded one, for 100ms or so. Maybe this is the sticky solenoid ?
-
dikidera
- Posts: 1304
- Joined: 15 August 2022
- Year and Model: S60 2005
- Location: Galaxy far far away
- Has thanked: 67 times
- Been thanked: 175 times
Today I did some experiments.
I increased the clutch fill time from ~250 to 350ms for 2nd->3rd shift, oh boy did it not like that. Fairly violent shifts. While I have set a cap on torque reduction to 150nm, it felt like I went below 20 but the logs still show 150nm only. I cannot explain why this was, maybe increasing the clutch fill time caused it to partially engage, while the offgoing clutch was still engaged, basically having two clutches on at the same time, for a split moment.
And in other news, I have also discovered from my logs that once in a while, the feedback current of SLS solenoid differs wildly from commanded. Example is SLS commanded current of 765 milliAmps causes for a split second a feedback current of 1022 milliAmps. And since more current = less pressure, then 1.02 amps = 0 pressure for SLS. Somehow something is propelling the solenoid plunger backwards.
I increased the clutch fill time from ~250 to 350ms for 2nd->3rd shift, oh boy did it not like that. Fairly violent shifts. While I have set a cap on torque reduction to 150nm, it felt like I went below 20 but the logs still show 150nm only. I cannot explain why this was, maybe increasing the clutch fill time caused it to partially engage, while the offgoing clutch was still engaged, basically having two clutches on at the same time, for a split moment.
And in other news, I have also discovered from my logs that once in a while, the feedback current of SLS solenoid differs wildly from commanded. Example is SLS commanded current of 765 milliAmps causes for a split second a feedback current of 1022 milliAmps. And since more current = less pressure, then 1.02 amps = 0 pressure for SLS. Somehow something is propelling the solenoid plunger backwards.
-
- Similar Topics
- Replies
- Views
- Last post
-
- 1 Replies
- 6396 Views
-
Last post by RickHaleParker
-
- 5 Replies
- 8644 Views
-
Last post by forumoto






