27C256 EPROM Emulator project

[DaWaN]

Recently I have been tuning a Honda car with an EEPROM burner.
This is a cumbersome process as with every change you need to stop the car and update the EEPROM.
To solve this there are quite a few EEPROM emulators which allow live updates to the emulated EEPROM for a PC.
You can buy the Moates Demon/Ostrich or the Hondata S300, but these cost well over 200$.
I was thinking of building my own EEPROM emulator, because I want to refresh my PCB / SW / HW knowledge a bit.
So please do not comment I can just buy something of the shelve: this project is for educational/entertainment purpose.

Technical details:
The Honda ECU uses an OKI 66207 microcontroller running at 10MHz.
The OKI 66207 reads the firmware from a 27C256 EEPROM (32kByte).
The OKI 66207 also uses an UART to send logging information.

For the PC side we need to provide USB. The tuning tool supports a few EEPROM emulators, all of which use a serial protocol.

So what I need to make is a device with a USB plug on one side and a 27C256 EPROM I/F and UART on the other side.
I would like the emulator to be able to change data while the 66207 keeps running.
This would be the biggest challenge I think.

I have already searched and found the following topic:

https://www.eevblog.com/forum/microcontrollers/looking-for-an-romram-emulator/

In the past somebody called "Obeny" also developed a similar device, but unfortunately his website is down.
If somebody still has the design files I would appreciate it if somebody can send me the files.

I already looked at the hardware used by Moates and Hondata.
The Moates hardware uses a Xilinx CPLD with an Everspin MRAM. Data is updated by an ATMega and USB is provided by an FTDI chip.
The Hondata hardware uses a Xilinx CPLD together with a SRAM. Data updating and USB is provided by a NXP LPC1768.

Now I am thinking about the following solution:
Using a STM32F0 for the composite USB device and data updating, Lattice MachXO2-256 device and 2x SRAMs like ISSI IS62WV1288DBLL-45QLI.
The SRAM has an access time of 45ns, so I theory it should be possible to write to it between the OKI fetching its instructions.
However, for the first version I can just put two of these chips on board and toggle between them (so update one SRAM while the OKI fetches instructions from the other).
As a later step I can improve the VHDL / Software and ditch one of the two SRAM chips.
Anything against this approach? Any comments on the MCU / CPLD / Memory choice?

Also I was thinking about a simpler / lower cost solution, using a dual-core MCU like the NXP LPC54114.
Then write some assembly code for the Cortex-M0 to emulate the EPROM.
However, I am not sure whether the <90ns access time can be guaranteed by design.
The M0 runs at 100MHz so you can tolerate 9 instructions, but I cannot find how fast the GPIO registers and SRAM are.
Also there might be a chance the M0 gets stalled by activities of the M4 on the shared bus matrix.
So this approach seems a little risky.

Or maybe somebody has an even brighter idea how to solve this?

[BrianHG]

If you seriously want to build your own dual-port rom emulator, get this IDT dualport ram chip:

https://www.avnet.com/shop/us/p/7007s55ji-3074457345625368033?CMP=EMA_FindChips_inventoryfeed_VSE

Wire one side as an eprom or sram IC socket, wire the other side to a MCU with USB or RS-232 port and read/write from there.
The only thing you need to look out for is collision, writing on both sides to the same address, or writing on one side while reading the other at the same address.  But, I guess this is true for any asynchronous dual-port ram.

The more insane way is to write FPGA code unless you are very familiar with doing so, dealing with the lower 3.3v IOs. not the 5v system of your 27C256, having the FPGA's rom side running asynchronously, clockless like a static ram, which makes it really slow to respond, and you still might end up using a MCU to interface with a PC unless you want to code all that as well within the FPGA.

Also, unlike the FPGA, the standby current is less then 0.2ma, with proper designing, which means an old rechargeable NiMH pc clock battery with proper diodeing on the VCC will allow battery backup of you data during power-down, or removal from the IC socket.

[Moshly]

Google "eprom emulator"

http://www.worldofspectrum.org/z88forever/eprom-emulator/eprom-emulator.html

