Vida CEM swapping

[prometey1982]

I have progressed further in developing the Windows J2534 python tool usng the Mongoose JLR clone drivers. I have with reverse engineering figured out it only supports CAN_XON_XOFF_PS(or ISO15765) protocol aka 0x800A(according to github) from the J2534-2 API spec, provide anything else and it wiill error out with 0xA error code.
The Mongoose driver reverse engineering was terrible, it uses try catch exceptions, stack canaries(VS stuff) and every C++ bell and whistle, everything is interspersed with unwinds and whatnot.

Oh yeah I also found out Python still produce x86(32-bit) packages and binaries. Meaning I did away with the wrapper/glue bridge for 64-bit drivers.
I am on error 0x13(ERROR_PIN_INVALID) because of 0 flags for the protocol, which I will take care off soon.

You just need setup right pins for second channel
https://github.com/prometey1982/VolvoTo ... l.cpp#L230

[dikidera]

Thanks prometey. It seems like a simple import of PassthruGetLastError also solved a lot of issues., the DLL reports the exact issue now..

[dikidera]

Despite not touching anything related to 3-4 upshift, I have developed a harsher upshift. For 2-3 I have increase the shift time to almost double to get more smoothness, but in the process of doing so, there is a slight flare but not in all conditions. So instead I plan to reduce shift times to less than the original in effect making the shifts quicker.

I have also done some drains and fills with very small quantities of ATF, like 2 liters so far, no effect yet. But I will do more, this time only original Volvo fluid, I will do 10l, but because it is expensive, I will accumulate over time.

In the process of reverse engineering the tcm shift logic, I have discovered I think the ramp rate parameter, so far it is dimensionless. This also required me to further my understanding of the pressure control logic.
The ramp rate parameter is deferred to the logic that actually calculates current and then duty cycle, that logic is an interrupt handler called every few ms. This is in contrast to my belief that the shift functions responsible for fill time and clutch control also factored in ramp rate.

