MR_Loyale
-
Posts
1556 -
Joined
-
Last visited
-
Days Won
27
Content Type
Profiles
Forums
Gallery
Store
Posts posted by MR_Loyale
-
-
Can you flip it over and take a pic of the bottom?
-
Looking at it from a systems perspective, I cannot believe that the EPROM does not contain any of the controller code simply because of the economics of having to remask the 6301 at the foundry to fix a bug - which is what you would have to do if you used it in mode 7. Probably the EEPROM also contains table data as well.
Frankly, whether the EPROM contains table data or executable instructions is irrelevant at this point because in both circumstance, the EPROM must reside on an address bus in order to be read.
-
Yes, the sheet I uploaded seems to indicate single chip mode too. Maybe the EPROM is all tables?
But if you look at the memory map for mode 7, all memory (RAM and ROM) is internal. The rest of the address space is listed as"unusable" which means to me that you cannot put an 8K EPROM in that space. That is the contradiction. Can you try to trace some of the pins from the EEPROM back to pins on the 6301? That might give us a clue as to how they put this together.
The example given in the handbook appendices for a mode 7 application is dot matrix printer controller.
-
In regards to the post you made in the other thread, I believe the intent here is to gain access to allow tuning. If that is the case, the things we should be able to change are as follows (and this is from memory as I haven't tuned anything OBD1 in years) :
AFR table: This is the air/fuel ratio table based on RPM vs MAP or MAF (engine load).
Spark table: This is the spark curve, again based on RPM vs MAP/MAF.
PE table: Power enrichment. This function acts as an accelerator pump and is based on TPS vs MAP/MAF. It's how much longer the
injector(s) will pulse for when the throttle is stabbed to eliminate the dead spot.
OL ECT: Open loop engine coolant temp. This is the value at which the system goes into open loop and stops using the base maps
which will be stored on either a separate ROM or in the processor.
AFR: You can actually change the air/fuel ratio here from 14.7:1 to whatever you want. Generally, there's no reason to unless you are
trying to mix fuels, inject methanol or you're having trouble with a knock you can't get rid of.
Spark knock table: Also based on RPM vs MAP/MAF. This is how much advance the ECU removes when knock is detected.
There are some other tables and values to play with, but those are the main ones. Based on the physical engine design, I don't see more than a 10% gain in HP or mileage by tuning unless mechanical mods are made.
Wow. Love how the posting gave itself it's own indenting and sentence spacing. lol
Not my intent to tune anything at all but good information nonetheless. I mentioned you might want to peruse the ROM file to see if anything pops out as "tuner stuff" as you have put forth yourself as a tuning authority (or at least experienced) in OBD1 which no one else here knows about. You would be most likely to recognize something like that hopefully. We are simply collecting a bunch of facts about the ECU here at this point. It has a yellow connector, a Hitachi CPU etc. Given your stated experience, the hope was if you look over it, something might pop up. Many unrelated facts, when put together can lead to new discoveries.
I am finding it fascinating. I am geeky that way, you will have to get used to it. I would never have thought that my Subaru has something in common with a freaking radio shack computer from the 80s!
Would 8 K be overkill for OBD1 era basic engine control tables? I am thinking they probably did not have 3d tables and the like that far back as this was still new stuff back then. One table I think we should be able to find is the one with the fault codes.
-
P20 = pin 8
P21 = pin 9
P22 = pin 10
All 3 are tied high by 1.00K resistors.
Pin 7 [standby NOT] is wired directly to +5V
That would mean mode 7 (single chip mode). That doesn't make sense looking at the memory map for mode 7. That indicates NO external memory. We know we have an EPROM. What am I missing here?
-
MR_Loyale,
I don't know what they refer to the standard before SSM as, however I have an old 1992 OTC Scantool here I use occasionally at the workshop and I have been having a look at how it is set up in the Operations manual.
According to the handbook, Pre-88 Leone and XT/Vortex use a single communications line that must transmit and receive on the same line I guess (?) which is terminal #7 at the 17 pin diagnostics plug near the Brake Booster.
However after 88 it refers to using the same 9-Pin SSM Style connector plug for "88-90 Leone, 88-90 XT/Vortex, 89-91 Liberty", so maybe, just maybe, using that same RS232 setup you might be able to go into a late-ish model ECU. (Well, late Leone anyway)
I can get you pictures if you wanna take a looksie anyway.
Any chance you can scan that manual and upload the PDF?
-
Well, looking at pdf pg 179 note (2) at top, after reset, program execution begins at the address values stored in $FFFE and $FFFF (addresses are 16 bit). These are the last two addresses in the 64K memory space.
This is listed as RES (RESET eg what happens when it is powered off the on) in the vector table below:
Now depending on our mode (as explained previously) the vector map may or may not live on our EPROM, It may be masked into the chip from the foundry.
Let's assume the vector map is on our EPROM and validate it with a logic exercise. If it is on our EPROM, the then it has to be wired as the last 8K in the 64K memory space. Looking at the possible memory map modes that are configured by the states of P22,P21 and P20 the possibilities are (PDF pg 156):
Mode 1 - non-multiplexed
Mode2,4 - multiplexed/RAM
So from our ROM file we see FFFE has value DC and FFFF has 6F. Thus when reset, program execution starts at address DC6F, IF our EPROM holds the vector table.
That is the rub. If our assumption was true, the address at which program execution should begin would be DC6F. However if we are in one of the modes we assumed, then whatever address the execution begins should occur in our EPROM memory range which is E000 - FFFF. Since DC6F falls below our beginning address, I think our mode is not 1,2 or 4.
Confirmation should come when DaveT traces and or measure the states of P22, P21,P20.
If I am correct, then the modes left are ones which include factory masked ROMS and allow for 8K for our EPROM. This would leave mode 0 or Mode 6.
-
So looking at the hd6301 handbook beginning on pdf page 156 looks like there are eight possible configurations of the mcu that are set based upon the state (high or low) of pins 22,21,20 . The memory map is different depending on how these are configured.
Dave - can you visually look at those pins and see if they have a jumper high or low on each? Please report back to us. If you cannot be sure, you might be able to safely bench test this by supplying power and using a digital probe if you have one. These are going to be jumpers or hard wired.
Just looking at it though, I think we can eliminate mode7 because we know there is an external ROM and that mode makes everything internal only.
0,1,2/4 or 6 appear to be the only modes possible based upon the memory maps show for each mode. I say this because none of the other modes makes available an 8K or greater space, since our EPROM is 8K I think we can eliminate those mode. Tracing should confirm this.
-
MR_Loyale,
I don't know what they refer to the standard before SSM as, however I have an old 1992 OTC Scantool here I use occasionally at the workshop and I have been having a look at how it is set up in the Operations manual.
According to the handbook, Pre-88 Leone and XT/Vortex use a single communications line that must transmit and receive on the same line I guess (?) which is terminal #7 at the 17 pin diagnostics plug near the Brake Booster.
However after 88 it refers to using the same 9-Pin SSM Style connector plug for "88-90 Leone, 88-90 XT/Vortex, 89-91 Liberty", so maybe, just maybe, using that same RS232 setup you might be able to go into a late-ish model ECU. (Well, late Leone anyway)
I can get you pictures if you wanna take a looksie anyway.
Pics would be nice. This is intriguing because the section 2.6 (PDF pg 169) of the handbook does mention a built-in serial communications interface.
-
Hey fellas,
What an interesting topic! Its way above my understanding level, but i'm going to be following anyway.
MR_Loyale, in regards to a RS232 port, I stumbled upon an interesting site the other day when I was doing some Subaru Select Monitor research for my EJ22 swap. The site is here. http://www.alcyone.org.uk/ssm/protocol.html
Also check out the headings "How to build a PC adaptor" and "Eavesdroping"
That site covers how to make an RS232 connector to use a PC as a SSM, I would imagine with a bit of creativity and a donor harness you could rig it up to get into an ECU outside of a car, or alternatively find the SSM Plug on the vehicle and use that.
I have a 1986 Leone Turbo Auto (Australian edition of course) that I can whip the ECU out of to check out as well. Would be nice to get an archive of numbers and all that.
If I ever do EJ stuff, that is the site I will start at. Those ECU's are in a different league compared to these old school ECU's What was the precursor to Subaru SSM?
-
Also I want to investigate where in the address space the memory mapped I/O lives. Those will be key to finding the code that reads the TPS and CTS and such.
-
C'mon now. I was just pointing out what we'd need
. I used to have some experience in this, but that was many, many years ago and I'm way too rusty to even begin to take a crack at the code. The tuning portion is another story. I'm glad you have the expertise necessary to try because I really would love to see it done and my limited experience is nowhere near your level."If we shadows have offended, think but this and all is mended..."
Thats all good but I am still unclear as to what we are trying to do. So you might want to mozy on over to the ECU thread, download the hex editor and open up the ROM file. Starting browsing for stuff that looks "tuner like". If we have a running car and know this ecu works, we can get another UV ROM chip, alter our bin file, burn it into the ROM, change chips and see how it blows up. LOL.
-
Here is a fun fact, our old Subarus use almost the same microprocessor as the TRS80 Color Computer. Who ever used one of those? Raise your hands.
-
Here is another useful tool, a 6800 family disassembler. The disassembler takes as input a binary code/data image
file (typically a ROM image) and generates either an assembler source file or a listing file.Here is a link:
http://myweb.tiscali.co.uk/pclare/DASMx/
Reading through the instructions, it does claim to do Hitachi 6301. This is a command line tool folks, no fancy GUI for you! I will see if I can get a listing out of this, It also claims to be able to do code threading (eg identify regions of code rather than data).
-
Found a nice hex editor here:
http://www.handshake.de/user/chmaas/delphi/download/xvi32.zip
I have opened the bin file and I can see areas that are most likely data storage areas for settings of some sort as they have repeating values that would not be opcodes and operands simply due to their repetition. If we all use the same hex editor with rows arranged in a similar way we can discuss values at addresses using the same point of reference.
Here is what it looks like:
It shows an address for the first byte of the row in the first column. Next are 16 columns showing hex values for each byte. Finally an ASCII representation is shown in the right 16 columns. If there are any human readable strings, they will show up in the ASCII area (maybe Subaru or Leone or something).
-
Other ICs - Hitachi HD46520P 40pin DIP, right alongside of the processor.
NEC D449C-1 24pin DIP along side of the EPROM.
So far, I haven't been able to find any information on these 2.
The 6301 history ideas above make sense to me.
In the text HEX file, The leading :20 is ignored. using the first line as reference, the address is the next group of numbers, the 00 [first data byte] is 7F. Looks like 32 bytes per line.
I think the Hitachi HD46520P 40pin DIP is an A/D converter based upon searches for this I was directed to the spec sheets for the HD46508 which may be a substitute or one in the same family of "Analog Acquisition Units" as they call them:
http://kazus.ru/datasheets/pdf-data/3211033/HITACHI/HD46508A-2.html
Possibly this is used to digitize sensor inputs such as the TPS and CTS. Some following of the board traces to where they emerge to a connector may give a clue as we can identify the wires coming from both and their connector to the ECU box.
-
Looking at some documents from Hitachi regarding the processor, it apparently could be ordered with onboad eprom masked in at time of manufacture. So some of the actual coding may be onboard the processor chip itself, It would make sense though that any sort of car model specific stuff would be on an external UV erasable chip in case a bug was found, new regulations happened , recall etc.
Are there possibly any ports that may be a diagnostic port (possibly an RS232 used for QC)?
-
We should be able to identify subroutines by searching for JSR (jump subroutine $90) opcodes and their endpoints with the RST ($38)opcodes. This would help in delineating code regions from data regions.
EDIT: The disassembler claims it can do this for us.
-
This is a thread to track whatever we discover regarding ECU internal wiring / code / experimenting.
Dark color coating the external metal box. From an EA82 4x4 Wagon.
ECU is labeled:
22611 AA100
MECF-001
5Y14
The UV erasable EPROM is a Hitachi HN482764G.
8K x 8 28pin Ceramic DIP
The CPU is a Hitachi HD6301V1P
1MHz 8 bit 5V CPU I have the data sheet. Includes the Op codes.
Object code compatible with 6801 family.
What is the packaging of the HD6301V1P? Dual inline or square? Are there any other RAM or ROM chips? We may need to do some tracing on the address bus to the ROM chip to see where in the address space the ROM lives.
I suspect it is in the lower 8K as the 6800 starts program execution at address 0000.EDIT: Actually our processor gets it's starting address from the RES vector at the end of the memory map ($FFFE and $FFFF).
-
More evidence this may indeed be the same Motorola 6800 instruction set:
"After the 6800 project Bennett worked on automotive applications and
Motorola became a major supplier of microprocessors used in automobiles." -
Here is a nice little intro to 6800 assembly langauge programming:
-
This is a thread to track whatever we discover regarding ECU internal wiring / code / experimenting.
Dark color coating the external metal box. From an EA82 4x4 Wagon.
ECU is labeled:
22611 AA100
MECF-001
5Y14
The UV erasable EPROM is a Hitachi HN482764G.
8K x 8 28pin Ceramic DIP
The CPU is a Hitachi HD6301V1P
1MHz 8 bit 5V CPU I have the data sheet. Includes the Op codes.
Object code compatible with 6801 family.
Can you give me some more info on the txt output format of your reader? How many bytes to the right of the colon are the address indicators? Or is it assumed from address 0000? This is a critical detail.
-
So looking at this, I am thinking that the CPU instruction set is based upon the Motorola 6800. If this is true, there should be assembler/editor programs. Hitachi may have licensed this and produced their own chips.
Here is my reasoning for thinking this, please sanity check this out:
From the HD6301V1P datasheet, go to scanned page 63 (23 in your pdf reader) and look at table 8 where the opcodes are listed.
Then open this link for the Motorola instruction set
http://www.lucidtechnologies.info/6803_instr.pdf
I do a quick comparison of the accumulator A ADD instruction (ADDA) and it appears to me that they have the same hex designation in all the five addressing modes. Can someone else independently confirm?
Update: Came across this wikispace on the 6800 and it also lists a Hitachi 6301 controller version. I think Hitachi licensed the 6800 architecture and adapted it for industrial and hardened environments. They also added 6 extra instructions including a sleep (slp).
-
Here is the link to the 6301 series handbook with hardware, software techniques:
EA82 ECU experimenting
in Old Gen.: 80's GL/DL/XT/Loyales...
Posted
DaveT,
How hard would it be for you to backtrace the trouble code LED and produce a small schematic ? Either it goes back directly to the 6301 or it has some support circuitry that then goes back to the 6301. I am thinking this may be helpful in correlating the subroutine for trouble code output to some port addresses and since there are only 128 bytes of RAM we can potentially look for opcode references to the RAM address space to help us out. The trouble codes are the only data that is volatile and there are not any external RAM chips.
Does this make sense?