Has anyone replaced HP8591(E) SRAM by FRAM?

[MarkL]

I had mentioned this experiment to readout the SRAM using the "mbrd" command:

  https://www.eevblog.com/forum/repair/has-anyone-replaced-hp8591(e)-sram-by-fram/msg5786259/#msg5786259

In working on something else, I had a moment to try it on my 8595E.  It gets almost all of the SRAM except for the very last block of data and causes the system to hang.  I can hear the attenuator clicking, so I think the the SRAM module is overlapping with some of the I/O space, or maybe I have the addresses wrong, or mbrd is doing something unexpected.

At any rate, if you were thinking about it, just saving you some time not to bother.

[Miti]

Thanks Mark! No, I won’t bother, I go hardware.

[Miti]

Here's the final schematics and board for the FRAM and programming adapter, please take a final look. I will wait until the weekend to place the order, just in case somebody catches something that I missed.

Thanks,
Miti

[MarkL]

Yum, test points everywhere.  Should be interesting...

[Miti]

Boards are on order. Now I can focus on another project out of 25 currently in the pipe. 

[Miti]

Ok, I received the boards for the FRAM adapter and the programming adapter and I've assembled one of each. Three bad news and a good one
The bad news first:
1. The FRAM boards look like s..t! The prog adapter is ok. I've used water soluble paste, I like my boards clean, and if I don't use parts that cannot be washed, I prefer water soluble. Until now I had no issue but this board looks stained after wash.
2. TL866II Plus supplies about 4.5V instead of 5V and the supervisor holds everything in reset. I would need to disable the supervisor if I want to use that programmer.
3. I've tried Xeltek SP5000, 5V is ok, programming seems to go ok.... buuut when I read back it is not. I filled the first part of the buffer that corresponds to LB with 0x55, and the second part that corresponds to UB with 0xAA. When I read back the LB is all FF, which tells me that it does a 16 bit write and overwrites the first part, the programming adapter pulls the unused data inputs high. That means that changing LB, UB after CE or WE goes low is ignored, so I cannot get away with a single chip.
I'll do more tests but that's the only explanation I have for what I see at this moment.

The good news now:
The winter storm ended. 

Cheers,
Miti

[Uup]

Actually, your reasoning is sort of right.

Your reasoning for the failure is on the correct path, however, the cause is not.

The reason why it is not working is because you have a logic error, or mistake, in your schematic.

Take a closer look at the upper address line (A18) and you will see your error.


edited poor grammar

[Miti]

Actually, your reasoning is sort of right.

Your reasoning for the failure is on the correct path, however, the cause is not.

The reason why it is not working is because you have a logic error, or mistake, in your schematic.

Take a closer look at the upper address line (A18) and you will see your error.


edited poor grammar

I don’t see it. Can you please elaborate?

[Uup]

I don’t see it. Can you please elaborate?

There is an I/O logic error with A18. Take another look… and think about I/O

Perhaps the notion where ‘the ability to see a mistake is inversely proportion to the amount of times it is checked’ applies here.

I haven’t read this thread but was curious and wanted to help with troubleshooting, so looked over the schematic.

It must be why the error stood out to me and not to you, since you’ve looked at it so many times and I looked at it for the first time.

[Uup]

Here’s another clue.

I/O

A0 / MA1
A1 / MA2
A2 / MA3
...
A18 / ?

[Miti]

Here’s another clue.

I/O

A0 / MA1
A1 / MA2
A2 / MA3
...
A18 / ?

Ah, exactly what I thought. There’s no A18 on the FRAM board. It is only used to read/ write the 16 bits memory in two chunks of 8 bits. When A18 is low I access the LB, when it is high I access the UB. No error in logic there. Also, the address lines are not I/Os. From the memory perspective, they’re Is only.

[Uup]

Ah, exactly what I thought. There’s no A18 on the FRAM board. It is only used to read/ write the 16 bits memory in two chunks of 8 bits. When A18 is low I access the LB, when it is high I access the UB. No error in logic there. Also, the address lines are not I/Os. From the memory perspective, they’re Is only.

You wrote above "when it is high" but...

A18 is all input. There is no driver or source signal for A18.

Since you don’t see the error, then perhaps the error is with me and I’m interpreting your schematic incorrectly?

I just took another look at your schematic and there is no driver source for A18.

Every other (used) input in the schematic has a corresponding driver source, either from the header or from a device, with the exception of A18.

