Vida CEM swapping

[Treur]

Now I'm trying to figure out how to write a J2534 API, and it's quite a problematic task, since I write in C#. I tried to understand Olaf's API code, but about 80% of it is not implemented and somehow I need to switch from a serial port to pure USB. In parallel, we are trying to port cracker to launch it on command, and give the application the execution status.

[dikidera]

COM ports on Windows are slow. Back in the day, 11 years ago I ported a bitcoin miner that didn't seem to want to work with libusb under Windows, to use COM ports, the speeds were extremely low as the miner couldnt report to Windows fast enough to report work or request new one. The fix was a one line change to libusb code to make it discover Intel USB3 hubs which made my work obsolete.

But yeah you could try and use libusb under Windows.

I have a question to you guys. I seem to remember that CAN ids have arbitration and the CAN id with the lowest number has the highest priority. Now that we know how CAN ids are calculated, can we not modify the diagnostic response ID (0x1200021) to be something with a lower number(higher than the can id for regular streaming data though) and get faster data response to improve sample rate?

[regula]

Thank you! Sirloin's one_pass branch did the trick and pin was found successfully and fast.

It looks ugly, i know, but wires are not touching each other, everything is soldered, copper wires are used, CAN wires to OBD are twisted, quality 12V->5V step-down converter is used for sufficient power, nothing is ordered from Ali and are bought from local electronic shop.
Still only the [0] byte is found with 100% consistency, [1] and [2] are always different.

Transceivers still can be fake.

Things to try:

- set clock rate to 180 MHz
- sirloin's one_pass branch: https://github.com/cmolson/volvo-cem-cr ... e/one_pass
- cem_freq_align branch: https://github.com/vtl/volvo-cem-cracke ... freq_align

[vtl]

Thank you! Sirloin's one_pass branch did the trick and pin was found successfully and fast.

Nice, congrats I wish it worked for every CEM.

[dikidera]

Do you guys think that this value from the formula below is the variation in revs?



Here is a better representation

h142_gbr = ((CurrentEngineRPM - PreviousEngineRPM) * 100 * 410 + Previous_h142_gbr * 9590) / 10000

I am not sure but it could be the dN variable, aka Variation in revs?


Well after a lot of logging I have these graphs.



You can see the distinct line of the curve as shown in the example above, but with the lack of sample rate it looks more choppy. The green line is the engagement pressure, the dotted is the torque limit request, which happens during the window known as 'shift time' The black and orange line are the same, one is current, the other is it's respective pressure, showing the disengagement. But the curve is still quite different than the time charts, it seems to rise more gently than the patent curve suggests.
I'll be honest, three solenoids controlling this many elements makes my brain hurt as one solenoid controls more than one aspect depending on which gear we are shifting to leading to them spiking in places because it's time for them to do something else..

On the green line, just after the big drop is a small peak which is PS1 part of PA, aka the Fill time, this is the time where the clutch circuit is being filled, afterwards below the dash line, is the area where shift time occurs.

[dikidera]

I have identified only one function, I have named return_time_compensated_value which includes logic that differs for each gear up or down, the only one that contains logic where time-compensation is done(as mentioned in the patents) , uses input shaft rev variation AND contains a check for two flags from the TCM configuration block which directly affects how this time-compensated value is used. The TCM Configuration block is one where all the relevant params are defined, e.g Slip Lockup, Neutral Control and other things I've yet to identify.

Based on these two flags, the relevant code executes two different blocks of code, 99% similar but with some slight differences. Something related to negative values, not just that, but also two versions of the same function with different map values.. Additionally the entire function has several maps for each gear, that could be related to fill time or shift time, maybe both.

I shall first start by writing a new configuration block disabling the two flags one by one. But this could be it, a fill time map or several.

The function itself takes three arguments, arg 1 is 1 for upshift, or for 2 for downshift and they prepare the various tables, or 3 means we are done and we are ready to use this data to compute the final value given to the solenoids(mostly). arg 2 is unknown but it's an index into specific tables elsewhere. arg3 simply bypasses a piece of logic from a few maps and caps those values to a single value of 100.

[dwappertam]

I don't have the equipment to extract a bin file.

You probably do. It only needs a USB-serial converter (the one with RX/TX lines). T5Luke taught me how to read/write Renesas flash with such adapter and m16c-flasher.de software.

Does that mean i can get the bin file on the rx tx lines of the mcu instead using the BKG method?
Thanks fot all source of information on my quest
Pegelaar!

[rkam]

The Bacground Debug Method is using rx and tx lines on the MCU, So it is basically the same, just different software on the computer.

[dikidera]

I guess we had a little miscommunication with our user over there due to the language barrier.

[Treur]

I guess we had a little miscommunication with our user over there due to the language barrier.

There are no barriers, the main thing is the desire to understand each other.