Reply to thread

Hey great markup and glad to see that info put to good use!


Yes, you are correct, on the Legend ECU board it's almost as if accommodation are made for you to change the mode of the processor! I have successfully done this by simply cutting some jumpers in the top left hand of the board and rewiring the MD0 and MD1 pins vice-versa of how they were from the factory to gain access to MODE3.


I actually had some recent success with getting the entire ROM contents to run off-MCU. I had to hack the vector tables to get it to work though, and here is why... The I/O Controller onboard can be controlled from either the processor or the BACKUP chip. The ECU, when first powered on starts up in BACKUP mode, in where the I/O controller is controlled by the custom BACKUP processor (ASIC MCU chip IC501) which contains the bare minimum settings to make the motor run (AKA Limp Home). As the processor is booted (from the reset exception vector) if everything checks out, control of the I/O controller is taken over by the processor. If any problem is detected within the program (checksum error, timing error, etc) an exception is generated and it refers back to the vector table to know what program to run. This program sets a flag that puts the ecu into BACKUP mode. All of the error-based exceptions and unused exceptions refer to this program that puts the processor in a reset loop and hands off control back to the BACKUP processor. If the problem is somehow corrected the processor will re-take control.


I wired the external ROM to be active from 0000-BFFF by using another 2-4 line decoder (74HC139) piggybacked to the existing circuitry, changed the mode to MODE3 and wired the extra address lines to the ROM. I did this on the fly so I didn't update the schematic, but if you like I could. I stacked the MCU contents and the external contents to fit into 48K size (and filled the rest of the chip with 0's) into 0000-BFFF and uploaded it to the ROM. I was disappointed to see that the processor didn't boot out of backup mode. But ahah! I was getting a live serial port i could communicate with! So, on a hunch, I changed all of the error and unused exception vectors to point to the RESET routine instead of the backup routine and it booted! I installed the ECU in the car and was able to drive it around the block but anytime I tried to accelerate quickly the engine randomly bogged out, and reset again, and other random things happened. BUT, IT RAN off the processor and that's some progress!


I think the problem is one of the following, with the first being the most likely due to the random nature of the engine running.

* If you notice in the stock form, the chip decoder circuit is 100% symmetrical. The instant the ROM is accessed the I/O controller is off, and vice versa. When I piggybacked the extra decoder chip it sent the circuit asymmetrical which could be causing a bus fight for an instant. Not sure how to make a symetric circuit from scratch though.

*The internal ROM is accessed through 16bit data bus, while the external rom is limited to an 8 bit data bus. Might the 8 bit data bus be simply too slow to run the program?

*There could be an unrecognized watch dog timer program running within the ROM. I've verified that the built in watch dog timer circuits in the MCU are not utilized, though.

*I noticed in my research that the early 90's nissan 300zx's run two 32KB rom's instead of a single 64KB ROM and use a similar processor. Why did they do this? Did the 64KB rom not exist at that time or could it be possible that the highest page switch (A15) is simply too slow?


-Matt


Back
Top