OBD not responding on a Honda ECU

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on a small LCD milage indicator that will receive its info via the ODB II interface on my car. To ease the development, I bought a 99' automatic Civic ECU off of ebay so I can have a test ECU on my desk instead of having to haul all of my dev stuff out to my car. I've wrote the code to initialize the ECU over the ISO 9141-2 link but the Civic ECU doesn't respond to the initialization command. I hauled all of my stuff out to my Accord to test my link on its ECU and the ECU responded to the initialization command just fine. Thus, my link is OK but the Civic ECU isn't responding for some reason. I still need the Civic ECU to develop the rest of the OBD software without hassle.

I shorted out the service check signal (SCS) and the check engine light blinked out 6 trouble codes. Rightly so, given that the ECU is running without any of its peripherals attached. Still, the OBD link should work to spit out all these trouble codes. Anyways, that means the ECU is alive to some extent. On the ECU I've hooked up IGP1/2 (switched 12V), PG1/2 (power ground), LG1/2 (logic ground), VBU (voltage backup, always on 12V), and of course the K-line (OBD link), MIL, and SCS. Here is a pin-out of the ECU with all of its signals. Am I missing some connection that I have to make or what? Has anybody else done a bench test of an ECU? What did you have to do to get the decapitated ECU working? Thanks for your help. :D

Here is a list of the trouble codes it spit out through the malfunction indicator light:

  1. Auto transmission malfunction
  2. VTEC oil pressure switch malfunction
  3. Electrical load detector malfunction
  4. Idle air control valve malfunction
  5. Engine coolant temp. sensor malfunction
  6. Intake air temp. sensor malfunction

Once this is done I will publish the schematics, PCB, and code. I also might take orders for an assembled kit. It will display stats like mileage and temperatures on a character LCD, but also provide an OBD link to your computer via USB. :)

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you try to do something else, let's say to read the battery voltage or to callibrate the battery voltage, or even to turn off the mil lamp?

I am saying this because this is a good way to test if your device works ok. If this test will pass then it prooves that there may be a bug in your fault memory read function.

I hope this helps.

Michael.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michael,

I haven't actually gotten to any of the fault reading yet, I'm just trying to send the initialization command (0x33 at 5 baud). The command was accepted and responded to with my actual car's ECU but not with the ECU I'm trying to bench test.

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OBD2 is a lot of fun, but it's hard to find good information. There are a ton of sites out there, but most lack a lot of information and some are plain wrong. The ISO standards are hard to read and are expensive, but are very thorough.

Check this out, lots of good info:
http://sterntech.com/obdii_proto...

Also good, but no initialization info:
http://www.obddiagnostics.com/ob...

Good group to join and look at the Files section or search messages:
http://tech.groups.yahoo.com/gro...

The wikipedia entry is somewhat informative as well:
http://en.wikipedia.org/wiki/Obd

In short, you may be missing the Keyword interaction with the benchtop ECU (see sterntech link). It is possible your Accord doesn't care about Keywords, but the Civic does.

Hope that helps! Good luck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a project to display instant MPG and others information on a LCD in car.

One "branch" is taping injector and VSS to calculate and display, it works.

I am working on the OBD2 branch, with an Arduino board (ATMEGA168P) and a MC33290 chip, however my ECU never answer to my init command (0x33 at 5 bauds).

As yours is working maybe you could help us debugging either the hardware or the software :wink:

The main project page is here
http://code.google.com/p/opengauge

The obduino source code (GPL) is in the trunk
http://code.google.com/p/opengau...

We have a development forum at
http://ecomodder.com/forum/openg...

You are working in C? would you share your source?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure, here is the init function. I just send address 0x33 and my Accord's ECU responded correctly. I didn't bother using the UART for such a slow baud, just software bit toggling. Let me know if you have any questions. Good luck! :)

For anyone wondering, the ECU has a faulty BJT on the K-line, go figure. I can't get a hold of the seller either. :(

void send_address(uint8_t addr) {
   uint8_t i;
   uint8_t temp;
   
   /* idle high */
   TX_PORT |= _BV(TX_BIT);
   TX_DDR  |= _BV(TX_BIT);
   
   /* required idle delay w0 (2ms), be safe with 4ms */
   _delay_ms(4);
   
   /* start bit */
   TX_PORT &= ~_BV(TX_BIT);
   /* this is at 5bps */
   _delay_ms(200);
   
   /* send byte */
   for (i = 0; i < 8; i++) {
      temp = (addr >> i) & 0x01;
      if (((TX_PORT & _BV(TX_BIT)) >> TX_BIT) == temp) {
         /* already at the correct level, do nothing */
      } else {
         if (0 != temp) {
            TX_PORT |= _BV(TX_BIT);
         } else {
            TX_PORT &= ~_BV(TX_BIT);
         }
      }
      _delay_ms(200);
   }
   
   TX_PORT |= _BV(TX_BIT);
   _delay_ms(200);
   
   /* already idling high on TX */
   
   return;
}

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the schematic, for completeness. The voltage divider is a poor way of doing the RX side, the specs for ODB-II interface say that the voltage can vary quite a bit. This circuit could easily go over 5V on the RX pin if that is the case.

Attachment(s): 

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jevin,

I've never played with the ODB II bus. So take my thoughts with a grain of salt... I have, however, put several uC's in vehicles.

If the K-line is not already protected, and has potentially lots of spikes and noise, how about putting a simple reverse biased 5 V Zener diode across R3?

This would clamp that line to about 5 V, protecting your input.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Magister,

I've looked at the code in obduino.pde and the init routine looks fine, as long as the supporting functions are correct. You do know that the baud sync byte is 8-bits while the keywords are 7-bits with a parity bit? Why did you choose to bit-bang the UART instead of use the hardware UART (I'm assuing the Arduino has functions to use the 168's hardware UART). Are you sure your car is using ISO 9141 and not KWP2000?

