I'm looking for some information pertaining to the address locations for the I/O on the 730/749.
I've looked at the schematics and have been staring at code and motorola info all afternoon and can't find the default address that indicates what input pin A3 or B3 would be addressed to. they look to be open and I want to use them.
Is there a listing somewhere that I missed?

You'll want to reference the schematics on Ludis' site ( http://www.cruzers.com/~ludis/1227749schematic.html ) to figure this out. Here's how I'd proceed :

First, go to the "Connector" section of the 7749 schematic. It shows A3 as "TPS2#" and B3 as "MAT2#".

Next, go to the "Passive Inputs" section of that page. Third column, second down shows the TPS2# going into a pulldown circuit. Fourth column, fourth down shows the MAT2# input going to a 1K pullup. This will be important to note relative to what you want to connect to these pins. Some inputs, like MAP2, have filters between the input pin and the A/D. This may or may not be a good thing for whatever you choose to put there....

Finally, go to the "I/O Expansion" section. U5 and U6 are the chips to find. TPS2 is located on the first input (X0) of the U6 chip. MAT2 is the 5th input (X4) of the same chip. U5 is the main A/D chip. You can see MAP, Coolant, Volts and TPS are on U5.

Now, you know where they're wired. All that's left is finding some code that will let you read these channels. Sounds easy, right.....? I'll show you how the 7749 does this. I'm sure there are similar (if not identical) instructions in the 7730.

You'll notice from the I/O page, the ESC is the 4th input on U6. The code that reads knock counts in the 7749 ECM is :

ldaA #$03 ; ESC Channel on Multiplexed A/D
call LFA35 ; Read muliplexed A/D Chip (ESC)
staA L017E ; ESC Counts

This chip is special in that it is multiplexed off of the 9th A/D channel in U5. So, the routine at LFA35 has to do two things. First, it selects the appropriate channel to pass through on U6. Then, it "reads" the 9th A/D channel on U5. I believe the ESC is the only input on U6 that's read in the stock application. In the code above, register A contains the desired channel number for the U6 chip (3 for "X3"). The routine at LFA35 takes care of the rest. The result is stored in the A register after the subroutine call.

As another example, I wired in my WBO2 signal into A3. Here's the code that reads the value (correctly I might add!) and stores the result in RAM:

ldaA #$00 ; WBO2 Channel on Multiplexed A/D
call LFA35 ; Read muliplexed A/D Chip (WBO2)
staA $0182 ; WB02 Counts

I should mention that this is different from what you'd do if you wanted to wire something into the MAP2 input (F14). Since this input is wired directly into U5, there's a different routine used to read it. (I believe this is the only "free" input on this chip.) This routine is the same as what's used to read MAP, Battery, Coolant, etc :

ldaA #$10 ; Battery Channel
call LF4B3 ; A/D read w/Interrupts disabled
staA L0051 ; Battery Volts A/D result

To read the MAP2 input, you'd change the ldaA from #$10 to #$00. Routine LF4B3 only reads the U5 chip inputs. It doesn't deal with the U6 chip.

Hopefully, this helps you on your way. I can't say enough about how much Ludis' site has helped me understand the hardware-to-software relationships like these. I can appreciate the feeling of staring at code/schematics for a long time trying to figure these things out! Let me know if you have any questions.

Thanks!.

Now how do you know that LFA35 is which input?.

The LFA35 routine is used to read all the inputs on the U6 chip. This includes :

TPS2 / Pin A3
F12IN / Pin F12
F11IN / Pin F11
ESC / Not sure exactly. Think it reads resistance only...
MAT2 / Pin B3
MAT3 / Pin E10
Fault1819 / Not sure....
E11IN / Pin E11

The LF4B3 routine is used to read all the inputs on the U5 chip :

MAP2 / Pin F14
Battery / One of the batt/ign leads to the ECM
O2 / Pins E14-E15
MAP / Pin F15
Coolant / Pin E16
TPS / Pin F13
Fuel Pump Volts / Pin E13
Diagnostic Line / Pin E12
MAT / Pin F16
10th input comes from U6 internal to the ECM.
(Quick edit : I know I said this was the "9th" input to the U5 chip in a previous post. But, it is, in fact, the 10th. Have to remember "$00" is 1st, "$10" is 2nd, etc. This makes "$90" the 10th input. Sorry if this caused any confusion.....)

This comes from straight from Ludis' schematics. I can confirm the TPS2/A3 pin since that's where I added my WBO2. And, all of the code lines up with the U5 pinout. I haven't confirmed all the other pins. But, I also have no reason to doubt them, either. Looking at the $58 source code, this routine is only called to read the WBO2 and ESC channels. I'm not sure if "Fault1819" is used in other applications or not.

I just took a quick look at the anht_hac_727 document. It appears the 749->730 routine equivalents are : LFA35=>LE2D4, LF4B3=>LF0D2. This hac shows TPS2 as an oil temperature sensor input. I wouldn't be surprised if different masks have input variations.

Let me know if you have any other questions.

Thanks a whole heap 1981TTA, :hail:
This will get me going in the right direction. I've read this 3 times but it will take me another 3-4 times to really digest the info.
I was using everything from Ludis's site as well to try to nail the adresses down but to no avail. I'll have to look into those filtering circuits to be sure the one I use will be applicable.

Again thanks for giving some really excellent info.
I'm sure I'll have more questions in the future on this.
Jp

Btw, My main goal was to input my Trans temp into TPS2 and trans pressure into the other.

So the LFA35 routine has to have a previously-specified MUX channel in order to read the input you want. Right? You can read U5 directly, but to read U6 you have to specify the input channel and then read it THROUGH U5 using the routine at LFA35?

Exactly!!

I see another use for this info.....
Modifying some of the masks to eliminate repinning mask swaps?????

May not totally eliminate it, but it would be a step closer......

Very interesting information indeed....

OK, One more quick question on this. I've got most of this down finally to the point of clarity.
I think I'm just being dense on this one but, the STAA to save the result does not have a "$" indicating a hex address.
The result for the oil temp is STAA L01BC.
There is no reference to the line in the hac.
Is this just a memory location that is called by the line number as a lable?
I was figuring it should be more along the lines of $01BC type of address if that was the case.
(same difference?)

BTW,
JP that is where I'm headed soon

It stores the value of accumulator "A" to that location (remember the equates when first getting the file to assemble?)
It then calls that location for the err code 52 and 62 routines. Therefore, the oil temp is for information only. Now I fail to see where the filtered A/D comes from. Is it handled in another loop?

I'm determined to get an understanding of this stuff!!!!

I have determined that either case could be used for the addressing of the stored A/D result.
The EQU is basically "labling" the $01BC address so it can be called by "name".
This may be for two reasons,
1.) to allow the programmer to keep track of dynamically used addresses.
2.) for means of "declaring" the adress space placeholder for the variable. Probably not the correct terminology for that but you get what I'm saying.
Not sure if #2 is needed for initialization or not (don't believe so)

