An ECU scan tool for turbo and NA owners

[scuzzy]

Ummm... well, try making it print out each byte it receives. We shouldn't do that in recvpoll, since that's part of the timer ISR, so do it in the readbyte procedure. Something like:

Code: Select all

readbyte                               ; read a byte into al
 push bx
 .wait:  
  call byteready
  jz .wait
 xor bh,bh
 mov bl,byte [cs:in_start]
 mov al,byte [cs:in_buf+bx]
 inc byte [cs:in_start]
 and byte [cs:in_start],0fh
 pop bx
 pusha
 mov bl,al
 mov al,'<' 
 call putchar
 mov al,bl   
 call puthex
 mov al,'<'  
 call putchar
 popa
 ret

Maybe that will give us some insight into what's happening.

I'll give it a shot as soon as I get home for lunch (about an hour)

[scuzzy]

Ummm... well, try making it print out each

Maybe that will give us some insight into what's happening.

I'll give it a shot as soon as I get home for lunch (about an hour)

I dropped in the print code in that function (so that it comes out <hex><hex> and so forth.

Noteable things to mention, and/or my procedure:

Started the car, plugged the parallel port into the laptop, powered the laptop on. b10scan.com (modified) ran immediately upon starting the laptop - normal.

No output on the screen other than the reading rom id. I hit space, gave it a moment or two, still no output.

So I closed the application, started 0.05 (bcbfscan.com) and it detected the rom id, I paged through a few variables, made sure everything was working ok. I paged back to the ROM ID variable and then closed the application and started b10scan.com again.

On the screen was a repeating output <70><31><25> (I can't recall the exact rom id, I never can.oh well)

I closed the application again, fired up bcbfscan and changed to a different variable, then closed it down and started b10scan - it was showing the hex values for those variables (such as speed and stuff)

turning the car off and trying again, same procedure, leads to the same results.

[scuzzy]

I did the same thing for the send side. the codes I'm getting back when it's sending are:

FF FF 00 78 FF FE 00 00 FF FF 00 78 FF FE and so on.

So to recap, when starting program, no output from ECU (no bytes recieved) but we're sending like nuts.

[scuzzy]

/me waits patiently.

[IronMonkeyL255]

Can anyone help me?

I am using v 0.5, and can't get it to work. My cable is good. The parallel port on the computer is on and reading correctly (00.ff.ff RID when jumpered). It gets as far as reading the ROM ID, but can't seem to get a valid one.

Also, when I changed parallel port addresses, it changed what ROM ID I got. Here's the results:

-No ROM ID when using port addy 3 and interrupt IRQ7

-f7.fb.3b when using port addy 1 and interrupt IRQ5

-f4.ff.fd when using port addy 3 and interrupt IRQ5

-f2.e1.98 when using port addy 2 and interrupt IRQ5

-fe.fe.fe when using port addy 1 and changing the port mode from bi-directional to EPP (or something like that.....)


It said all of these were invalid. I was excited to see that much progress, considering all morning it wouldn't get past 'Reading ROM ID:'.

Anybody have any ideas?

[IronMonkeyL255]

I am now slightly more confused.

I figured out that I get best results with port 378 and interrupt IRQ5. I also set the processor to its slowest speed. Using it like this, I got results ranging from it stopping at reading ROM ID to pulling the correct ROM ID, but not showing any parameters and showing an undefined ROM ID when I try to re-initialize the parameter.

The other ROM IDs I got include:

7f.ec.71
79.7e.21
71.3b.31
fe.31.36
fe.ec.ff

This is starting to get really frustrating. BTW, the laptop is an IBM Thinkpad T40.

[scuzzy]

Vikash, I narrowed down the problem with the scantool. Now, help me figure it out please

I built the serial connector for my laptop, and after realizing I built a male plug instead of a female, I ran to work and got a gender changer for it.

Here's what I noted

with the cable unplugged from the ECU, I get scrolling 00 HEX's across the screen.

with it plugged in and the car just started, I get no output from the ECU on the screen.

if, leaving the car and the laptop running, I unplug the connector from the ECU and cross the TX and RX pins, I get 00.ff.fe as a ROM ID and it drops down from the 'Reading ROM ID..' screen to the regular 'ROM ID' screen where you can hit space/enter to reinitalize the signal.

now, if I leave them crossed, I can tap enter and I get the same ROM id over and over again - as expected.

if I plug the cable back into the ECU, and tap enter again. I get my car's ROM id. 70.31.25 (IIRC) From there I can scroll between all of the inputs, and all of them come across just fine.

however

if I close the program before changing back to the ROM ID screen, then reopen it, it won't detect rom id anymore - the debugging hex on the screen that we wrote into the code is that of the last value I changed to.

more interesting to note, if I leave the program displaying the ROM id, turn off the laptop, unplug it completly, then plug it back in, I can fire the software back up and it will detect the same ROM id. but if I cut the car off, it won't - I have to cross the TX/RX pins again and get it to display 'Unrecognized' before I can plug it back into the ECU and start viewing data.


Vikash, to me this means one thing and one thing only: we're not telling the ECU in the 'Reading ROM Id' stage to give us the ROM id. However, when I cross the TX/RX pins, I come out of the reading rom id stage, and into the normal stage - where we DO tell the ECU to give us the rom id - and then everything works normally.

Thoughts on a solution? There are the symptoms, you know your code better than I do.

[scuzzy]

By manually sending commands (sendbyte, not using the .commands data) I've been able to get the ecu to spit out ff fe e7 on startup.

keeping you posted.

scuzzy

[scuzzy]

edit: not fixed. thought it was

the add versus and is only part of the problem. I havn't been able to get it to respond properly on a reliable basis.

Generally, it doesn't start to respond to the ROM ID request untill another test I wrote is run first (which isn't designed to complete, so that's sort of a kludge)

the other fact is that it doesn't always work when I run the other test first.
..

screw it untill morning. urgh.

[scuzzy]

Made some progress in the code.

Code: Select all

--- b10scan.orig	Mon Mar 27 17:18:48 2006
+++ bt7.asm	Sun Apr 30 09:52:42 2006
@@ -536,14 +536,17 @@
  mov word [cs:cursor_loc],80*2
  mov bx,.readstr
  call putstring
- xor bh,bh                             ; offset in commands
+ xor bx,bx                             ; offset in commands
  xor dl,dl                             ; how many bytes we've read
+ call sendtest
  .idloop:
+  cmp byte [cs:stct],32
+  je .reset
   mov al,byte [cs:.commands+bx]        ; send the next byte
   call sendbyte
-  inc bl
-  and bl,7                             ; keep walking through commands
+  add bl,8                             ; keep walking through commands
   call byteready
+  inc byte [cs:stct]
   jz .done
    call readbyte                       ; expect ff,fe,??,romid
    or dl,dl
@@ -558,6 +561,12 @@
    je .expectromid2
    mov byte [cs:romid+2],al            ; last byte of rom id
    jmp .gotid
+  .reset:
+   mov byte [cs:stct],0
+   xor bx, bx
+   xor dl, dl
+   call resetsent
+   call sendtest
   .expectff:
    cmp al,0ffh
    jne .notff
@@ -604,10 +613,30 @@
    mov al,1
    ret
  .commands:
-  db 78h,0ffh,0feh,00h                 ; read 0fffeh
+;  db 78h,0ffh,0feh,00h                 ; read 0fffeh
   db 00h,0ffh,0ffh,00h                 ; request rom id
  .readstr db 'Reading ROM ID...',0
 
+sendtest
+ pusha
+ mov al,78h
+ call sendbyte
+ mov al,0ffh
+ call sendbyte
+ mov al,0feh
+ call sendbyte
+ mov al,00h
+ call sendbyte
+ popa
+ ret
+
+resetsent
+ pusha
+ mov al, '.'
+ call putchar
+ popa
+ ret
+
 initparam                              ; request parameter from ECU
  pusha
  mov al,78h                            ; make the request
@@ -1995,6 +2024,7 @@
 recvport dw 0                          ; address of input register

This is probably not right, but, I get some reliability out of it. Sometimes it takes re-starting the program a couple times, but eventually it picks it up and takes off.

We'll know more soon enough. I'm done for now.

[vrg3]

Guys, I'm really sorry that I haven't had time to keep up with this. I'll make some time this evening. I promise!

[scuzzy]

Guys, I'm really sorry that I haven't had time to keep up with this. I'll make some time this evening. I promise!

*cricket*












*cricket cricket*






*cricket*

[vrg3]

I'm sorry!

Okay, let's see:

IronMonkeyL255 - Wow, now that is weird stuff! The scantool doesn't use any IRQs or the bidirectional/ECP/EPP capability of the port, so that shouldn't matter, but it's weird that you're getting those results. Wait a second -- how can you be choosing a port number if you're using version 0.05? 0.05 didn't let you choose one. Or do you mean you're choosing the port address from three options in the BIOS? What are those addresses? Does the scantool correctly detect the address? What kind of computer are you using?

scuzzy - Woah! So using the serial connector, once you somehow finagle it into correctly reading the ROM ID, everything else works? Okay, that's a good sign. I was thinking that somehow the comms routines were just not working. Can you make this happen with the parallel port cable too?

In the meantime, maybe you could just bypass the code that reads the ROM ID, sticking this at the very top of the getid proc:

Code: Select all

mov word [cs:romid+0],3170h                                 
mov al,1
ret

What do you mean "the add versus and is only part of the problem?" I think I missed out on something that you edited away in that post.

Your hack to get the ROM ID seems like you're on the right track. So this tells me that maybe I should reconsider how I'm reading the ROM ID. I don't understand why this would only become a problem now. I don't recall changing this part, unless I changed something accidentally while porting it to NASM. But it all looks correct; I'm pretty sure that's how the Select Monitor does it. Sigh, I wish I had the old code. Oh well.

Thanks for all the work, scuzzy. Sorry I haven't been around to do my part.

[IronMonkeyL255]

The addresses I was choosing through the bios, and yes I am using v .05

Each time the program would correctly find the port.

The Laptop is an IBM Thinkpad T40 w/ a 1.5 gHz processor. There is a setting in the bios for slowing it down, which I tried.

I could see if I was getting consistently bad results, but it just is all over the place.

[scuzzy]

I'm sorry!

Okay, let's see:

IronMonkeyL255 - Wow, now that is weird stuff! The scantool doesn't use any IRQs or the bidirectional/ECP/EPP capability of the port, so that shouldn't matter, but it's weird that you're getting those results. Wait a second -- how can you be choosing a port number if you're using version 0.05? 0.05 didn't let you choose one. Or do you mean you're choosing the port address from three options in the BIOS? What are those addresses? Does the scantool correctly detect the address? What kind of computer are you using?

scuzzy - Woah! So using the serial connector, once you somehow finagle it into correctly reading the ROM ID, everything else works? Okay, that's a good sign. I was thinking that somehow the comms routines were just not working. Can you make this happen with the parallel port cable too?

In the meantime, maybe you could just bypass the code that reads the ROM ID, sticking this at the very top of the getid proc:

Code: Select all

mov word [cs:romid+0],3170h                                 
mov al,1
ret

What do you mean "the add versus and is only part of the problem?" I think I missed out on something that you edited away in that post.

Your hack to get the ROM ID seems like you're on the right track. So this tells me that maybe I should reconsider how I'm reading the ROM ID. I don't understand why this would only become a problem now. I don't recall changing this part, unless I changed something accidentally while porting it to NASM. But it all looks correct; I'm pretty sure that's how the Select Monitor does it. Sigh, I wish I had the old code. Oh well.

Thanks for all the work, scuzzy. Sorry I haven't been around to do my part.

I don't have my old parallel port cable, I had to hack it apart to hack it into my new serial cable (needed the connector which snaps into the select monitor port)


I'll take a look at this some more when I get the urge again. I probably should. I'll take your advice and do the bypass trick at the top of getid and see what happens there.

[west_minist]

Hi all!

If I just run the program w/ no parallel connector, what will happy? The progam is just dead for me.

Tonight I hook it up with the parallel port to a 97 jdm wrx with no stats at all.

I ran portmon with no data @ all.

What do I need to do? I am running it on a IBM T41 laptop.

[vrg3]

If you run it without connecting it, it will just hang when trying to read a ROM ID.

If it's connected correctly and failing to read a ROM ID, try the previous version first. It won't read any parameters other than the ROM ID, but it will tell us whether you're experiencing the same bug that scuzzy and I are trying to resolve.

[west_minist]

Ok. I will try the previous version.

Is there a way to know if the program is communicating with the parallel port in winxp?

[west_minist]

Another question, if I hook up the select to strobe on the parrallel port, would the software show anything?

[vrg3]

It won't work in Windows XP. The page clearly states that the scantool runs standalone or under DOS.

Yes, if you connect the Select and Strobe pins together, it should read a ROM ID of 00.00.FF .

[west_minist]

I have done that on all versions with no results.

I will have to try it on my other computer to see.

[west_minist]

Ok. I tried the other computer, but with the same results.

Reading the site, I used the up/down buttons and the screen change to select the ports. But it then sticks up there.

[legacy93]

hi i need some helping finding the parts for the curcuit

MIC5203-5.0bm4 i have gone to a few place but cant find it is there some specs on it to maybe help me find one that is similar and also on the NDS355AN also are they just surface mounts do i just grab any? help?

[vrg3]

I don't understand. You're talking about the serial port interface? Just get any old 4.7-volt or 5.1-volt zener diode, any old general-purpose NPN bipolar junction transistor, and any old 10K resistors.

What are you saying with those part numbers? The NDS355AN is an N-channel FET, and the MIC5203-5.0 is a 5-volt regulator. What does that have to do with anything?

[legacy93]

k thanks for the extra info

http://www.vwrx.com/selectmonitor/RS232-Discrete.pdf this is the curiciut im try to build just to make sure we on same page

also the N-channel FET is it a switch, as thats what it looks like from the wiring diagram

thanks for the help