-Jevin

Attachment(s): 

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the "Freescale MC33290 ISO K Line" chip, you can see the schematics of our setup here:
http://code.google.com/p/opengau...
It's a all-in-one chip that does all the signal conversion, it includes something like 75 transistors and is used in others similar design.

The UART of the duino board is used to upload new code and send debug info on it. The K line is drived through 2 digital pin for the 5 bauds as well as the 10400 bauds.

My init function to send the 0x33 at 5 bauds seems right, I monitored the output with a scope and timing are correct.

I made the 3 init functions, iso9141 and iso14230 (kwp) fast and slow. My car should answer to both ISO, as well as CANs, I am wondering if it's CAN only :shock: It's a 07 Hyundai.

It's just that my car answer nothing after the 0x33 :( the K line is always high and I never receive a start bit from the ECU. I put the scope in the car on the K line to monitor it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Magister,

By no means am I an expert, but I have a few more thoughts and I have been down this road. Hopefully Jevin doesn't mind too much that we are hijacking his thread.

I don't know what kind of scope you are using, but the 10.4kbps response may be hard to see relative to watching the 5bps address go out, depending on the resolution of your scope. You are trying to see a few ms of reponse right after seconds of response.

Along the same line of thought, the accuracy of your 5bps may be more critical than you are able to eyeball. As Jevin says, the way to do this is use the USART. (The disadvantage is that you cannot detect collisions on the bit level.) With the clock prescaler register and the UBRR, you should be able to set the USART to 5bps VERY accurately. I don't know anything about the Arduino, though. I wrote some routines in C that I could share if it helps.

If your car is KWP2000, you should still get a response with the slow init, but the keywords will be 0x94 0x94 as in Jevin's figure above instead of 0x08 0x08.

If your car is both CAN and ISO/KWP, your ECU may be on the CAN bus but only other systems (ABS, etc...) on the ISO bus. In that case, the ECU can only answer from the CAN bus.

Since you have a 2007 Model Year and all US cars (maybe Canada, too?) are required to be CAN bus by 2008 model year, Hyundai may have implemented it early and you are out of luck. In that case, find a friend with an ISO protocol car and try it on his/hers. Once you determine that it works, try it on yours.

Also, keep in mind in the big picture that OBD is relatively slow. Retrieving MAF and MPH, if they change rapidly, may lead to errors in sampling.

OpenGuage looks like it could be a great DIY project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On most AVRs, you can get 5 baud *only* if the master clock is under 327kHz or so - you need to bit bang it.

I've successfully initialised Bosch pre-obd units using a 200ms bit period but the spec has stated +/- 10%

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not to step on anyone's (barnacle's) toes, but that is something to consider in more detail. Is it possible to scale the system clock (CLKPR) and USART (UBRR) low enough? I don't know the Arduino, but my experience is on the mega169 (Butterfly). There, I used the 8MHz internal RC clock. I don't have my datasheets, notes, or code with me to go through it right now, though.

From memory, I scaled the system clock down by a factor of 128 to 62.5kHz. The UBRR is 12 bits, which allows a huge reduction to the USART baud rate.

It looks like the Arduino boards use the mega168. I would assume the same thing is possible there, if this is the case, by just skimming the datasheet.

barnacle, I have looked at your project in the past. It is nice work. You are dealing with KW1281 or some variant, correct? Is the 10% spec for ISO, or specific to Bosch/KW1281/OBD1? In any case, unless measured precisely, it may be difficult to just eyeball 10% on a scope.

There are many variables to consider and I didn't read up on Magister's code or the Arduino in detail.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The scope is an Agilent 54622D, the resolution is fine and the timming is right to the ms, I even put the trigger on the line and as far as I can tell, my ECU does not answer :(. I can see in the init when I send the 0xc1,0x33,0xf1,0x81,0x66 on the scope.

I will ask some co-workers to test on their cars, or find a "true" scanner and sniff what it does.

Damn, I hope my car is not CAN only!!

The arduino is a small dev board, all the info are here:
www.arduino.cc
It uses the "wiring" API so it's easier to play with I/O and things like this, then it uses avr-gcc to compile the source.

For Opengauge we want an easy "DIY" project: buy an arduino kit or an already built one, a few plugs/wires, download the Arduino IDE, copy/paste the source and click on "upload to board" and voilà.

PS: sorry Jevin for the thread hijack!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bro, I don't know where I got the spec, somewhere on the net. Both the ECUs I talk to claim ISO9141, but having discovered at the time that the 33290 was only available in tens of thousands, I played around with a few inverters and ended up with a level slicer - a low-voltage op-amp and a reference voltage.

When I was using a 5v supply I had no problems, but the 3.3v supply made it a bit more problematical. Although a half-rail version *should* have worked, it was fine on the Magneti Marelli ECUs but not happy on Bosch. I've ended up pushing the slice reference as high as I reliably can before the chip sulks - 2.07 volts - though it appears to be marginal at 1.8v and stable at 2.0v which is somewhat more than 10%

In a redesign, I'd probably put the slicer in the 12v side and pad down the output to 0-5v.

I'm thinking of the M32, and haven't investigated the others in detail, but the UBRR registers - 12 bits - divide the master clock. Best you can get internally is 1MHz, but that limits around 16 baud (and all the stability options previously noted with internal clocks and uarts). Externally, hmm, haven't investigated in detail, but it might be possible to run it in slave mode with an externally generated signal and a bit of wire.

But I had a convenient internal 10ms tick that I could hook, so I did. :mrgreen:

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems my car is CAN only so I may take another way (ELM327 for instance) :(