I'm still not sure why all of the EQU exist at all if they are not for programmers reference.

There is a separate filtering routine. The ANHT shows how it works IIRC. Its at LE31C.
Jp

Please clarify if I've mistated the above.

The filtering function is called right after the A/D read :

LD121: BCLR L0043,#$80 ; CLR ERR 52/62 BIT

This part reads the A/D value:
LDAA #$01 ; SEL A/D CH 1, (OIL TEMP)
JSR LE2D4 ; A/D MUX READ
STAA L01BC ; A/D OIL TEMP RESULT

Next, oil temperature is determined from a lookup table:
LDX #$F116 ; OIL TEMP LIN TABLE
JSR LE3D0 ; 2D LOOK UP, NO OFF SET

Finally, the lag filtering routine is called to filter the oil temperature:
LDAB $83E8 ; OIL TEMP FILT COEF
LDX L01BD ; LINEAR OIL TEMP
JSR LE31C ; LAG FILTER ROUTINE
STAA L01BD ; SAVE LINEAR FILT OIL TEMP

In addition to the code 52/62 routines, it also appears to be used to disable A/C...?

As far as I've seen, the EQUs exist for programmer reference. The disassemblers probably don't do a good job of showing just how helpful they can be.

From our example, imagine how much more helpful the following might be :

