pcmhacking.net

Yeah, after looking at the waveforms, CPU ROM~OE is actually ROM /CE. It is asserted for both read and writes.

I've just wired up my FRAM to a memcal. I was reading through the datasheet and it says any assertion of /WE while /CE is low will ignore /OE. Tick!

Also, every read or write access coincides with a falling edge of /CE. Tick!

And last, the FRAM like any other SRAM needs a way to ensure /CE or /WE is held high while the supply discharges on power off. Using a power monitor IC like the battery backed stuff is one solution. Instead I've fitted a /WE pull-up charge cap. This keeps /WE pulled high until VCC decays down to zero - and long after. I've power cycled the ECU and even crowbarred the 12v to trigger an unintended write but so far all good! I have also written a new map and verified via TunerPro so it all looks good.

I had to physically tie /CE to /WE when copying 12P to the FRAM initially. I'll need to update the firmware on my Memcal writer to strobe CE with WE/OE. Not sure if this is done automatically on the commercial EPROM programmers.

So there you go, it is not a direct plug in replacement and requires additional discretes to make it reliable. More testing is required before it can be confirmed 100%. If DMA transfers are possible in the CPU then this FRAM will require additional logic to strobe /CE at clk speed.

All my stuff is point-to-point wired, and as I only needed the one (maybe another as a spare) I don't plan on producing any boards. In fact, If I knew a week ago what I know now, I would have just purchased VL400's NVRAM board. It would have saved me quite a bit in parts and time. We have some of those Dallas NVRAM's in operation at work with date codes almost 20yrs old - a solid track record!

festy wrote: The write timing diagrams don't show /OE at all, it looks like holding /OE low permanently is still within spec for writes?

/OE signaling isn't shown during a write because it should always be high.

If /OE is low during a bus write, there is conflicting data which causes high surge current and ultimately a port IO driver will fail, either in the CPU or in the peripheral. i.e. the CPU is writing all 1's (5v) and the EPROM is writing all 0's (0v) to the same bus, something is going to give.

There is a finite wait time between say, /OE falling and /WE falling - this can be measured - and this is where the conflict occurs. Most often the output driver will latch up, sink a lot of current and destroy itself. This is common in the old 74&4000series logic. If you didn't even have enough bypass capacitance they would latch up.

I've got a 1993 date code DS1230 here that's still going strong, even after spending the last 5 years disconnected

A lot of eprom programmers hold /CE low to improve speed, but some of the eprom protection boards used by chip tuners exploit that to detect when they're in a programmer and then return garbage data in that case. The other trick they employ is to swap a few data and/or address lines around so you can't just pop the eprom off the protection carrier boarrd and read it out directly.

The DS1245Y datasheet notes that if /OE is low during a write, then the outputs are disabled on the falling edge of /WE, so there's no conflicting data on the bus at the time of the write (assuming I'm reading that correctly).
Note 8 says "If WE is low or the WE low transition occurs prior to or simultaneously with the CE low transition,
the output buffers remain in a high impedance state during this period" so if they're simultaneous like in your LA cap, the SRAM's data lines shouldn't be driven at the same time as the MCUs?

Ill have to read through the datasheet of my cypress sram I was using. It had an issue with it. The DS / FRAM seems ideal for these memcals.

Oh the transitions weren't identical. My capture speed was only 4mhz. At 24m you can see it

I had a 1230 fail at the 6 year mark. Supplied by Kalmaker so assuming they were supplying genuine back n the day.

Any updates on the FRAM board?

I was under the impression that there was already one in development by a user/mod here?

I thought that was you that was doing that?

No we do the nvram type, if we need to update the design we will but genuine nvram chips are still available.