Page 18 of 34 FirstFirst ... 8131415161718192021222328 ... LastLast
Results 256 to 270 of 509

Thread: 1997 F-Body ECM

  1. #256
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Kur4o --> OptiSim is finished for now. It works up to a point. I ran out of real time to run 6000rpm +

    Here is the code
    Attached Files Attached Files

  2. #257
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    In the OBDII version of LT1 ecms it is often necessary to check multiple DTCs are not set before setting a DTC. This is done to prevent a fault of a major resource from setting dozens of minor faults. Were this not done, the real problem might be obscured by dozens of smaller issues. This would make debug of the car way more difficult. I have a copy of the service manual and in many cases this issue is stated similar to this:

    DTC_Filter.JPG

    There are several routines used for pending and validated DTCs. Each has a mask table in the calibration section that permits the software to include/remove each DTC in the filtering. In the end, one call to the routine determines if any of the DTCs selected by the table are set and returns yes/no.

    I got tired of manually going through 144 (18 locations X 8 DTC per byte) each time I wanted to figure out a section. I threw together some C code to do this for me. One thing led to another and I added enough code that the output documents DTC mask tables. So I just call the app with the name of my binary file and the offset into the file, and it spits out all the detail of the DTCs enabled by the mask. For my code, I enclosed a sample of the output. I just cut and paste back into my source. Here is the code, rough around the edges but works.
    Attached Files Attached Files

  3. #258
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Some success on various fronts...

    I have tested both T & E side in bootstrap mode. The tester connector pins the same way for both and I have no problems running code on them. When I got the Tside up, I wrote some code to access the driver chips. In the system the Tside monitors all the fault conditions in the drivers and reports DTCs, sets/clears software flags for the conditions found.

    For a while I have been looking into limp home mode as it relates to some of the 28 pin plccs on the Eside. I have found that backup mode, commanded by the field service enable pin (blue 20) will cause this. You can use a 3.9K between the FSE pin and ground to command this.

    -Tom

  4. #259
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I have mentioned a test device in earlier posts and have had a bit better look at it...

    I believe that GM produced a test set used during development and proving. This test set attached to both the Eside and Tside 40 pin headers at the bottom of the two PCBs. The software is set up such that all the interface code remains in the production builds. I would guess this is done such that no changes creep in when transitioning to production. This offers both good and bad for those of us trying to understand their code. It is confusing when disassembling to see memory locations that are not associated with any devices. Also, there are locations that are written and never used by the operational code. Again confusion when trying to understand things.
    On the good side it would offer an opportunity for someone to re-create the test set for the purpose of tuning. Doing this would enable a faster turn on changes.

    In the '97 LT1 Eside code, the test set support is the first block you find above the calibration. Base address $3B87 and it carries on through $41BC. That is quite a big chunk of code. In addition to this, there are locations I mentioned earlier that are used only by the test set. Examples of this are all the locations that keep track of the runtime of interrupt routines, frequency of interrupt routines and so on... for example:

    1829/A INPUT CAPTURE 4 INTERRUPT SERVICE ELAPSE TIME
    182B INPUT CAPTURE 4 INTERRUPT SERVICE EXECUTION COUNT
    182C/D TPU INTERRUPT SERVICE TYPE $0400 ELAPSE TIME
    182E TPU INTERRUPT SERVICE TYPE $0400 EXECUTION COUNT
    182F/0 SPI INTERRUPT SERVICE ELAPSE TIME
    1831 SPI INTERRUPT SERVICE EXECUTION COUNT
    1832/3 REAL TIME INTERRUPT SERVICE ELAPSE TIME
    1834 REAL TIME INTERRUPT SERVICE EXECUTION COUNT

    I have not gone through all the code, but can see where the execution is transfered to code resident in the test set. I also see a number of places in the code where there is a test of test set presence and a test of status bits. The result of these tests conditionally updates test set variables.

    Way too many projects at the moment to spend time on this. Last thing to mention is that if someone were looking to add a feature and had no intent of using the test set interface, all this could be deleted for a gain of some 1500 bytes.

    -Tom

  5. #260
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    1500 bytes is a pretty decent chunk. Is it the same for T-side as well?
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  6. #261
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by NomakeWan View Post
    1500 bytes is a pretty decent chunk. Is it the same for T-side as well?
    I believe it is similar but yet to work through that side. I plan to get there...

  7. #262
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I am working through fueling, once again trying to understand aspects of the TPU. Started having a look at speed/density and trying to figure out the math. The intent of fueling is to inject based on the ratio of mass of air and fuel. All sorts of feedback from the engine are used to modify this, but the most basic thing is to figure out how much air is going in, and fuel based on a ratio. This all is my understanding and the starting point for...

    A standard formula for density of dry air is...

    Air density (KG/M³) = Absolute pressure(PA) / ( Specific gas constant for dry air (J/(kg·K)) * Absolute temperature (K) )

    In our case the calibration provides a constant which is related to the volume in ml. The code also contains a constant #$7480 which I hope to describe. Since we want to calculate the so called "cylinder ideal air mass", I messed with the formula as follows:

    Air mass (KG) = (Absolute pressure(PA) * Volume (M³) ) / ( Specific gas constant for dry air (J/(kg·K)) * Absolute temperature (K) )

    If I have done this right, we need just a few more things to get to the ideal air mass. First up is temperature in degrees Kelvin. In my PCM the A/D converter is fed an analog from the Tside which is temperature. Without going through all the code here, the system reads the ECT, interpolates it using a linearization table and saves a result which is charge temperature. I have not yet gone through all the places this happens, just one of them.

    So taking the charge temperature, the effect on volumetric efficiency is calculated through a table. The result of this is temperature (-40 TO 152 °C) * VOLUMETRIC EFFICIENCY VS ECT TEMPERATURE CORRECTION
    Notice the temp is in °C not °K. This is where the constant #$7480 comes in. This constant is exactly 128 times the scale offset between °C and °K less 40. By taking the temp*VE above multiplying by 128 and adding the constant the result is (°K * VE temp)/2

    Humidity also affects air density. Our system has no way of sensing humidity under S/D. I believe that our system has been designed with a nominal humidity and depends on things like O2 sensors to correct. Calibration gives volume as
    N * 8.961675624226406 in ml. I believe this is 2 * "Specific Gas Constant for moist Air". I am not sure of this but the numbers seem to work.

    With the above calculated and a value for MAP, the "ideal cylinder air mass" can be calculated. Ideal air mass is just the amount of air a cylinder would draw in if VE were 100%. From there VE is applied to determine the working amount of air, such that the fuel can be added.

    Ok so that is my level of understanding for now, I would appreciate your comments & corrections if necessary.

    -Tom

  8. #263
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by NomakeWan View Post
    1500 bytes is a pretty decent chunk. Is it the same for T-side as well?
    Had a quick look at this... Yes Tside is similar to the Eside. Test set routines begin above the calibration data at $4326 in my case. They run up to the start of interrupt vectors at $4C28. That is about 2300 bytes or so.

    As yet I have not looked through this to see if any of it is used by the operational code. I would not go and delete it without careful checking...

    -Tom

  9. #264
    Fuel Injected!
    Join Date
    Sep 2012
    Location
    Huntsville, AL
    Posts
    237
    I have often wondered if we could add a humidity sensor (and tables) to the code. The other thing I would add is fuel temperature. Makes me wonder if one could take datalogs and watch the fuel trims compensate for these.

  10. #265
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by sherlock9c1 View Post
    I have often wondered if we could add a humidity sensor (and tables) to the code. The other thing I would add is fuel temperature. Makes me wonder if one could take datalogs and watch the fuel trims compensate for these.
    Sensor could be added, but I am not sure what sort of sensor would work in an automotive environment. Do you know of any vehicles that have/use humidity sensor? I am not sure how the MAF handles this but as a guess this is a smaller factor and gets added to the error column. The O2 sensors and short term trims used to zero the error out. (?)

    I would like to find details of MAF operation, looks like I need to go digging.

    -Tom

  11. #266
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Quote Originally Posted by Tom H View Post
    Sensor could be added, but I am not sure what sort of sensor would work in an automotive environment. Do you know of any vehicles that have/use humidity sensor? I am not sure how the MAF handles this but as a guess this is a smaller factor and gets added to the error column. The O2 sensors and short term trims used to zero the error out. (?)

    I would like to find details of MAF operation, looks like I need to go digging.

    -Tom
    The new GM direct injection systems use a humidity sensor, e.g. 2015+ gen V trucks. Fuel temperature sensor is an option on 2004+ green plug PCMs and later ones, but it's an fuel VAPOR temperature sensor, and is used for EVAP.

  12. #267
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Quote Originally Posted by Tom H View Post
    Sensor could be added, but I am not sure what sort of sensor would work in an automotive environment. Do you know of any vehicles that have/use humidity sensor? I am not sure how the MAF handles this but as a guess this is a smaller factor and gets added to the error column. The O2 sensors and short term trims used to zero the error out. (?)

    I would like to find details of MAF operation, looks like I need to go digging.

    -Tom
    It's my understanding that humidity is only relevant for SD operation; if you're using a MAF, it's automatically compensated for because, as the name implies, the sensor is measuring the mass of airflow--and thus if the humidity changes, that mass changes, and the sensor will read accordingly.
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  13. #268
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I took a deep dive into the way that the MAF signal is processed. This took some time and it is quite involved. At first I found the approach the software took as strange. As I re-wrote bits of it I came to understand why it was done that way. Here is my best understanding of the way the MAF system processing works.

    Looking at the schematic, the circuit used to receive and protect the MAF signal is quite standard. The first element in the Input from the MAF is a capacitor. Value and parameters of the capacitor are not known, but it is similar to other 0.1uf capacitors and is marked on the schematic as such. This capacitor shunts static to ground, hopefully protecting the PCM. A 1.2K ohm resistor defaults the MAF signal to high should the circuit be open. The input then passes through an RC filter which also raises the impedance of the signal. A combination of an input resistor and a feedback resistor ensure a level of hysteresis to prevent oscillation. The LM339 references the input to a 2.5V bias. The output drives the TPU on pin 21.

    Location $14E8 of the TPU counts the number of transitions from high to low that occur at the MAF input. Each time there is a falling edge transition, a few things happen:

    - The count in location $14E8 is incremented
    - A count of the number of TPU clock cycles (Eclk/48) since the last falling edge is added to location $1468

    Note that other locations ($1448 and $1488) are used to hold temporary counts.

    In software there are a few conditions that need to be addressed. If software reads these counts *just* as they are being updated the count of cycles and the time stamp of the cycle may not match. The software works around this by reading, wait for a delay, re-reading the count of cycles. If there is a change in the number of cycles, it then re-reads the time stamp. Commented software is below for your interest.

    From there, a division provides an offset into a table. The software interpolates the air flow from that lookup. The value you read in the time stamp less the previous time stamp divided by the number of cycles gives you a count of TPU clock cycles for each cycle of the MAF. This is proportional to the air flow.

    Sort of hard to explain in words... commented code will help.

    -Tom
    Attached Images Attached Images
    Attached Files Attached Files

  14. #269
    Fuel Injected!
    Join Date
    Nov 2017
    Location
    Californiacation
    Age
    57
    Posts
    811
    Hi Tom, great research. I haven't looked at your data yet and will when I get a moment. Just a quick reply that the gm engineers that worked on this have always done "crc" checks while the code is running, even so far as testing writes from the outside. The gm guys were always ahead of the curve, pretty awesome :)
    -Carl

  15. #270
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I am going to set the airflow calculations to one side for a bit, but before I do: Someone mentioned in a post that I can't find now, that air flow is calculated differently at high rpm. I have confirmed this...

    I have gone through the calculations of MAF frequency using the TPU. It seems that the faster the engine turns, the fewer cycles of the MAF are used for calculation. As fewer MAF cycles are used the error builds. To fix this I believe GM engineers changed the frequency that the MAF is sampled at high rpm. From the code what I see is that above 4700rpm the MAF frequency is calculated only once per revolution. Below that the frequency is calculated each cylinder or 4 times per rev. I plan to get back to air flow later, but for now I want to examine spark knock system.

    On to looking at knock

Similar Threads

  1. 94-95 LT1 $EE Y-body vs. F/B-body PCM differences
    By johnny_b in forum GM EFI Systems
    Replies: 5
    Last Post: 01-15-2023, 02:41 PM
  2. Tuner Pro XDF 1999-2000 F Body + Y Body
    By john h in forum OBDII Tuning
    Replies: 33
    Last Post: 02-02-2020, 11:12 PM
  3. Replies: 31
    Last Post: 09-20-2018, 06:00 AM
  4. F-body engine install to B-body
    By serge_an in forum GM EFI Systems
    Replies: 4
    Last Post: 09-22-2016, 02:51 PM
  5. 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

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
  •