Problem With ECU Communication

For starters, in RS232 (serial) communication you must make sure both sides use compatible config modes (i.e. speed, data bits, stop bits, parity, flow control, etc.) If those are OK, possibly you have a cable or hardware problem. Also make sure your terminal is configured to echo both your input and response on screen, to make sure data is actually sent. You can't expect response to zero data. And something else. Are you using USB to serial adaptor? If yes, did this adaptor established any communication with ECU in the past? S.M.

Did it work and then quit? If yes, what changed?

Yeah, I am thinking the same thing that SimpleMind is.

I am assuming that you are monitoring the RS232 lines and see data sent to the ECU, but no return data.

The first thing that comes to mind is incorrect baud rate to the ECU or incorrect data protocol/format to the ECU. The ECU does not know you are trying to talk to it.

My recommendation is to check the specification for the ECU's serial data port and make sure that your transmission parameters are correct.

You may also want to contact the ECU manufacture and ask their technical support line. They are the experts.

Ofc we tried contacting the manufacturer, but it don't specialize in ECUs anymore and those products have been bought by another company. We are trying to get the needed info contacting them but it might be a little long or complicated.

We'll try it with an older computer with which everything was working. I guess if it works with this one, the problem might be about incorrect data protocol sent to the ECU.

Until we try that, feel free to express other ideas regarding our issue - it may help us finding more problems that may be hidden in our actual setup.

Thanks

If you have a machine that works, simply "sniff" that data and get the protocol. Then compare that with the machine that does not work for clues.

However, before you do that, confirm the serial port settings for the working machine and see if the non-working machine is set up the same.'

Of course, the problem could be that the host software does not run on your non-working machine due to an out of date driver software or something.

The problem may also be a 'virtual' 232 port in the newer OS. In the 'old days', the com ports were handled by the BIOS at fixed address locations (0x3F8 for COM1 if I remember correctly). I remember upgrading to a newer OS and the address port was no longer handled by the BIOS, but rather the OS, and it had given it a 'virtual' address that the older DOS software couldn't recognize. As stated earlier, the data speed, parity, and stop bit settings need to be confirmed. Check the internal BIOS for com port being enabled as well, it can also be seen in the Device Manager (assuming Windows OS here) configuration screen.

ahhhh...brings back fond memories of RISC processing.

Hi everyone,

I'm currently working with the OP about the ECU problem. To answer some questions, I verified my settings for the rs232 protocol (BaudRate: 19200, Stop bits: 1, flow control: none, data bits: 8, parity: none) Which is what we've been using the communicate with our ECU and used to always work.

Also, I verified my cables many times and I even have two

I tried what Anonymous Hero said about the request sent to the ECU, I used a rs232 sniffer and the software sends the right request but it doesn't read anything in return. By the way, we had the find the request by ourself because the company didn't want to give to us when we bought it. So the request that we know is the request that is sent to the ECU.

For the rest we didn't change anything except plug 2 new wires for our driver interface.

Other than that I'm stuck if any other idea let me kno

thks, seb_cc

...verified my cables many times and I even have two... two what? Have you tested these wires with another bi-directional serial device? (There are one-way variants and you can't tell the difference unless you test pin by pin.)

OK. Connect like this on computer side to test with hyper terminal or something equivalent if you have immediate echo back. (you must be able to see each character twice)

And there is another possible issue if ECU serial cirquit is really old, and you use USB to RS232 converter or a laptop serial etc. The problem is it's pulse voltage will be too low ~ 7-8V and old interfaces will not 'hear' anything below 10-11V. Try with an older motherboard with build-in serial (they will rock up to 15V) and W98SE (if you can find one) that needs no drivers and OS does not interfere with hardware all the time. S.M.

Earlier RS232 signals were much higher voltage than more recent ones. Maybe the signal going into the ECU is not big enough.

Can you borrow an oscilloscope?

Time to reverse gears.

Try going back to the exact same physical/software configuration that you had when it worked.

Once you get that working, again, then start adding the changes you made - one by one - until it breaks again.

That will isolate the problem to the offending change. At that point you should be able to figure out why.

What I meant about the two different is: I have two different cables to connect with my ECU. I made sure to test the cables with a multimeter to make sure there is no inteference between pins.

Also, I'm not using an USB-Serial converter. On the laptop, there is an DB9 RS232 plug at the back which I'm using. I tried doing the echo on hyperterminal and it was a success (it displayed twice the character that I entered).

After all this, I couldn't find the problem so I decided to do what Anonymous Hero said which is go back to my original setup and I still couldn't communicate with it.

Who said anything about interference between pins? Test one by one the pins if they are all connected in the other side, or make the pictured connection in my last post on cable end on computer side. Not at computer output. That's basic serial cable troubleshooting. And I specifically said about voltage level of laptop serial. Of course one can't push info into another's head can he? S.M.

So, ask yourself what do you think changed?

Once you have rechecked and eliminated all else, the most likely problem would be the ECU itself. Perhaps a hardware problem in or on the ECU board.

I might have express myself in a wrong way but ya I meant check pin by pin.

I'll try and get an oscilloscope for now and see what it gets me.

Thanks for your advice. Seb_cc

Check the baud rate (1200? 9600? Etc.) and bit string (8N1? 7N2)? Check for need for cross-over cable to interchange the Tx and Rx lines.

Regards/J