What is the driver source for A18?

[Miti]

What is the driver source for A18?

Same as all the other address lines. The header, the programmer.

[Uup]

Same as all the other address lines. The header, the programmer.

That's not in the schematic.

What pin on the header is connected to?

[Miti]

That's not in the schematic.

What pin on the header is connected to?

Ok, I think I know where the confusion comes from. The schematic that you attached is NOT of the FRAM module, it is the programming adapter, an interface between a regular programmer, such as TL866II Plus, Xeltek, etc. to the FRAM module, and it's intended to copy the content of the battery backed RAM module used in the HP859x spectrum analyzers into the FRAM module. First picture in reply #77. U1 is just a header, not the memory itself.

[Miti]

Here are the first scope screen shots.
The first thing that I see is that the 3.3V takes its sweet time to stabilize, about 7mS to be precise. It is less than 1V when RESET line LPF is released, so the entire safe power up sequence U9, U12 does absolutely nothing. I'll have to replace the supervisor with one that has a longer delay, or try an AP2204K that I also have, hoping it is faster.
Second, the 74LVC series are super fast! I was calculating using the maximum Tpd, I should have used probably the minimum.
The entire difference in delay between LLW/ LUW to WE and LLW/ LUW to LB/UB is about 5nS. So there's a hope that a longer delay on LB/ UB would make it work...maybe. Another order from Digikey or LCSC. 
Please see the attached pictures.

[MarkL]

Here are the first scope screen shots.
The first thing that I see is that the 3.3V takes its sweet time to stabilize, about 7mS to be precise. It is less than 1V when RESET line LPF is released, so the entire safe power up sequence U9, U12 does absolutely nothing. I'll have to replace the supervisor with one that has a longer delay, or try an AP2204K that I also have, hoping it is faster.

LPF doesn't control RESET.  LPF only goes to the RTC.  RESET is controlled by HPWRUP coming from the power supply.

It looks like the 3.3V is stable before any activity starts in Power_Up.png.

Second, the 74LVC series are super fast! I was calculating using the maximum Tpd, I should have used probably the minimum.
The entire difference in delay between LLW/ LUW to WE and LLW/ LUW to LB/UB is about 5nS. So there's a hope that a longer delay on LB/ UB would make it work...maybe. Another order from Digikey or LCSC. 
Please see the attached pictures.

Why is /CE always low?  Are the scope captures not zoomed out enough?

/WE (or /CE) going high should be ending the write cycle.  That's where everything needs to be stable.

Why do you name one of your captures "Writing_LB_Fall.png"?  What's failed?  In the datasheet, Write Cycle Timing 3 allows /WE going low to preceed changes in /UB/LB.

More importantly, does the analyzer boot?  Does it say anything?  Are any of the DS1 thru DS16 status LEDs lit?  (These LEDs are not populated on all boards, unfortunately, but the pads are there, near U57.)

[Miti]

LPF doesn't control RESET.  LPF only goes to the RTC.  RESET is controlled by HPWRUP coming from the power supply.

I meant local reset on my board, not system reset.

It looks like the 3.3V is stable before any activity starts in Power_Up.png.

Yes but not before LPF, which also acts as local reset, goes high.

Why is /CE always low?  Are the scope captures not zoomed out enough?

/WE (or /CE) going high should be ending the write cycle.  That's where everything needs to be stable.

These scope shots are from the programmer, not from the SA. That's how the programmer works.

Why do you name one of your captures "Writing_LB_Fall.png"?  What's failed?  In the datasheet, Write Cycle Timing 3 allows /WE going low to preceed changes in /UB/LB.

Falling edge and rising edge of WE.

More importantly, does the analyzer boot?  Does it say anything?  Are any of the DS1 thru DS16 status LEDs lit?  (These LEDs are not populated on all boards, unfortunately, but the pads are there, near U57.)

I haven't tried yet. I want to see it running with the programmer first.

[MarkL]

...
These scope shots are from the programmer, not from the SA. That's how the programmer works.

Sorry -  guess I missed that.

[Miti]

I wanted a way to validate the layout, the concept, so I programmed an FRAM externally with 0x55 the LB and 0xAA the UB. Then I installed it on my board and read it back. The result is exactly as I expected, 0x55 in LB, 0xAA in UB. This means the layout is Ok and more reasons to believe there's something illegal about LB/UB change after WE falling edge or not holding enough after rising edge.

