FRAM NVRAM Board

[BOGSTOCK Profile]

How do I get my hands on one?

[antus]

Im expecting the next batch in about a week. Ideally i'll get an online store setup but if time isnt permitting might just use the pm system until i can sort it out. I'll post details in the for sale thread soon.

[BOGSTOCK Profile]

Sweet, been after one for a while now so 100% get one. I'll keep an eye out next week but if u get a chance pm me when they are in.
Cheers bud

[j_ds_au Profile]

Read.JPG

Above is a typical read bus transaction. OE and CE are as measured on the EPROM's pins, the A15 is taken from the PCB as are the other signals.

The RW line is active much of the time because it is this signal that enables writing to other chips on the bus, not just our NVRAM. You can also see NVRAM /CS is not active during these writes. /OE is always active on the NVRAM. Also worth noting is that the NVRAM is only read when A15 is high, indicating it resides in the upper 32kbytes of addressable ROM Space (0x8000 - 0xFFFF). The 'E' signal is the CPU's enable or synchronisation signal. This is what we'll use for the FRAM.

write.JPG

In this snapshot, we can see a byte write to the NVRAM. A15 is high, indicating the NVRAM is being addressed. WR drops low to initiate a write and then /CE drops low to activate the NVRAM. The problem here is that /OE is still active.

This raises the question, How is NVRAM being written to when the waveforms are so far off the signaling spec.

Very interesting, but very strange.

The first thing that looked strange is the inconsistent E-clock timing. However, the MC68HC11F1 (which these ECU/PCM microcontrollers are based on) technical data says that the E-clock can stretch high if /CSPROG (that's the ROM chip select/enable signal) is configured for slower memories, and it can stretch low if the MCU is put in STOP mode. Nevertheless it seems implausible that the /CSPROG configuration would be continually changing or that the MCU would be STOPped for such very short periods of time.

The second thing that looked strange is that there are some cases where there are multiple E-clock cycles during an activation (low state) of /CSPROG (corresponding to access of the ROM), versus other cases where they are 1:1. There is nothing in the technical data to suggest that there can be multiple E-clock cycles within an activation of /CSPROG, such as perhaps consecutive reads from the ROM (or to put it another way, that /CSPROG can span multiple E-clock cycles). The behaviour would have to be consistent, supposing this were indeed due to consecutive reads from the ROM. Furthermore, there are (were) some EPROM's, such as National Semiconductor CMOS types, that would misbehave every few trillion cycles if their chip enable signal wasn't toggled for each and every read access.

The third thing that looked strange is the cases where /CSPROG deactivates (goes high) in the middle of the high portion of the E-clock. The technical data says that's impossible, an active /CSPROG state is maintained until just after (0-20ns) the high-to-low transition of the E-clock.

Finally, the technical data specifies, for the /CSPROG configuration settings, that the "Valid" timing is "Fixed (Address valid)". What this means is that it cannot be changed to the shorter "E-clock valid" timing. This means that the low width of /CSPROG should be much wider than just the high portion of the E clock, it should actually start about half-way through the preceding low portion of the E-clock.

So there are multiple issues with these waveform captures, based on the MC68HC11F1 technical documentation. One might think that a discrepancy may be due to this being a secret derivative of this MCU, so perhaps a bit different, but not this many.