The ramp rate is a combination of static parameters, feedback from already dispatched and applied pressures, a further transformation from static maps related to temperature(these maps decrease before further being processed in the main interrupt handlers for the solenoids. It is a dynamic value but has a lower limit of 1500 which I cannot figure out if its percentage, if its pressure per X ms.

Example: Minimum ramp rate = 1500. 1500 / 10 = 150 * <value from temp map> which is say 463 for 0C / 1000 = 69; 5200(gf cm2 max pressure perhaps or something else) * 100 / 69 = 7536, 5200 could be anything, I always labeled it as the max possible lube pressure supplied from SLT for SLS but these were early labels. As temp goes up, the computed value decreases and approaches 5200(but ramp rate is dynamically calculated).

This value is then passed on to the interrupt handler along the target pressure. From then we have an interesting thing. We have another table with maximum pressures that more clearly show the actual max pressure to the clutch that SLS can supply, or so I had labeled it.

So it becomes 17333(246 psi) * 1000 / 7536 = 2300 and 2300 is compared to the target pressure for part of the slope and I am guessing gets integrated several times. The target pressure is a complex value, not statically derived and only valid for the first 3 parts of the slope, and there are 5 slopes in total.
Adaptations modify only the first slope which is more directly responsible for whether we have flare or not.

[dikidera]

For a while now these pressure..there was just something that did not make sense. If the TCM commands 122 psi hold pressure, a static parameter...well that is too low, but according to the internet, at WOT at the clutches we should get up to 287 psi at 80 psi main line pressure

So I guess here we have boost valves/pressure regulator valves affecting these pressures? At 80 psi main line, WOT hold pressure is 287 psi which equals a ~3.6x boost.But at idle 5 psi main line, at high temps clutch pressure could be 73-89 signifying a greater boost of more than 16x.There seems to be a non-linear boost factor.

If we assume at max line pressure of 80 psi that our boost is 3.6, it makes sense for some calculations. A static clutch value of 122.6 psi gets normalized to say max line pressure, in code that is 74 psi for SLT, SLS but 79.7 for SLU. If we have a boost factor of 3.6, then if SLT=MAX, 74 * 3.6 = 266.4 psi and 79.7*3.6=~287 psi. Too easy for this to be the answer, and other things dont make sense.

The math doesn't always check out, cause I routinely have a main line much lower than 74 psi when driving calmly, but SLS can be 62, depending on whatever was computed from maps. It seems like the variables from the valve body design are quite necessary to compute actual pressures here.

[vladlenas]

Hi, I have CEM "brick" HW-PN 08688434. Should I look for the exact same one for the clone? Or will any "brick" from 1999-2004 work?

[porcupine7655]

I just want to send Thanks to all in this thread. It is very valuable and give me a quick boost start to read out information from my ECU, V70 2006 BiFuel. Denso ecu wuth a sh7055 cpu.

I started off by the simple scripts and code dikidera provided. They run successful and was able to read out flash.
Then I started to think of what can be done. Wanted to be able to run some kind of debugger. JTag is not possible to use on this cpu, sh7055, so that was not a way to go. I noticed that Lauterbach had a rommonitor together with their eeprom simulator (i have one) but I was not in mood to replace the flash with an adapter. I then found out that they also had possibility to run over serial port. Some requirements is that it is needed to download the rom monitor code to target and get it running. There we had the dikidera tool.
Was able to get it down, but there was a lot of places where toggling the external watchdog pin is needed. Is there a solution that not require the toggling? That I don't know but I noticed that the pin have someting called Pulse on it. Found out that can be used to toggle the pin from hw timer. Was quite easy to do, only some registers needed to be set.

Code: Select all

	// Ext watchdog is connected to PB15 and is also PULS5
	PBCRH |= 0x4000; // PB15 to Puls5
	PBIOR |= 0x8000; // PB15 Output
	TIOR11 = 0x11;   // IOA and IOB, High on match
	GR11A = 0x0000;  // Timer value to set pin low
	GR11B = 0x8000;  // Timer value to set pin high
	PSCR1 = 0x01;    // Prescaler
	TCR11 = 0x01;    // phi/2 clock
	POPCR |= 0x2020; // Puls5 pin set and reset enable
	TSTR3 |= 0x01;   // Enable Timer 11 (Connected to Advanced Pulse Controller (APC)

Success. With only this code I can loop infinity and not do anything. Don't get any reset.

Next step was to get the rom monitor running with this. I have it up and running so far that I can load in code into ram from the Trace32 and run it, single step, set breakpoints, look at variables etc.
It is also possible to execute code that is in flash. Only drawback is that I can only set one breakpoint. The limit is that User Break Controller inside the cpu only have one.
I have still not added the rommonitor to the flash image. It is possible to do. It is also needed to change some of the vectors in the interrupt vector table so rom monitor code can take control of cpu when it is running. Just now I create a new in ram and point on that.

Noticed now that I don't have any source in that picture, just assembler. There is no problem to have source debugging if you have a debug file. If building small parts of own code you have and can do source level debugging on that parts.

Only one serial port is needed, rx, tx and ground. In picture I have also added a connector to the AUD port.

DSC_2665-small.jpg (122.13 KiB) Viewed 1807 times

Do anyone know if any of the 4 serial ports is accessible on in the big connector? Just now I have soldered them directly on the cpu pins.

[dikidera]

Very nice. I am glad that my work especially on Bifuel ECM has helped someone and even furthered the work. Further in the thread you will find an idb file with over 100 and more variables named(mainly from DHA and VIDA) but you will also find many more variables not named from DHA or VIDA but myself which took 1.5 years of constant reverse engineering.

Especially...the CNG/LPG maps for the stepper motor.

User Break Controller also had address masks. One can write a special vector with memory addresses(small list to be fast) and you can then use more. At least in theory, never tested in practice.

I would be very happy for a dump of that 2008 updated ECM, and if you have, an ETM dump too.

[porcupine7655]

You are correct that the UBC can handle masks. Lauterbach have support for it as well. If you set a range breakpoint it calculates the mask/address needed to cover the range you specified and configure UBC.
If then execution hits the mask range, but not within breakpoint range it just starts execution again. It will be a "short" time when user code is not executing but mostly when running with a debugger that doesn't matter.

See this example. I have setup a range from 9010--9017. In the code window we see a small read dotted bar between 900e--9016. That is the mask range that the UBC breakpoint covers.
I also have one more breakpoint, 901E. Now I'm executing from RAM so it can set that as a soft breakpoint (eg change the instruction to brk)

Here I also have a mixed view in source window e.g. show both my source and the asm code that it belongs to.

[porcupine7655]

I would be very happy for a dump of that 2008 updated ECM, and if you have, an ETM dump too.

Here is the dump from the ecu's I have. Have not dumped the ETM yet. To long thread, is there any tool to do that out there?
The spare files is from a ecu I got from ebay, other one is the one in my car. Have not dumped the internal cpu flash from that one yet.

[dikidera]

In the DUMP look for sequence F00D - this is the DTC for the pressure sensor located on the reducer. I have not yet found a way to code them out, because I spent almost no time on DTC disabling.