OILTEMP_AD EQU $01BC
FILTOILTEMP EQU $01BD

When the LDAA/STAA operations are used, you'd "know" what they were supposed to have.

This is similar to what has been done for calibrations in applications like Promgrammer (sp?). Instead of refering to calibration tables as $Cxxx, they come up with a name. (Although I have to admit some of the names are cryptic at best. Then again, how much can you communicate in 8 characters..?)

To the assember/compiler, it really doesn't matter whether the EQUs are there or not.....

Makes sense to me......oil gets too hot, kill the A/C to reduce load on the cooling system. Fans will keep running based on coolant temp., and when everything cools down a bit the A/C can come back online. You only need one threshold because oil temp. doesn't vary fast enough to require hysteresis to prevent oscillation.

I believe some of them are mem locations for the aldl stream also. ie xx locations are called and spit out in the stream.

I'm trying to figure out how the data actually gets to a location for aldl use.

ANHT.hac starting at L88C4:
goto FDB $0094 10. a/d tps.
This is the tps % in the aldl stream. It's stored at location 0094h.
From the 8f hac:
If you look at the aldl def for the 8d,(a100.ds) you'll see that #10 is the a/d tps. Look at the ads file and the a/d tps is defined as 10. not 0094h.
So I'm missing a part of the addressing circle.

The reason for all this is so you can stick any address you want into the aldl stream. For instance the big todo about the 8d pw limit thread. The pw is stored in 2 different locations as the calc code is ran thru. Just monitor those locations to see how the pw is changed as the cal progresses.

Now that I've done the research to locate the info on the channels, I think it's pretty complete. I used all the info I could find from the hacs and the schematics on Ludis site.
These are checked against the wiring and the code references that I found as I'm commenting the AUJP.
The lookup routines are shifted in MY disassembly but they have been confirmed twice to be in the correct place.

I'm thinking the Fault 1819 recongnizes a digital output fault, possibly a dead shorted output ??
If anybody knows what that is I can stop looking.

I hope this helps someone else out there.
JP

Do you know how a multiplexer works? Basically the 3 channels (in a 3-8 mux) are a binary number that corresponds to the channel.

ie

001 means channel 1
010 means channel 2
011 means channel 3
100 means channel 4, etc.

Hope this helps.

My AUJP disassembly has the same shift.....the routine is located at LF0DA. Consider that a 3rd confirmation. I never noticed it as I haven't been making comparisons to the ANHT hac.

I just started commenting it a couple weeks ago, so I'm a bit behind you guys.



I do recognize the QDM though. U18, U19, and U20 are Quad Driver Modules (so called because they have 4 outputs each.) The quad drivers are grounding drivers which can be used to control relays and other such things....common failure points in GM ECM's from my experience. That line *should* stay high unless one of the QDM outputs shorts to ground.

FWIW DTC 18 and 19 are generic GM fault codes for the QDM's.....but apparently these codes arent used in $8D.

Thanks AlexJH,
It must be late, could you clarify that for me?
I'm getting MUX;d up.
I see the binary relevance of the channel numbers but do not see where the "MUXA, B, & C actually connect to the outside world.( no pins on the ECM connectors)
I'm thinking they are channels 8, 9, and 10 on the U6.
OR, are there only 8 channels on U6? (I'm betting thats why I'm cornfused)
With that info, this list is complete.

Those are held high or low to select the channel !!!
Thanks AlexJH, only took me a few to get my head on straight.

You might want to look here to get some ideas...

http://wasabi.dynu.com:8080/wiki/ind...60_Subroutines

Using 8 bit symbols makes things difficult to read. You could try the AS6811 V2.2 assembler. I think most people on this board are using the 8-bit version (v1.5-N that was compiled with a larger memory model). The V2.2 source is available and needs to be compiled with a large memory model for source files that have been commented. You will get "out of space" errors if you try to assembler a commented source file with the available AS6811 V2.2 executable.
You can compile AS6811 V2.2 with MinGW or MS-VC++ or any other C compiler. I recommed using MinGW & MSYS if you run Windows (any version). It works great........long descriptive symbol names.
You could also try GCC 68HC11 with the GAS assembler. It is good option if you prefer writing C code for patches and source code function changes.
Anyway, AS6811 V2.2 is worth a look.
J