http://www.piclist.com/images/boards/EPROMemuMk2/index.htm

http://www.baltissen.org/newhtm/epromemu.htm

or you could just get some 29f256 chips and use the programmer you already have.

[BrianHG]

Google "eprom emulator"

http://www.worldofspectrum.org/z88forever/eprom-emulator/eprom-emulator.html

http://www.piclist.com/images/boards/EPROMemuMk2/index.htm

http://www.baltissen.org/newhtm/epromemu.htm

or you could just get some 29f256 chips and use the programmer you already have.

Those emulators share each side by switching addressing and data during writes.  That's ok if the OT didn't ask to run his CPU simultaneously while editing memory contents without a potential lemon read going into his car's processor (let's see the car accelerate out of control here  ), or if the OT can pause his car's processor when updating the contents of the static ram.

[BrianHG]

The SRAM has an access time of 45ns, so I theory it should be possible to write to it between the OKI fetching its instructions.

You cannot guarantee the incoming address lines all time up perfectly parallel.  When you open/close that window time to switch from your read side to the write side, some address lines may be incorrect, or in the middle of transition unless you sync your AB dual port clock with the OKI CPU clock, and that cpu clock is properly synced with the addresses that are feeding the eprom, and you setup and hold the data you feed back to meet it's requirements.  With these unknowns, the IDT chip I mentioned earlier easily guarantees a uninterrupted response exactly like a 55ns eprom, including the OE and PD signals which the OKI CPU may use if the data bus is shared with other peripherals.

[Rerouter]

The simpler way i can imagine would be to have 2 eeproms, with a databus mux, one is connected to the ecu running along. you program one, then when the bus is idle switch. leaving the other free to program.

[BrianHG]

The simpler way i can imagine would be to have 2 eeproms, with a databus mux, one is connected to the ecu running along. you program one, then when the bus is idle switch. leaving the other free to program.

Still worse than my IDT dual-port ram chip.  It's a straight wire-wire solution, no switching ICs, no other logic. One side wired straight, no logic, to the eprom socket.  The other side wired straight to an eprom programmer, or, an MCU wired to a PC which is exactly what the OP asked for.  This is a 2 chip solution, the IDT chip and a MCU with enough IOs to write to a 32kx8 static ram chip, no cross wires, optional battery if the OP wants to retain data during powerdown which it seem he does not.

[BrianHG]

Here is a dual-port 64kx8 for even less:
http://www.questcomp.com/questdetails.aspx?pn=IDT7008L25J&mpid=224524126&pt=4

19.78$ us for 1.  Just short the high addressor to GND.

[DaWaN]

If you seriously want to build your own dual-port rom emulator, get this IDT dualport ram chip:

https://www.avnet.com/shop/us/p/7007s55ji-3074457345625368033?CMP=EMA_FindChips_inventoryfeed_VSE

Wire one side as an eprom or sram IC socket, wire the other side to a MCU with USB or RS-232 port and read/write from there.
The only thing you need to look out for is collision, writing on both sides to the same address, or writing on one side while reading the other at the same address.  But, I guess this is true for any asynchronous dual-port ram.

The more insane way is to write FPGA code unless you are very familiar with doing so, dealing with the lower 3.3v IOs. not the 5v system of your 27C256, having the FPGA's rom side running asynchronously, clockless like a static ram, which makes it really slow to respond, and you still might end up using a MCU to interface with a PC unless you want to code all that as well within the FPGA.

Also, unlike the FPGA, the standby current is less then 0.2ma, with proper designing, which means an old rechargeable NiMH pc clock battery with proper diodeing on the VCC will allow battery backup of you data during power-down, or removal from the IC socket.

That seems like a nice part, but price and availability are not great.
I prefer cheap over easy for this project.
At that price level I might even consider a FPGA with enough BlockRAM...

The simpler way i can imagine would be to have 2 eeproms, with a databus mux, one is connected to the ecu running along. you program one, then when the bus is idle switch. leaving the other free to program.

