Page 1 of 6 123456 LastLast
Results 1 to 15 of 89

Thread: 1997 F-Body Tools

  1. #1
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    1997 F-Body Tools

    New thread is intended to help support tools of use for debugging, uploading and downloading LT1 OBDII PCMs.

    I have had a good look now at some software that I believe Tech II uses to download these PCMs. Somewhere back in the 1997 F-Body PCM thread there are details of this software but I have had a much deeper dive into it now and it's worth sharing. I believe that in our PCMs the TPU is the heart of the system. If you accept that I will offer that the SPI bus is the backbone. In working through the way that the Eside is programmed, I came to a better understanding of how the SPI is used in the system.

    During normal operation, the SPI makes our multi-processor system function by transferring data both from Tside to Eside while simultaneously transferring from Eside to Tside. Details of this transfer are to be found in the "PCM" thread and I will not duplicate here other than a broad overview. The T to E transfer moves 25 parameters every cycle along with a checksum. The E to T moves 20 parameters each cycle plus one of eight frames and of course checksum. The eight frames each have 10 parameters and are sent sequentially every cycle. So it is the SPI that passes both control and information between the two sides.
    A second function present during normal operation is the monitoring of the output driver circuits. Here, the Tside re-configures the SPI, de-asserts slave select to the Eside and transfers two bytes through the blue, red and black driver ICs. Those ICs are the 23 pin staggered SIPs that are found by each of these connectors.
    The third function the SPI serves relates to upload/download. The Tside sends an SPI message that puts Eside into a special mode. In this mode the Eside interprets commands sent to it in a very similar way that DLC commands are interpreted. In fact these commands are the same except that the header used in J1850 is stripped off.

    With that background, one goal I have is to upload the code from Eside. This will make use of a mode $35 command. While the Tside does not support mode $35, I wrote some software to provide it. This permits upload of Tside. To do the same with Eside the command received and validated by the Tside must then be forwarded through the SPI and acted on by the Eside.

    I have improved the comments in the programming assembly file and will attach a snip of it to this post. In order to support upload, I will re-write some of this code to permit validation and forwarding of mode $35 commands to the Eside. I plan to merge the software I wrote earlier such that uploading will require a single file downloaded to the Tside. Once downloaded the module will permit uploading from both banks of Tside and from Eside.

    Here is a snip of the code that does the forwarding in the download case:
    Code:
    *************************************************
    * FORWARD REQUEST TO ESIDE
    *************************************************
    
    F_REQ_ESIDE:                    ; ...
            pshy
    
    
            ldy    #$0549            ; INITIALIZE TIME OUT COUNT
            clr    COP_RFSH_COUNT        ; INITIALIZE COP REFRESH COUNT
            jsr    RESET_COPS        ; RESET    COP TIMERS
    
    FE_WAIT_ES:                    ; ...
            dec    COP_RFSH_COUNT        ; DECREMENT COP    REFRESH    COUNT
            bne    FE_SKIP_CR        ; SKIP COP RESET
    
    
            jsr    RESET_COPS        ; RESET    COP TIMERS
    
    
            dey                ; DECREMENT TIME OUT COUNT
            beq    FE_FAULT        ; TIME OUT EXPIRED
    
    FE_SKIP_CR:                    ; ...
            ldaa    PORTA            ; PORT A BIT 1
            anda    #$02
            bne    FE_WAIT_ES        ; LOOP UNTIL ESIDE SIGNAL
    
    
            ldaa    $00,x            ; READ SPI TX DATA
            staa    SPDR            ; INITIATE FRAME TRANSFER
    
    FE_XFER_LP:                    ; ...
            ldaa    SPSR            ; READ THE SPI STATUS
            bpl    FE_XFER_LP        ; WAIT FOR TRANSFER TO COMPLETE
    
    
            ldaa    SPDR            ; READ SPI RX DATA
            cba                ; COMPARE RECEIVED WITH    BYTE COUNT
            bne    FE_FAULT        ; SPI FRAME ERROR
    
    
            incb                ; INCREMENT TRANSFER COUNT
            inx                ; INCREMENT SPI    TX BUFFER POINTER
            puly                ; RESTORE REGISTER
    
    
            rts                ; DONE
    ; ---------------------------------------------------------------------------
    
    FE_FAULT:                    ; ...
            ldx    #$1008            ; SLAVE    SELECT INACTIVE
            bset    $00,x $20        ; ABORT    REQUEST    TRANSFER
    
    
            jmp    START
    ; End of function F_REQ_ESIDE
    -Tom

  2. #2
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Home brew cable update

    There were a number of bugs in the first version of the home brew cable. A time parameter was mistakenly entered in hex instead of decimal. The cable had only been hand tested and had never been checked for ensuring the tx didn't over write incoming frames. Other small fixes.

    Thought I would take just a moment to update the software in case someone is trying this... There is no change to the interface, so I just copied the info from the other thread here.


    -Tom

    =============================================
    Download for OBDII

    The first bit of software to discuss is the bit that runs the home brew cable (HBC). The heart of the HBC is an Atmel ATMEGA328P processor. Subjectively, this part has a lot of advantages over the 68HC11 that I first tested with. The timer has very powerful modes, the free IDE programs the part in C and has all you need to write/debug code. Cost of the board was under $5 although the worldwide shortage of semiconductor parts has brought the price up a bit.

    My code which Atmel refers to as a "sketch" is written in 5 modules. Here is the basics of operation:

    The HBC software separates receive and transmit completely. This lets me monitor what I send along with what is returned by other nodes. The software (at least this version) has limitations in speed (no 4X yet) and in ability to perform outside of the early GM network (no arbitration --> two nodes only, break is detected but not acted on)

    The receive symbols are decoded using the pin change interrupt. The interrupt determines the level of the previous bit and it's length. It then looks up the meaning of the symbol and pack it into bytes sent to the PC.

    The transmit is timer driven. When a line is received, it waits until any current frame in progress is complete, then output the frame including SOF and EOF.

    A normal sequence to read the security seed sends
    4C 10 F0 27 01 71
    and receives
    4C F0 10 67 01 58 3D 27

    Since the Arduino Nano board uses serial over USB, I set the interface at 115200 8N1
    Characters are sent to the board using standard ASCII, each pair represents a hex digit

    Probably forgot to detail something, so please just ask if there is confusion.

    I am enclosing an archive of the Atmel archive. I am told that it is just a zip file that contains the project. All is in public domain/free for you to use. I expect to be improving on features and quality as time passes, will post later versions here.


    That is the cable software, but I have written command line code for your PC that takes SRecords and downloads them to ram. All sorts of things can be downloaded: Flash programming, Flash dumping, debug routines... whatever you can think of.

    -Tom
    Attached Files Attached Files

  3. #3
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Interesting stuff Tom. I recently bought a 2001 Y body and was thinking to myself how cool it would be to have an open source tool to talk to it with. But for now I'll be dusting off my Jet cable / software (based on tunercat).

    Just to clarify a few bits - the arduino IDE is not sanctioned by Atmel. They also have a free but non-open IDE suite for their AVR products but it's not quite as friendly to beginners.

  4. #4
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,469
    Quote Originally Posted by spfautsch View Post
    Interesting stuff Tom. I recently bought a 2001 Y body and was thinking to myself how cool it would be to have an open source tool to talk to it with. But for now I'll be dusting off my Jet cable / software (based on tunercat).

    Just to clarify a few bits - the arduino IDE is not sanctioned by Atmel. They also have a free but non-open IDE suite for their AVR products but it's not quite as friendly to beginners.
    A little off topic but 2001 ybody pcm is currently very well hacked, with freeware support. Still a homebrew cheap cable is missing, but you can easily fill the gap.
    Maybe a new thread will be more appropriate to get you started.

    On topic, the progress is awesome. Great work and complete write up. Can`t wait to see that project finished.

  5. #5
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I received mail with a few questions regarding the home brew J1850 cable. For this project I have built a single prototype and the software is still somewhat in flux. Having said that, it works reliably and I have been looking at extending the upload capability to the Eside. I am answering questions on this thread because whatever someone finds unclear, others will surely question as well. OK so....

    J1850_IF.jpg

    1) The 820 Ohm Resistor; is that a commonly available discrete or should I combine a few resistors to get that value?
    This resistor was selected based on several assumptions. The zener diode is 8.2V and for my test setup the input voltage is 12V (give or take). These two components are just there to provide an 8.2V source for the line driver. There should be round about 4v across the resistor. This gives us about 5ma of bias current for the zener. Since IZT of the zener is 30ma you could go with a much smaller resistance but not too much larger. Probably 1K would be fine. Just depends on what you have floating around your tool box. I suggest you use no larger than 1K or smaller than 500 ohms. With these values resistor of 1/10 watt will be fine. This part is not sensitive... use what you got.

    2) Best to get the 47K resistor in the bulk pack kit?
    The 47K resistor forms a voltage divisor with the 10K. The ratio of these two parts is important but values could be changes. These two resistors along with the transistor and another 10K form an inverter and a level shifter/buffer. Test your circuit by sending frames. You should see the output of this inverter toggle and the circuit will send your sent frame such that you can monitor it for correctness on your terminal. These resistor are all available on digi-key/Amazon/Ebay and hundreds of places.

    3) The Arduino_Nano... there's a lot of choices on SparkFun.com. Any recommendations in particular? I see this one: Arduino Nano Every - DEV-15590 - SparkFun Electronics
    I bought several Arduino boards. I like the ones that come with a short cable and have all the header pins installed. I can't recommend a vendor except to say that some things are in short supply just now. I got mine through Amazon and found a vendor that had a good delivery and good recommendations from other buyers.

    4) Any particular size breadboard you recommend?
    I guess it depends on your skill soldering and so on. If you want small, surface mount resistors are good. you can use wirewrap wire to hook things up. With leaded components you will be a bit larger due to the resistor wires and bending them to fit the holes. I would thing 2" by 4" would be more than enough. So far I have not built a breadboard. I built mine in a prototyping strip... this is just another project I need to complete.


    Hope this helps.

    -Tom

  6. #6
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    I have an arduino uno R3 on hand; any issues with using that instead of an arduino nano? The processors are the same, I believe the code is the same, and we only need two output pins so we should be good? I'm just brand new to arduinos.

  7. #7
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,469
    Great write up on the hardware side.

    Can you give some insight how the software side of actual communication will work. Does it use comm port, is it transparent or some translation between cable and pcm is done, checksum and so on. The usual stuff we need to get a good start with it.

  8. #8
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    Zener diode question - based on mouser, it looks like the P/N you used was 1N5344B?

  9. #9
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by sherlock9c1 View Post
    Zener diode question - based on mouser, it looks like the P/N you used was 1N5344B?
    The schematic should have shown the part number, but didn't... I used a 1N4738 in the prototype. You can pick up a datasheet here:
    https://www.onsemi.com/products/disc...er-diodes/1n47

  10. #10
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    Tom, I ordered a few of those 1N5344B's before you responded; it looks like the Izt is 5x what the 1N4738's is, (150ma vs. 30ma). The Zzt is 1.5 vs. 4.5 ohms. It's been a long time since I've done circuit design; is that much more bias current a deal breaker? 150ma seems like a lot for this application.

  11. #11
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by sherlock9c1 View Post
    Tom, I ordered a few of those 1N5344B's before you responded; it looks like the Izt is 5x what the 1N4738's is, (150ma vs. 30ma). The Zzt is 1.5 vs. 4.5 ohms. It's been a long time since I've done circuit design; is that much more bias current a deal breaker? 150ma seems like a lot for this application.
    Yes but cheap and dirty. You don't need much current for this... easy to calc from J1850 spec. Remembering if I can, I bias the zener with ~5ma or so suggests a 30ma is still overkill

    I am sure this will work but if any troubles... Just reduce the value of the resistor (increase bias current) bias some. 400ohm would double the bias to about 10ma. From the curve you should be well in range.
    Last edited by Tom H; 01-27-2022 at 03:35 PM.

  12. #12
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    HomeBrew Cable (HBC) was designed initially to get around deficiencies the ELM327 cable presented me. I wanted to explore the PCM software fully but was unable to get past the restriction of 12 byte frames. To be fair, this restriction is part of J1850 standard. GM used this violation of the standard for the purposes of transfering large amounts of data between PCM and tester. It was this one issue that caused me to abandon the ELM327 and find another interface. I went looking for a store bought cable. Availability, cost and flexibility were the factors. At the time I started this project, there were no good candidates. There was one, but they didn't ship to Canada... So how hard could it be to design my own? Turns out it wasn't easy AND I am still chasing a few gremlins (now gone with v3?) buried deep in the code but at this time it is about 99%. This write up could help get rid of any final issues because it causes me to try and remember how/why things were done in order to write it all down. Here is my best shot:

    The HBC is based on an Arduino NANO module. This module is very low cost (mine cost ~5$, prices have gone up because of world semi shortages but still low cost). The module integrates an ATmega328P processor with all the circuits needed to make it run (clock, reset, power, CH340 USB serial interface). I won't discuss the CH340 or the bootstrap loader system here. The one thing that is important is that when the PC serial port is opened, it causes a reset in the NANO. When you write software for this setup, the port should remain open for the duration of what ever you are doing. Else wise, the module is reset and needs a delay of seconds (2S if I remember correctly)before the part re-boots it's self.

    J1850 Software
    --------------
    Again before I start, This is not intended to be a certified 100% grade AAA interface. I have not paid much attention to rise a fall times of signals. This could mean that the module could produce enough EMI to buzz an AM radio. Please remember that the intent is/was to build a workable interface that permitted up/down loading, testing, logging.

    Starting with the receive side: It is necessary to detect and measure the time between transitions in order to decode J1850 symbols. The software makes use of interrupts to do this because the latency of polling will not be accurate enough. The function "ISR(PCINT0_vect)" is run each time the pin changes state. Timer 2 (of the ATmega328P) is setup to run with a prescale of 32 and thus counts 2us increments. Each time the receive pin changes state (H->L OR L->H) the PCINT0 (that is PinChangeINTerrupt0)is serviced.

    PCINT0 needs to take care of timer overflows. For example if a L->H transition takes place when the timer reads 0xFFF0 and the pin transitions H->L 40us later the timer will then read 0x0010. This overflow condition needs to be looked after in order that the correct time is computed. Once the pulse duration is found, this time represents the width of the !PREVIOUS! bit. Using the previous bit level and the width, the symbol is looked up.

    Symbol Standard spec What the code does
    ----------------------------------------------------------------
    Invalid ; Pulse width less than 34us
    Short pulse > 34 <= 96 ; Pulse width 34us <--> 96us
    Long pulse > 96 <= 163 ; Pulse width 96us <--> 164us
    SOF > 163 <= 239 ; Pulse width 164us <--> 240us
    EOD > 163 <= 239 ; Pulse width 164us <--> 240us
    EOF > 239 N/A ; Pulse width greater than 240us
    BRK > 239 <= 1.0 sec ; Pulse width greater than 240us
    IFS > 280 N/A ;

    IFS is not so important in a system with only two nodes. The nodes work in a request/response manner, I have not yet found the need to time this.


    For accuracy, transmission of bits is also interrupt driven using timer 0. The service routine is TIMER0_COMPA_vect. The output always toggles for each bit sent. The level and width depend on the previous bit and the bit to be sent.

    The NextBit class provides a lookup of the next symbol to send. See NextBit.CPP and .H.


    At this point it may be easier to handle each of the files in order to understand the software. I have done my best to add comments to the code and to explain it BUT it isn't easy to write this all up. Here is a shot at a write up...

    Note1, it might have been easier to document this code with pseudo code. Does anyone have a tool they can recommend to ease this? I have no experience with pseudo code at all.

    Note2, A ghost was found buried deep in the code that was causing the bug I have been searching for. The request to document this code caused me to clean up, remove junk and generally consider things. The problem I found might help others who write code for arduino serial functions. Originally I wrote the end of frame to the PC like this
    Serial.print("\n") // DON'T DO THIS
    The above line creates a hex string of $0A $00. It then sends the character $0A, detects the string termination and returns. If you do this from an interrupt there is a problem that I don't understand with the .print function. It works 99% of the time but sometimes overwrites characters in the fifo. I was getting ramdom missing characters. My upper level software detected the missing character. This resulted most of the time with CRC fault. Other times the frame header got hit and I detected a missing response. I started to mess around with recovery from bad frames BUT in the ends solved it like this
    Serial.write(0x0A) // Faster easier cheaper works 100%
    I am now able to down load support for mode $35 to ram then with another bit of code dump TSide, format into Mot SRecords (S2/S9). I will post this stuff later.

    Note3, Newest software for HBC is in this post PLEASE get rid of the older stuff.



    Parse.cpp
    Parse.h
    ---------
    This pair files service inputs from the PC to the HBC. Valid inputs are:

    -'I' Initialize the transmit side to receive a frame. This is optionally done to reset the transmit input.
    This command may be send after the NANO has booted. That is about 2.5S after the port is opened. In most (all?) cases it is never needed.

    -' ' Space character is used to make the line human readable. Space may optionally be sent between pairs of hex data.

    -'characters in the range of 0-9, A-F or a-f' Characters sent are the frame content. Space may optionally be used between hex pairs but not separating the pairs.

    -'\n' Hex $0A character instructs HBC to send the frame in the buffer. The TX buffer sent has CRC appended to it before the frame is sent.

    The code simply checks the input serial stream from the PC to see if characters are available. If characters are available, data input characters are placed in the tx buffer sequentially. If \n is received, the buffer is sent. I command resets/initializes the transmit buffer to it's initial point

    NextBit.cpp
    NextBit.h
    -----------
    This pair of files instansiates the next bit class. This is responsible for generation of the next symbol during transmit. NextBit is called from the timer 0 interrupt service. The return value is used to set the level and length of the next bit to be transmitted.

    HexOut.cpp
    HexOut.h
    ----------
    This pair of files takes a hex character input and transmits three ascii characters to the PC.

    CRC8_SAE.cpp
    CRC8_SAE.h
    ------------
    This pair of files takes an array of hex data representing the frame to be sent and returns the CRC. Used to append crc to the transmit stream. The HBC does not check CRC on the receive stream. This could easily be done, but is better handled by running this routine in the PC. That way the CRC covers not only the J1850 serial but also the NRZ link between the arduino micro to CMD640 and also the USB to the PC. An arguement could be made for generating the transmit CRC in the PC as well. My decision here made it much easier for me to send commands from a terminal without needing a separate calc for CRC to hand enter into the frame. In the future a command could be added to inhibit appending of CRC by the HBC.

    J1850_VPW.cpp
    J1850_VPW.h
    -------------
    This pair of files looks after initialization of HBC, interrupt services and debounce of the input. The initialization sets up Timer 0 for 4us interrupts when enabled. The bits sent have width that is multiples of the 4us time. When a frame is sent, this timer is enabled (parse.cpp) and Next bit is initialized. The timer interrupts when the count reaches 0x40. The reason for this selection is lost in time, it might have been easier to have selected 0xFF and just used a -ve number for initialization. This works well so...
    Timer 2 is concerned with measuring the time between transitions of the input. Each bit restarts the timer. When a transition happens, the count (2us increments) is measured. It is this count that determines what symbol has been received. The symbols are assembled into bytes and sent to the PC. When EOD is reached, a \n character is sent to the PC. This makes it more useful for a terminal to read because the frames are all separated on lines.
    Attached Files Attached Files

  13. #13
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I am at the stage where I have most of the functions needed for altering code working. I have questions for you all regarding format(s) that are useful in other tools.

    My work has so far been mostly in isolation from commercial tools. I find Motorola S records to be a very convenient format. This format permits me to load a module without remembering where in memory it is to be loaded. There are dozens of standard formats out there but it also makes some sense to stay with the format that matches the processor used. IDA is also set up to read S records, so at least there is a flow there.

    If I look through gearhead archives of binaries, most are just straight binary... start at $0000 work through $FFFF. This just isn't good enough for the orphan '96/7 PCMs. These PCMs are based around 68HC11 unlike the later OBDII PCMs. Also an issue is the bank setup on the Tside. To use a binary format, three areas need to be loaded: TSide bank 0 range $2000-$FFFF, Tside bank 1 $8000-$FFFF and Eside $2000- $FFFF. Minor ranges for both sides in the $0E00-$0FFF might also need to be considered. If a 128K binary for the TSide was generated, the programmer still needs to remember that the first $2000 are not programmed and that the first $8000 on bank 1 are also skipped.

    Since I see the Srecord as the format of choice, this is what I plan to use for storing and loading of binary data in/out of the PCM. Often times where another tool is involved in the modification for tuning there will be a specified format they want to use.

    Here are my questions. If binary format is wanted for your tool (tool name?):
    - Does the TSide bank 0 binary start from $0 or $2000?
    - Is there a separate file for TSide bank 1?
    - If yes, how is the bank 1 gap between $0 and $8000 handled?
    - If no, does bank 1 address $8000 follow bank 0 $FFFF or is there padding there?
    - Does the ESide binary start from $0 or $2000?

    If someone could offer me some guidance here (The exact expected format), I will make up a console app to do the conversion back and forth. If I can't pin down the output format, command line switches could be set up BUT that is always confusing to the end user.

    Other stuff --
    Tside upload is complete now. I have tested uploading both banks and the EEPROM areas into SRecords.
    Download console app is now completely solid after yesterdays fix to HBC.
    Still thinking about the ESide, some work needed.
    4X for HBC is a little way off.
    For interest below are some of the calculations for upload time.

    =================
    Distribution of short and long bits, assumed to be even

    Short bit time 64 us
    Long bit time 128 us
    Ave bit time 192 us

    Ave byte time 1536 us

    Frame Overhead 500 us


    Request UL $35 11 Characters + overhead
    Response UL $75 12 Characters + overhead
    Request UL $36 29 Characters + overhead
    Response UL $76 12 Characters + overhead

    Sequences 3584 Sequences loading 16bytes at a time to match SRecord format

    Characters/sequence 52 Assumes no PC response to Mode $36 (no mode $76)


    Sequence time 80372 us
    80.372 ms

    Total time 288053.248 ms
    288.053248 s
    4.800887467 m

    Characters/sequence 64 Assumes PC response to Mode $36 (mode $76)
    5.901892267 m

    I tested and found the time matches (all 1X for now). The total time to upload will be about 11min for the whole PCM. When/if I can get 4X working, 3min PCM upload should be possible.

    -Tom

  14. #14
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by sherlock9c1 View Post
    I have an arduino uno R3 on hand; any issues with using that instead of an arduino nano? The processors are the same,
    I've yet to delve into this for lack of time, but I believe any 328P based arduino / clone will work. It looks like I'll need some zeners to test but I intend to try with a bare breadboard clone and a FTDI cable.

    Edit: one advantage to using a clone that lacks an integral usb>rs232 adapter is that the RTS line can be disconnected, eliminating the microcontroller reset caused when the serial port is opened by the client application.

  15. #15
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by spfautsch View Post
    I've yet to delve into this for lack of time, but I believe any 328P based arduino / clone will work. It looks like I'll need some zeners to test but I intend to try with a bare breadboard clone and a FTDI cable.

    Edit: one advantage to using a clone that lacks an integral usb>rs232 adapter is that the RTS line can be disconnected, eliminating the microcontroller reset caused when the serial port is opened by the client application.
    No zener? I just used a 9V battery in place of the zener supply for a while. The circuit is quite forgiving...

    -Tom

Similar Threads

  1. 1997 F-Body ECM
    By Tom H in forum GM EFI Systems
    Replies: 508
    Last Post: 01-19-2024, 11:19 PM
  2. Tools are good...
    By DavidBraley in forum GM EFI Systems
    Replies: 2
    Last Post: 12-05-2016, 05:46 AM
  3. 95 F-body Fuel Pump with 95 B-Body Engine/Tank
    By EPS3 in forum GM EFI Systems
    Replies: 7
    Last Post: 09-19-2016, 02:40 PM
  4. PRE efi tools
    By roughneck427 in forum Fuel Injection Writeups Articles and How to New and Old
    Replies: 1
    Last Post: 03-12-2015, 07:17 PM
  5. Good PCM Hacking Tools For OSX
    By Durahax in forum TunerPro Tuning Talk
    Replies: 0
    Last Post: 07-28-2013, 12:58 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •