I like to think of microtech as being the mentally handicapped ecu's. they do work extremely well at what they do and are very simple and plain.

 

yep, i like simplicity at times but the hardware is the largest issue and even the software. i can't save a map and tweak it while relaxing at home, nor can i plug in and reconfigure various sensors or switch around configurations which is becoming more and more a problem as people want to go beyond the stock limit of 20psi.

the narrowband input is beyond retarded though, and even that doesn't work right if say you have a LC1 converted to a narrowband output it doesn't read right even if you set it up properly.

people who didn't have foresight are stuck with what they have.

 

Microtech also flat out lied about supporting the ECU through software upgrades. We were supposed to get save to disc, wideband support, closed loop, etc. all later on. Fat lot of follow through they had.

It's also the other stupid "features" that have got on my nerves lately. The fact that I have to set my fan to activate at 90 degrees because there is a fixed 5 degree hysteresis and no option to set the off point like every other damn ECU in the world. If I set it to 88 degrees, the next available option, the damn thing always runs because the stock thermostat is 82 degrees! Stupid, stupid, stupid. My decision is about 90% made that once I'm finished with my Cosmo, I'm replacing the Microtech with a Haltech. I'd go MS3 but with 4 low impedance injectors, Haltech can run them without additional resistors.

 

i'll stick with the microtech in my car since it's there and still somewhat works but i doubt my next personal EMS will be one, that is unless we get some aftermarket support to chop these things up and turn them into actual tunable units.

 

for me, not-free isn't a showstopper. A C-Note might be steep for "a few bytes", but there is value in 'fixing' some the issues everyone has encountered and I, for one, would be just fine with fair compensation. (just my inner capitalist speaking)

- k -

 

Did you ever copy the firmware for old microtech ecu/lcd hand controller?

 

hello,

Can you send me the code you have for the microtech ecu's you have, thanks
jverban@hotmail.com

 

I've dusted off this idea recently because I have an MTX-8 that has become locked and I'm trying to work out the PIN. It is a real trap, a friend was messing about on the handset and loaded a map from a memcal which turned out to be locked, not just the "Prog" but the "ECU". This means that his engine now needs the PIN to start, which he does not have. You are unable to revert the change, or reset to default. Basically the ECU is now junk and it does not even warn the user.
The PIN #6 screen has a code: 35X79Y;=

I've contacted Microtech and provided the code to reverse the PIN. Despite it being 2021 and these computers are using 1990 tech, they won't email me the PIN and want AU$130 and postage each way to reset to default. I offered to sign a statutory declaration stating I have absolutely no interest in someone else's obsolete tune for an unknown car but they won't accept that and preferred that the user be extorted $130. It is a frustrating situation as ANY other device I have encountered has some form of reset button where the config can be reset by the user, but not Microtech.

I've used a piece of hardware I designed in uni to communicate with the processor. The key components on the circuit are the PLCC52 socket, the power supply, crystal, reset button and a MAX232 serial comms IC. It has been a bit of a blast form the past where I've been fighting off the feeling I'm getting dumber because I was initially drawing a mental blank on how to do this so I had to work it out again so I'm going to list the steps here for my benefit and maybe yours. Life is a bit more complicated because a lot of the tools won't run on 64 bit OS now.

The steps are:
1) pull the HC11 from the Microtech, which isn't straight forward as they are really jammed in there
2) insert it into the programming circuit
3) use a serial cable with RX, TX and ground on DB9 pins 2, 3 and 5. I'm not sure which way I had RX and TX, swap it if necessary. I used a 3.5mm stereo connector to connect to pins 13 and 14 on the max232
4) use program jbug11 (https://sourceforge.net/projects/jbug11/) to pull the firmware. In the jbug config, specify your comm port, the baud speed (9600), talker speed (1200),and critically tick "PC controls reset" as shown in the attachment. I used ECU type 811E2 though I'm still trying to work out exactly which ECU variant it is - as the numbers are scrubbed off the chip. It might be an E9
5) power on programmer, put the HC11 into bootstrap mode by grounding the mod_b pin and perform a reset
6) in jbug, select connect, select the reset button that is next to connect. After a few seconds the "talker" code should be echoed on the screen. This means the comms are working. This needs to work to proceed any further.
7) select button "save MCU memory to s19". You'll get asked the memory range to download. I went for 0000 to FFFF. Specify a file name and wait for 30 seconds or so for the file to finish saving.
8) Load the S19 file into a disassembler. As hwnd mentioned, I'm using IDA Pro 7.3, there is also an online disassembler https://onlinedisassembler.com/ which seems to work OK too.
9) This where I'm up to at this moment, trying to look at the code, work out the memory blocks that have been used so that the correct HC11 can be determined. I loaned my not-locked mtx8 to my friend, when I get it back I'm going to perform repeated code grabs with the lock feature activated with various PINS setup and see where the assembly code changes. Hopefully this will tell me where to look in the locked mtx8 code

https://cimg8.ibsrv.net/gimg/www.rx7...9c45bb4a75.jpg

 

I'm yet to find the PIN. On my own MTX8 I can set a pin, lock the ECU, grab the machine code and compare this to the code obtained from the same ECU without the PIN and lock configured.

I am able to see the user text PIN entry fields, but I cannot see the stored PIN.

The locked MTX8 is weird in that there is no data at b600 which is where eeprom is stored on the E9. My unlocked MTX8 has all sorts of data there.

So where is all the user configurable data (I.e. the tune) on this locked MTX8?

I'm wondering if there is an external i2c maybe 8k or 16k eeprom chip involved. It's hard to know as all the chip numbers are scrubbed off. The E9 only has 512 bytes of eeprom onboard which does not seem like enough space to store all the tune settings, particularly when matrix mode is involved.

The wiring of the ECU is setup so the the chip is running in normal single chip mode, it isn't expanded mode or special test mode because the levels on Moda and Modb are 0 and 1. I think though that this would still allow use of a serial eeprom chip, Dom clearly knows more about programming HC11 than I do!

As a next step in going to compare the code on my unlocked MTX8 when I change from Normal to Matrix mode and see if that causes the onboard eeprom memory at B600 to get blanked, the theory being that it has moved it all out to this serial eeprom chip, something like a 24lc16 maybe, which is something that was typical at the time these circuits would have been designed, early to mid 90s. It is an 8 pin chip and there are a couple of these on the MTX8 PCB around the processor.

I'm wondering what would happen if I transferred my unlocked processor into the MTX8 that is locked. Which config will it pick up? Can I then delete all the saved memcals? What would happen if the locked processor is reinserted, will it throw it's toys out of the cot if the expected config isn't there or would it just reset to default?

 

No PIN yet but I haven't had time to look at this much in the last few days.

I've just had a quick look at it again and did confirm something. On my own mtx8 (the one that isn't locked and on which I can set a PIN and check things and clear the PIN again) I did a test that updated the tune. I updated the air temp correction from all zeros to all 12 degrees. I then put the microprocessor back in my programmer and pulled the firmware. When I compared it to the baseline tune in Notepad++ the memory in the EEPROM region is updated as expected. The memory between B780 and B78F has been populated with hex C, which is 12 decimal, see attached screen snip.


https://cimg1.ibsrv.net/gimg/www.rx7...8b177e84dd.jpg

 

No pin yet. Looked at this again on the weekend. I think the processor is an HC11E20, not an E9. The reason is that it's the only processor I can find that has program space at address 9000. It also has a total of 20k program space in comparison to the E9's 12k. Otherwise the E20 is very similar to E9, and also E2.

I have experimented with swapping chips between main boards however nothing exciting happened. I tried to take a not locked processor configured in normal mode, place it into the socket of the locked mtx8, booted it up, enabled matrix mode, set and cleared the lock, and replaced the locked processor back into the socket however everything was still the same.

I also tried to place the locked processor into the not-locked mtx8 mainboard, booted it up and it was still a locked computer


https://cimg8.ibsrv.net/gimg/www.rx7...624271a324.jpg

 

I've spent some time this weekend looking at how things are wired up to the main processor and other features of the circuitry.
I've documented the various connections in the attached screen snip of a spreadsheet. The ICx column headings align with the labels on the PCB pictures which are also attached.
I'd very much like to identify IC1, it is an EEPROM I'm fairly sure, and is unusual in that pin1 is ground and pin 8 is 5V supply. Most other EEPROM 8 pin packages are 4 and 8.

I'm still unable to identify the PIN. The locked-ness follows the HC11 but what I do see when doing a code compare is that the Port C config changes, given what I have observed over the last couple of days how Port C is involved with the EEPROMs this sort of makes sense.

I'm fairly sure that the crank and cam trigger uses a pair of LM1815 chips which connect over to IC2/IC3 (unknown) and then onto HC11 port A pins from there.
The injector drivers are a 5 pin package CS453. From the spreadsheet it's interesting that to drive the 4 injectors, Dom has managed to use only 3 pins using logic of both rotor 1 injectors, both rotor 2 injectors , and then both secondaries, using Ports B4, B6, B7
The ignition uses VB921 which seems fairly common, Megasquirt used these at one point I think, and now run a BIP for this purpose. The four ignition drivers use 4 individual ports, Ports A3, A4, A5, A6
The crank and cam VR input goes via a 22k resistor to each of the 1815 ICs pin 3. The output is pin 12 on each and they both head over to unknown IC2 pins 1 and 3. IC2 communicates with HC11 on Ports A0, A1, A2

Port C is very busy and it is quite difficult to understand what Dom is doing here, it is very elegant. Along with 2 Port D pins, a lot of stuff is connected in parallel, the spreadsheet shows the detail. The 5 buttons (B1 doesn't seem to go anywhere), the LCD display, IC1 and IC6 all share these Port C and Port D pins. I'm guessing that each device is enabled in turn and read/written as there are a couple of these HC11 pins that only go to the one thing. Because Port C is also an AD converter port, I'm wondering if the button presses are read via an analogue voltage, the port is reconfigured back to read/write digital and the EEPROMs and display are addressed. IC6 is a serial EEPROM 93c86, and I assume that IC1 is also EEPROM though I cannot identify it yet.

If anybody has any thoughts about IC1 with it's unusual power and ground config please reply!

The E20 chip used in this system is one time programmable so I guess to answer the original intent of this thread, there is not going to be a way to DIY the firmware on a Microtech. It may be possible by purchasing a new, blank processor, or there is a EPROM version with a window that is UV erasable but I do not think that they're available any longer. This is why the gear needs to be continually returned to Microtech for upgrades, reconfigurations (for example to go from 4 cyl to rotary), the code cannot be changed so I'm guessing the cost is because they have to supply a new microprocessor every time. The E20 does have a small section of EEPROM, which is where the tune data lives - 512 bytes, and because it is Electrically Erasable, it can be user updated (via handset/laptop). How Dom has managed to run an engine on only 20k of code, with just 512 bytes available for all the tune data - which includes matrix mode - is quite impressive. As dated as a MTX8 is these days you have to acknowledge that Microtech did a lot with very little.




https://cimg8.ibsrv.net/gimg/www.rx7...5cf3710397.jpg
Pin interconnections microtech mtx-8


https://cimg6.ibsrv.net/gimg/www.rx7...5dcd0b248a.jpg
microtech handset



https://cimg9.ibsrv.net/gimg/www.rx7...fc590da1ae.jpg
microtech mtx-8 pcb

 

arran, I've been following your exploits with the MTX8 and looking forward to updates.

I do have to take some exception to that statement though. Is it that impressive? The old MC68HC908 in the Megasquirt 1 does an infinitely better job at 8MHz, 512 bytes of RAM, though 12K more program space at 32K.

The Microtech code is crude, crude, crude. Now obviously I don't have the source so I can't say how terrible it is for sure, but we can make some guesses based on how the device operates (ie. having to make the PC software emulate the hand controller via an adapter in order to claim "PC programmable!).

Also, my god, through hole construction! Even 15 years ago that was obsolete. Much higher cost to manufacture instead of a redesign of the PCB. Which I'd assume is a cost they pass on to the consumer.

Regarding the buttons, they may be analog multiplexed. Analog read the buttons which each have a different resistor value in series, and then swap the port to digital and use it as a bus. Neat, but largely unnecessary if a proper CPU was chosen and limiting to the user. We now understand why the hand controller is so damn slow.

 

This topic got me wondering. the focus of this thread was to explore the inner workings and limitations of the microtech ecu and whether or not upgrading the firmware would be possible.

i'm not a developer, programmer, or electrical engineer. many of these conversations i only have a modest understanding of.

what i'd like to know is if an external application can be developed to work around the microtech's fundamental hardware limitations?

my understanding is the programming software and usb adapter function as a gateway for programming the ecu. it's basically just an emulator for the handheld controler. data isn't stored remotely within the software, the tune file is simply viewed and edited by the emulator.

why not build a more expansive interface software that stores its own tune files? the data in the files would be a reference for a script that has control over the microtech software/emulator.

the simplified idea:

microtech can only display AFR data for the tuner to reference and make changes. whatever data is used to display the AFR can be captured. when running, the microtech knows what cell its referencing and that information can be captured, no?

if the AFR data and the active cell data are known can they be used as reference points and fed into an algorithm to achieve a targeted AFR?

again, i'm not a developer or programmer, or otherwise qualified in any way to answer these questions... what barriers, besides the specific knowledge and coding experience, are there to the idea?

clearly, it would have to be a robust package and take a lot of variables into account, but i feel like there is a creative solution hiding somewhere to circumvent the limitations of the hardware.

~Ray

 

something like this has happened with the Power FC, Xavier has at this point reverse engineered it, and then built a box to talk to it, and now has a thing that can run the PFC in real time.
its been really cool.

 

Really better off selling it and buying something with native capabilities from a time and cost perspective unless you want the personal challenge.

 

I completely appreciate that… I think the most respectful reply I can offer is that I drive an 85 Mazda RX7 with a 13B-REW in it - I take everything I do to this car as a personal challenge 😂