[Miti]

More importantly, does the analyzer boot?  Does it say anything?  Are any of the DS1 thru DS16 status LEDs lit?  (These LEDs are not populated on all boards, unfortunately, but the pads are there, near U57.)

It does this, I forgot to look at the LEDs  . Does it need to be initialized? Are the characters stored in the RAM? If the battery and the supercap die, are the calibration constants the only things that we lose?

Cheers,
Miti

[MarkL]

Well, that's good sign that it boots!  It wouldn't get very far if the FRAM wasn't performing its duty as the system's SRAM, at least partially.  Even though garbage is being displayed, does it respond to any controls?  Can you talk to it via GPIB?  Is anything working?

I asked about the LEDs because there are some low-level checks performed at boot on the various buses, SRAM, ROM, etc., and results are displayed on the LEDs.  If the FRAM wasn't working right, the unit should fail the SRAM tests (at a minimum) and the LEDs may provide clues.  See page 632 in the Assembly Repair Manual for detail on the LEDs.  If you don't have the LEDs populated, maybe just run down the pads with a pair of probes attached to an LED.

"Characters stored in the RAM"?  No, not that I'm aware.  Maybe the FRAM card is interfering with the video controller bus access?  Or interfering with a region of EPROM where the characters are stored?  The video controller has a DMA controller in it, but HP is not using it in these units.  It's all memory mapped I/O for the processor to talk to the video controller.

There is an initialization procedure in the Assembly Repair Manual on page 204.  Even if you can manage to navigate through it, I don't think it's going to resolve the garbage.

If the battery dies, yes, the calibration constants are gone, which are the most important thing.  You're also going to lose DLP's, stored setups, traces, variables, video setup, display units, serial number, and possibly the model number.

For the calibration constants, Tom over on HPAK io.groups has developed a GPIB utility to restore them using the output from "CAL DUMP":

  https://groups.io/g/HP-Agilent-Keysight-equipment/message/149983

If you manage to get control of the unit, you could grab a "CAL DUMP" snapshot from your old SRAM and restore them to the new FRAM after doing the initialization procedure.

[Miti]

Bingo!
Dead bug working! 
My first instinct to delay /WE was correct. Once I've moved the /WE after the /LB, /UB, all the stars aligned. I copied the RAM into FLASH and everything is there.
It woks fine for more than 30 minutes.
Back to the drawing board to add the flip-flops. I will also change the package for U3, U4 to TSSOP because what I have now is smaller, but not readily available.
Meanwhile I've also laid out the two chip version. I may clean up and order that version as well.

Cheers,
Miti

Edit: Oops, looks like I need a diode series with the battery. The clock wasn't showing up and I figured out that it was charging my battery, I assume through the RTC interrupt line and R105. I'll think a bit about the circuit around the battery. A Schottky diode has too much reverse current, a silicon diode has a high forward voltage drop. I may need a more elaborate circuit in that area.

[Miti]

Hey Mark,

I think lesson learned from here is, /LB and /UB are latched, most likely on the falling edge of /WE, any change after that is ignored.
I don't understand why they don't mention this in the data sheet and we need to discover it the hard way.

Edit: I've added some new scope screen shots. I need a faster clock, somewhere around 30 to 33MHz may be ideal, now I'm using 25MHz.

Edit1: Wait, cannot be latched on the falling edge of /WE, at least not in the /CE controlled cycle. Are there different rules in /CE vs /WE controlled? 

[MarkL]

Interesting that a delay on /WE makes this work.

Without the delay added, granted the design is not explicitly represented in the timing diagrams, but at the same I don't think violates any timing specifications.  Plus the text description of operation says that it's the rising edge of /WE and /CE that matter.

Maybe a case of the datasheet being overly ambiguous and/or sloppily written?

I've ordered a FM22L16 to see if I can discover the reality.  I can use an STM32H7 nucleo board that I have laying around as a pattern generator which will allow me to independently control each FRAM control signal with 2.5ns granularity.  With software it will be easy to put things in any arbitrary order.  Do you have a scope capture when the FRAM board is not working (e.g., without the delay)?

It's even more interesting that your analyzer booted at all.  I pulled the SRAM from mine and it doesn't boot.  So, in the non-delay case, the FRAM module is *partially* working or marginal.

Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs.  This would provide a more predictable delay than a free-running oscillator.  There are also silicon delay lines (e.g., DS1100L-xx series), but not cheap.