I notice you are storing the WBO2 value at address 0x0182. On the 730 ECM, it maintains the stack using 0x01C2 - 0x1FF. Reading though the code, it looks like it never really gets that deep in the stack. So there is *probably* a lot of extra SRAM that could be used for storing stuff. Just seems like the stack is way deeper than it needs to be for the functions that are used by the ECM. I am guessing they set it pretty deep so that they never had to worry about it when they called nested functions.

What is the bottom of the stack on the $58 code? Are you taking advantage of SRAM that the stack never uses?

Man, I have to get around to building an ECM bench to test some of the theories out.

J

You're correct. I just started from the last used memory location in the disassembly. I haven't done a formal analysis to determine where the stack "ends". Like you, I ASSumed the stack wouldn't go that deep. Sooner or later, with additional RAM usage, this isn't going to be the case..... Between the bench and idling in the car, it hasn't caused any problems. You say that the 730 stack ends at 0x1C2. Is that from the hac or from analysis? To my knowledge, there's no explicit limit to the stack in the 749 code...?

I can't say enough about having a bench available for things like this. Regardless of how it's put together or the cost, it will pay you back big time in cases like this.

The stack in the $8D code goes from $01C3 through $01FF inclusive.

The stack in the $58 code goes from $0186 through $01FF inclusive.

The stack in the $88 code goes from $01DD through $01FF inclusive. Note that the $88 mask also runs in the '730 and is used in 3rd gens.

Stack usage is mask dependent, not ECM dependent.

RBob.

I will have to take another look at the $8D AUJP code. I swore the stack ended at 0x01C2. That is where the MCU writes a zero and later checks to see that it is still zero (check for stack overflow). HHHHmmmm, I guess that makes sense. The true bottom of the useable stack would be 0x01C3. 60 bytes of stack SRAM seems pretty large to me for the $8D Code.

I have been doing simple "printf"ing to the ALDL to use it as my main debugging tool. Cheesy, yes, but gets me by for now.

As simple test for seeing what stack SRAM is available can be done by modifying the "init" code so that a value other than 0x00 is written to the stack (e.g. 0xAA, or counter, or something)
Then dump the stack memory to the ALDL port and see where values were changed from the value that was used for the init.

Try a few different values just to make sure.

Got some 730 ECM connectors at the "yard" a few weeks ago. Just need a power supply to get the bench setup going. Anyone got a rough idea what the ECM draws for electrical current without any I/O connected?

J

Less than 1 amp, from what I've seen.

I just fired up the '730 on my bench, and it only drew 0.67A. That's using only LED's for outputs, rather than "real" stuff.

Thank you. I was hoping it was down around 400mA.....got a good 15V - 500mA wall transformer here already. Looks like I will be ordering a stiffer supply with the DACs needed for creating the TPS, MAP, etc signals.

J

In the $8D code, it goes like this:

register $4004, Bit 2 controls MUXA signal
register $4004, Bit 3 controls MUXB signal
register $4002, Bit 5 controls MUXC signal

register $4004 is bidirectional and register $4003 controls the direction

register $4002 is always an output

J

I'm having issues with reading the upper channels on U6.
I believe it is due to the channel number I am passing to the routine.
The list above for channel # works fine for U5.
References in the code seem to indicate that U6 will use just a # of the channel rather than the same format as U5, Passed directly to the MUX bits.
Channels 4, 5, and 7 are my main interest. They do not seem to read correctly with the U5 channel number passed to the U6 routine and have not worked using direct values 4,5, and 7.
Should they be $04, $05, and $07 ? (or offset for "0" channel, $03, $04, $06)

The channels for U6 are a direct number. It is not like the channel numbers for device U5.

For device U6:
0x01 -> channel 1
...
0x05 -> channel 5

Load the channel number and call routine LE2DC as done in the stock ANHT code. I tested all the channels when you asked about channel 4 a few months ago. All tested correctly on the bench.

Thx,
that's where I was going wrong.