Still worse than my IDT dual-port ram chip.  It's a straight wire-wire solution, no switching ICs, no other logic. One side wired straight, no logic, to the eprom socket.  The other side wired straight to an eprom programmer, or, an MCU wired to a PC which is exactly what the OP asked for.  This is a 2 chip solution, the IDT chip and a MCU with enough IOs to write to a 32kx8 static ram chip, no cross wires, optional battery if the OP wants to retain data during powerdown which it seem he does not.

Depends how you define 'worse'. For the price of the IDT I can buy around 15x 1Mbit SRAMs, so using two SRAMs does not seem like a complete terrible idea.
Data retention is not really a huge issue, I prefer to swap out the emulator for a real EEPROM after the tuning is done.

You cannot guarantee the incoming address lines all time up perfectly parallel.  When you open/close that window time to switch from your read side to the write side, some address lines may be incorrect, or in the middle of transition unless you sync your AB dual port clock with the OKI CPU clock, and that cpu clock is properly synced with the addresses that are feeding the eprom, and you setup and hold the data you feed back to meet it's requirements.  With these unknowns, the IDT chip I mentioned earlier easily guarantees a uninterrupted response exactly like a 55ns eprom, including the OE and PD signals which the OKI CPU may use if the data bus is shared with other peripherals.

Yeah, that is indeed part of the challenge. I should start probing around on my spare ECU to see how things are timed.
I am not a complete n00b when it comes to FPGAs / VHDL and especially not when it comes to MCUs and C.
This kind of timing stuff makes it an interesting project for me. Reason for me to open this thread is to get some confidence in the HW design.
Not sure whether the data bus is shared, I guess not as all instructions are fetched from the EPROM.

Those emulators share each side by switching addressing and data during writes.  That's ok if the OT didn't ask to run his CPU simultaneously while editing memory contents without a potential lemon read going into his car's processor (let's see the car accelerate out of control here  ), or if the OT can pause his car's processor when updating the contents of the static ram.

The cars I will be tuning with this tool will have a mechanical throttle and manual transmission. There is no real risk of unintended acceleration. Stalling or blowing up the engine is more of a risk.

Here is a dual-port 64kx8 for even less:
http://www.questcomp.com/questdetails.aspx?pn=IDT7008L25J&mpid=224524126&pt=4

19.78$ us for 1.  Just short the high addressor to GND.

Still more expensive compared to 2x SRAM + CPLD + MCU.
I would also prefer to stick to Digi-Key / Farnell for parts.

[BrianHG]

Too bad they aren't available yet, but Altera's entry level cyclone 10 at 8$ 144pin EQFP would be all you need.  32k x8 dual port internal, RS232 UART direct on any free IOs with a little code to read and write to the internal DP-SRAM.  No MCU, no other logic other than a serial prom and maybe a RS232 to TTL level converter unless you are already using a TTL level RS-232 interface.  Logic wise, the chip would be empty.  And this is getting close to most of the other IC's and added PCB area all summed together.

[grantb5]

There is a guy/company in Poland, Momik, selling an emulator called MemSim2. It looks very good (isolated, etc) and great price, < $100 USD.  They are available on eBay and probably direct.

http://www.momik.pl/pdf/memSIM2.pdf

[SiliconWizard]

Don't know how familiar you are with FPGAs. I personally would do that with some FPGA which has enough embedded RAM to minimize parts. Unfortunately the MachXO2 line doesn't have more than 30 KBytes embedded RAM max (EBR), although you can probably instantiate the 2 KBytes additional RAM from logic cells. The Xilinx Spartan 6 line certainly has more than enough EBR for this (the XC6SLX9 for instance has 576 Kbits = 72 KBytes, so you'd have enough to emulate one EPROM, one other block for double buffering and some extra RAM for communication needs or whatever) and more than enough LUTs to implement the EPROM emulation + the communication part (with an FTDI USB chip for instance) and UART. That would be 2 main ICs with a few additional components.

[grantb5]

5v target?

[legacy]

on my EVS board, I have two EPROM emulators in parallel, another problem is when the target system is 16bit data width, and two UV-ROM need to be emulated.