Opel 1.3 cdti ECU replacement - No communication with the controller

I have a problem with Opel Corsa D 1.3 cdti.
The engine driver was damaged - initially there was a problem with the injection control, then there was communication with the controller - it does not connect with the opcom and the letter F appears on the display of the board, so surely the communication, the power supply on the controller are checked and there are ok - 12V on pins 50 and 23 are ok, but there is no mass controlled by the ECU after turning the key (pin 80), which is the reason for the lack of 12V on pins 4.5 and 6 - probably it is not a matter of communication only, but maybe the processor has died ...

I bought a similar one from the same engine - of course I know that the numbers should match, the driver should be logged out etc. - but I bought it more out of curiosity, in order to compare with the damaged one and try to find the problem ..

As I'm curious, I tried to connect a new driver to the car, I expected no possibility to start the car due to differences in the pin / immobilizer, but there is still no communication with the driver, opcom does not connect, light "F" still present on the display - is it normal ? Is the purchased driver also damaged?

Maybe CIM is present in Corsie, as in Astra and Vectra, check it out. This is a steering wheel module, it comes off of many systems and often sits down.

The problem is that if the ECU is disconnected then I can connect to any module in the car.

After connecting the ECU, I cannot connect to any of the modules (including the ECU).

Question - this is a Corsa D, the module comes from Agila B with the same engine - can it matter?
Of course, again, I did not expect the car to start but in Corsue D and Agila B there is CAN, so I was hoping that maybe the addresses (in CAN NodeID) are the same for the control units in Opel cars .. Then I should be able to connect to the ECU from the OBD connector and read the error messages immo etc. ..

However, if there are actually other NodeIDs for various Opel models - which memory is this in? How did I compare the hardware side of both computers, came out that the processors, drivers are the same in both - is it possible to download the software from the original ECU by, for example, BDM to make the communication work?

What driver? EDC16?

Magneti Marelli. Give the controller to check, is it communicating on the table?

I gave the original (damaged) to check, a specialist familiar with this type of driver tried to connect for 3 hours and there was a problem .. Further attempts would involve considerable costs, so before I start spending thicker money I thought I would try to check some things myself - hence the idea replacing systems with a healthy controller designed for the same engine, but a twin model of the car ..

As for the new (used) driver, I haven't given it anywhere to check, because I was hoping to be able to connect from the OBD connector .. But as you can see a bad topic ..
And for this driver I bought for the purpose of replacing elements, hence my question at the beginning of the topic, because if I should connect to this bought driver and it fails, it means that something is wrong with it and replacing the elements does not make sense. .

As for the old, original driver, when turning off the ignition one driver heats up - L9132 (I suspect that he is responsible for power management), one minute after switching on the ignition is so hot that it's hard to touch.

In addition, I checked and both controllers have the same system responsible for CAN communication .. I would consider a problem with the connection - maybe a jumper between CAN H / L, but then communication would not be even when the ECU was full, and I connected them several times and each time same..

Probably the ECU purchased for testing is defective ..

Probably everyone who attaches to this car will be defective Power checked with a test tube on a fastened controller? Correct weight?

Power and mass checked - as I wrote at the beginning ..
But what puzzles me is the lack of communication with other modules, when this driver is plugged in - even if some ground or power supply is missing, the stuck controller should not block communication with other modules, right?

crsevolution wrote:

however I bought it out of curiosity more to compare it with the damaged one and try to find the problem ..

you bought a driver out of curiosity that costs over a thousand, you are wasteful.
On the table he goes to check in five minutes I just fix it and I have connected.

That's right, I bought a driver for comparison - it's the second one in principle, but the first (much cheaper) turned out to be of the older type and significantly different from my original.

Is this wasteful? I wouldn't call it that - to understand how something works and learn how to fix it, you have to bear some costs - I'm aware of it - and even if I spend 2x as much as my controller type bought with a specialist like you, it's worth it - let's say that I like to feel satisfaction.

What to check on the table I understand that you are writing about connecting KTaga and downloading the contents of mpc memory, eeprom maps?
If so, then this has nothing to do with my question in this topic, because even if I connect and download the memory content, the CAN module can still be released right?

I mean, should the ECU controller connect and "talk" to other modules in the car, even if it is not programmed for this particular car? The driver is from a different series - the original is 6o3.s7, the test is 6o2.w1 - once again I will point out that I know about differences in hardware and that 6o2.w1 will not go 100% after reprogramming, but I thought that at least to make a communication via OBD and this confirmation or denial I am looking for here - because if it actually does not walk it is a waste of my time and I have to buy something from the same series.

I do not sell drivers, I am able to check, repair as much as possible, upload content without opening it, etc. ... and if you put something under the cover, which is similar to the casing and you are surprised that it does not work, I wish good luck and perseverance.

adam7009 wrote:

I do not sell drivers, I am able to check, repair as much as possible, upload content without opening it, etc. ... and if you put something under the cover, which is similar to the casing and you are surprised that it does not work, I wish good luck and perseverance.

Thanks for the wishes of good luck and perseverance, but it would be more useful to know how to check on the table that the processor and / or the CAN module is functional in these 5 minutes - because (as you wrote) you fix it you know ...

please is
scheme

Thank you, I have the driver pinout (how can you deduce from the first entry in this thread) - how to check on the table whether after giving the power everything is ok with CAN communication and the processor?

All you need is an oscilloscope and a little practice and experience, you don't have to see specific frames, I haven't received a driver with working communication yet, sending wrong frames. So to check on the table all you need is a picture that "sends" something.

I will give a solution - the new driver did not connect with the rest due to a different configuration of the CAN line.

The original driver fell completely - the processor was burnt down, I was able to bring it back to life by reprocessing the processor, but now I have a problem with a 5V error - that's another story.

Thank you for helping to solve the original problem.