Vida CEM swapping

[vtl]

All-new CEM shouldn't have PIN set. It's either all 00s or all FFs.

[Scoloo]

All-new CEM shouldn't have PIN set. It's either all 00s or all FFs.

Thanks! Then I can read it with io without a problem.

[WhizzMan]

So, i have a brand new CEM H on the bench right now. With part number : 31394157 can i assume that there is no pass on it? If yes, can i read it directly with io terminal?

If not, i tried to read it with the cracker but no part number found.

If it is brand new, please read all possible chips out so we can "virginize" used ones. (assuming you are willing to share)

[oscilloscope]

So, i have a brand new CEM H on the bench right now. With part number : 31394157 can i assume that there is no pass on it? If yes, can i read it directly with io terminal?

If not, i tried to read it with the cracker but no part number found.

If it is brand new, please read all possible chips out so we can "virginize" used ones. (assuming you are willing to share)

Good idea

[Scoloo]

Offcourse i'm willing to share. Gonna read tommorow i think.

[Arty]

Hey, guys. I am new to this topic, so I want to ask you guys for more details. I have a 2006 Volvo S60. Let's say I get a pin code. How can I then change the configuration through the obd connector. I just want to flash cruise control and fog lights. I have re-read the whole forum thread but my English is very bad. I hope for your help. Thank you very much in advance

[dikidera]

Hey, guys. I am new to this topic, so I want to ask you guys for more details. I have a 2006 Volvo S60. Let's say I get a pin code. How can I then change the configuration through the obd connector. I just want to flash cruise control and fog lights. I have re-read the whole forum thread but my English is very bad. I hope for your help. Thank you very much in advance

A programmer. Or a Volvo supplied SBL. It cannot happen normally I believe. You need to dump CEM flash, change configuration, write back flash to CEM.

[Scoloo]

Here are the virgin files guys. CEM number is 31394157.

[dikidera]

I have been studying the code in Denso which is responsible for accepting dynamic record parameters and where the frames are built and how the messages are stored. I found where they create 8 separate what I can only describe as linked lists, The one for dynamic records is fairly small and thus if you request the dynamic records being sent too fast you will be met with a msg buffer full error. However this means the CAN msg buffers for dynamic records are not emptied fast enough through transmission. And with each parameters I request, I am dropping to something like 12hz logging rate from the usual 15.

Whenever we need to build a CAN message, we have a link list of particular size, separated into individuals regions/indexes.

So basically they do something like

curBuf = prev->next
nextBuf = curBuf->next
curBuf->next = nextBuf

At this point curBuf is taken out of the linked list, and data is added to it. A frame is built in a loop(when dispatching) but not within the same cycle they build one part of the frame, then I guess control is returned for other more important engine tasks, and then we return at some point to continue building the frame.

This is how these specific buffers, referenced by their index(does not equate to priority I believe) are created/initialized


The linked list beginning is stored in a global pointer D2CANMSGBuffer_pointer_array_810788, where the parameter to CAN_LinkedListInitialize in r4 which is the index to D2CANMSGBuffer_pointer_array_810788[index] = r7

And this is a piece of code where we add a parameter to our Dynamic Record of choice(0xAA)



And the actual request to read dynamic record



If the function returns 0xFFFFFFF this means all available buffers are full and a CAN error message of "Busy bus" is returned instead.

We know that since all available memory has been accounted for during linking process, we cannot extend the memory buffers for CAN, what we can attempt to do is find a way to transmit the messages faster to allow more samples per second for data logging

The function above also do not immediate build and send the data, instead, what happens is that we now store a send request perhaps stored in an entirely different queue of some sort, a message queue to be executed at a later time.

Basically all the operations from requesting, building and sending via CAN are not done immediately but are processed in steps/chunks at much later times, they basically have only a small time slice for each of these operations.

Addendum:
I found some suspicious variables which are some sort of counters.

One of those had the max value of 138D, which is 5005. Add in factor of 5005*262144/65535 we get the value 20,002 microseconds which is 20ms. This is about as long as each of my dynamic record frames takes to complete. I request 15 parameters and they are retrieved in 80ms, if we assume I got my full record in 4 can frames, that is 4*20ms = 80.

Although since I am not at the car I cannot see my live can frames. The problem here is i expected a cpu-bound counter that was precisely followed. Instead I am seeing a manually incremented counted that is compared to the value 138D. Of course it could end up being wrong, because you cannot possibly increment a counter manually to count a passing microsecond with a clock speed of 40mhz and so many instructions.

Addendum 2:

I don't think I can increase the speed, not without increasing the frequency of ALL CAN messages which may really saturate the bus. I noticed engine critial data in standard CAN stream are sent out at roughly the same frequency as my dynamic records.

[al1Volvo]

Hi,

Is there anybody here who have a dump from both MCU (flash and eeprom) of a P1 CEM ref 31327215 please ?
I erased the left chip while doing some test and didn't backed up it before ...
It is not my CAR CEM, just a bench testing CEM, so no drama if you don't have it.

From what I found for now, both MCU are masked 1L15Y MC9S12XDT384MAL, left one at 4MHz, right one at 8MHz.
I tried first to read it with OSBM and true time debugger from codewarrior but it erased the left one while unsecuring it. Then I bought a R270 programmer that could read both chip nicely.

Car configuration seems to be at @7C100 on chip2 (right).

Thanks for the help !