EPROM Emulator Proposal

Ludis Langens ludis at cruzers.com
Thu Apr 8 09:52:01 GMT 1999


David A. Cooley wrote:
> How about a couple Dallas Semi DS1230Y NVrams that are updated at the PIC's
> leisure when it's not updating the DPRAM.  When the unit is powered back on
> (IE restarting the car), the NVrams are read into the DPRAM so a battery
> backup isn't needed... the othe roption is EEPROM instead of DPRAM

The reason to use DPRAM is to eliminate a huge number of muxes.  The win
that DPRAM gives here is enough to afford the loss of adding a separate
battery back up.  I believe that the NVRAMs are simply SRAMs with a
battery in the same package.  We can do the same thing externally - the
DPRAM standby power usage is very minimal.

The emulated ROM needs to contain valid data almost immediately after
power up.  There isn't enough time to copy data from elsewhere.  That's
why the DPRAM needs to be battery backed up instead of copying from
EEPROM, FLASH, or NVRAM.

Actually, at first power up, it may be possible to have the PIC stuff a
short stub into one bank of DPRAM.  This stub will make the ECM ponder
it's navel while the PIC copies the EPROM (in the piggyback socket) to
the other bank.  I don't guarantee that this feature will be possible.

> Shouldn't that be A15 for bank select?

Normally you'd expect to use the highest RAM address line for bank
selection, but DPRAMs come in a variety of pin compatible sizes.  Using
the lowest address line allows for any size of DPRAM to work in this
circuit with no hardware changes.  For example, someone doing only SyTy
work could get by with a smaller RAM.  The extra EPROM upper address
bits will be ignored by the small DPRAM (while our bank select is safely
at the low end.)

> Boards will be about the same cost ($50 each for beta,
> 25-30 each for qty 10 in production).

Does that $25-30 price apply to a board smaller than 2.6" ('727 limit)
by 5.5" ('165 limit)?


Andy Quaas wrote:
> > Someone else will need to draw up the power supply
> > circuitry.  
> 
> 5 volts?

Yup, 5 volts standby for the DPRAM.


Steve Ravet wrote:
> Lets make the banks an option.  They're useful for storing multiple
> images, but if a single bank is allowed then the 64k chip emulates to up
> 27512.  The PIC will have to watch for collisions on writes and repeat
> them if necessary.
> It's mostly a software issue.

At the speed that collisions come and go, software can't handle them. 
Besides, the reason for two banks is not to avoid collision problems. 
It is to avoid incoherent ROM images presented to the ECM.  For example,
say you changed two tables.  If the ECM sees just one changed, it may
puke.  The emulator needs to download both before switching the ECM's
ROM image.


Tom wrote:
> I'd like to suggest that a pushbutton
> switch be part of the design that can be used to reload the default dpram
> bank from the eprom (assuming it's present) so that you can recover from a
> corrupted ram image without using a laptop computer.

This could be an automatic feature.  If we make the PIC powered during
standby, it could retain a checksum of the DPRAM.  When it wakes up, and
the RAM checksum doesn't match, it could copy the EPROM over.

> Maxim (www.maxim-ic.com) and others make parts with voltage supervisors
> specifically for memory protection (let me know if you want specifics). 

Could you look this up?  I've got a Dallas book here, but none of their
parts will work for a 5V standby.


Tom also wrote:
> Often, chip selects and write enables are active low.

The DPRAMs have two chip selects, one active low and one active high. 
Both need to be at the proper level to access the chip.  We can use the
active high in the power monitor circuit.


Andy wrote:
> Wouldn't just the CS/CE on the DPRAM would need to be
> isolated during the power cycles?  If no CE, no write,
> correct?

During power down, all the other inputs need to be kept at a power
supply rail voltage, usually ground.  We'll need pulldown resistors on
all of them.


Terry Kelley wrote:
> If the emulator is powered externally (many are powered by the ECM), then
> the ECM is irrelevant.

I think we want to normally power the emulator from the ECM, this should
simplify our power supply.  But we do also need a power connection for
use during in-circuit PIC programming and on-the-desktop RAM downloading.

> The problem is the off bank with be behind one edit, so it will need to be
> updated right after a toggle with the new bytes.

The PIC could do this automatically or by command.  It has full access
to both banks at any time.  After a switch, it can read the fresh
(active) bank and copy it to the stale (inactive) bank.  This allows
future updates to be fast because only the changed areas need to be downloaded.


Terry Kelley also wrote:
> Unless everyone is intending on having an active circuit running for a
> "fake" prom, this is a better solution. Edit on the pc and burn a final
> eprom.

I'm not sure what you're getting at here, but, the main reason for the
battery back up is so that the DPRAM is ready to go immediately upon ECM
power up.  Any other benefit is extra.


Tom Sharpe wrote:
> I don't have a MEMCAL, just a 28 pin xxc256 EPROM (in my proflow). Please add
> to the schematic.

That's the reason for a 28 pin DIP header in parallel with the MEMCAL.

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/




More information about the Gmecm mailing list