Author Topic: Has anyone replaced HP8591(E) SRAM by FRAM?  (Read 6815 times)

0 Members and 1 Guest are viewing this topic.

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Has anyone replaced HP8591(E) SRAM by FRAM?
« on: December 09, 2024, 11:15:11 pm »
Has anyone tried to replace HP8591(E) SRAM by FRAM?
I want to get rid of the damn lithium battery holding calibration data in SRAM.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #1 on: December 12, 2024, 11:41:21 pm »
I haven’t seen one but it’s an awesome idea. I have an 8594E and I replaced the battery few years ago.
We would need a 256k x 16 FRAM, probably 4 level translator chips, there are no 256k 5V chips, a 3.3V regulator and couple more gates. I can’t find the connector part number.

Cheers,
Miti

Edit: There is an old model of memory board and a new one. I have the new type.
« Last Edit: December 12, 2024, 11:51:06 pm by Miti »
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #2 on: December 13, 2024, 01:40:25 pm »
I don't know if my memory board is new or old but it's the same as described in the attached pdf.
 

Online squadchannel

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: jp
  • deepl translate user
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #3 on: December 13, 2024, 02:03:05 pm »
FM16/18 cannot be used without circuit modification due to differences in CE pin control. (See the datasheet for details.)
FM28V is improved in this respect and fully compatible with SRAM, but it is 3.3V instead of 5V.

I used TI LSF0108/0204. confirmed that it works with DALLAS NVRAM, and it should work with SRAM as well. :popcorn:

 
The following users thanked this post: picburner, Greybeard

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #4 on: December 13, 2024, 03:48:42 pm »
@Greybeard. That is the new style.
@squadchannel. Take a look at FM22L16. It is drop in replacement for SRAM, no multiple CE toggle rubbish, and I happen to have a hand full of them.
There’s also non volatile SRAM option and they are cheaper. They use QuantumTrap nonvolatile elements ??? and they save the content at power down.
Fear does not stop death, it stops life.
 
The following users thanked this post: squadchannel, Greybeard

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #5 on: December 13, 2024, 04:48:28 pm »
Has anyone tried to replace HP8591(E) SRAM by FRAM?
I want to get rid of the damn lithium battery holding calibration data in SRAM.
That lithium battery also keeps the RTC running on the main board.

You might be able to design in a super-cap, if it will keep the RTC running long enough for you during power off.
 
The following users thanked this post: Greybeard

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #6 on: December 13, 2024, 05:04:46 pm »
Aah, good point. I can add a small coin battery for the RTC.
Another thing is the RAM also keeps the personalities, for example I have EMC personality. It would be good to copy the RAM into the FRAM.
« Last Edit: December 13, 2024, 05:06:51 pm by Miti »
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #7 on: December 13, 2024, 06:37:51 pm »
I think the part number for the connector is 1734101-5 from TE Connectivity.
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #8 on: December 14, 2024, 06:48:57 pm »
We would need a 256k x 16 FRAM, probably 4 level translator chips, there are no 256k 5V chips, a 3.3V regulator and couple more gates.
Don't we need 2 separate 128k x 16 bit FRAM/MRAM/NVSRAM for the 2 separate (probably interlaced) CE lines?

I'm not quite sure if you can remap the 2 CE lines to the double address space easily.
« Last Edit: December 14, 2024, 06:52:16 pm by Greybeard »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #9 on: December 14, 2024, 10:29:12 pm »
We would need a 256k x 16 FRAM, probably 4 level translator chips, there are no 256k 5V chips, a 3.3V regulator and couple more gates.
Don't we need 2 separate 128k x 16 bit FRAM/MRAM/NVSRAM for the 2 separate (probably interlaced) CE lines?

I'm not quite sure if you can remap the 2 CE lines to the double address space easily.

You may be right and that is becase of byte writing. The way I read the schematic is this:

1. There are two 16 bit memory blocks. LUSERRAM0 (U1, U2) and LUSERRAM1 (U6, U7). These cannot be active simultaneously because there would be conflict.
    If this is correct we can use LUSERRAM1 as an address input.
2. There's only one output enable LOE that goes to all four chips so no worries there.
3. Writing can happen on the upper or lower byte or both, controlled by LLW and LUW and that's a problem.

Even more, depending on the processor speed, I don't think 14.7423MHz is that fast though, this FRAM may be too slow. The SRAM read and write cycle time is 70nS, the FRAM is 110nS.
We'd have to measure the memory access timing to see if the FRAM is an option. If it is, LCSC has FM22L16 at ~11USD, not too bad, we need 2 per. Unless the access is very slow and we can make UB, LB and WE from LLW and LUW, in which case one chip is enough.  :box:
« Last Edit: December 14, 2024, 10:38:36 pm by Miti »
Fear does not stop death, it stops life.
 

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #10 on: December 15, 2024, 12:33:33 am »
OK, that sounds “a little” more difficult than I had hoped…  :-\
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #11 on: December 15, 2024, 12:56:48 am »
OK, that sounds “a little” more difficult than I had hoped…  :-\

Looking at Motorola 68000, looks like it needs a minimum of 4 clock cycles for a write so I think we are safe.
If my calculations are correct, the write cycle time is about 271nS. Same for reading.
« Last Edit: December 15, 2024, 12:26:16 pm by Miti »
Fear does not stop death, it stops life.
 

Online squadchannel

  • Frequent Contributor
  • **
  • Posts: 449
  • Country: jp
  • deepl translate user
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #12 on: December 15, 2024, 01:05:55 am »
WE,OE? will probably conflict. if they don't conflict, could use a 16Bit FM22L16, but have to build a board that straddles the two ROMs. not my preference. :scared:
also, yeah, it slow.

my choice the 90ns FM28V100, but at $40(each $10). >:D
used to be able to get it for $10, but it's getting so expensive. jlc sell $10.
« Last Edit: December 15, 2024, 01:12:34 am by squadchannel »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #13 on: December 18, 2024, 02:14:10 pm »
Does anybody knows an IC that can delay a falling edge of a digital signal with minimum delay on the rising edge?

Thanks,
Miti
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #14 on: December 20, 2024, 03:53:07 am »
I have a preliminary schematic. Can you please review and comment? What's missing is a supervisor.
« Last Edit: December 20, 2024, 03:57:34 am by Miti »
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #15 on: December 25, 2024, 01:48:47 pm »
Looks reasonable, but I can't say much about it.
I'm not a bus timing specialist and I don't know anything specific about the timing of the two OE CE signals.
« Last Edit: December 27, 2024, 09:17:44 pm by Greybeard »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #16 on: December 27, 2024, 03:02:20 am »
Looks reasonable, but I can't say much about it.
I'm not a bus timing specialist and I don't know anything specific about the timing of the two OE signals.

Which two OE signals?
Fear does not stop death, it stops life.
 

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #17 on: December 27, 2024, 09:16:01 pm »
Which two OE signals?

Sorry, I meant CE ...

« Last Edit: December 27, 2024, 09:19:50 pm by Greybeard »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #18 on: December 30, 2024, 05:11:25 pm »
Bad news, I should have scoped the signals before going too deep down the rabbit hole. The fastest write time is 100ns while the FM22L16 access time is 110ns. See below the scope shots for LLW and LUW. Most writes are 16 bits but I've caught few 8 bits writes as you can see. We need a faster FRAM or NVRAM.

Edit: Oops, I was looking at the wrong parameters. Assuming the writing is controlled by WE , the minimum WE pulse twp for FM22L16 is 16nS, in our instrument case it is 100nS. The cycle time is between two WE pulses and it is, as guessed before, about 271.32 nS, four clocks of 14.7423MHz. Back to it.
« Last Edit: January 01, 2025, 08:14:33 pm by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #19 on: January 07, 2025, 03:00:42 pm »
I have a question about the bidirectional level translators such as TXB0108. I see it has an OE pin for the LV side. Can I connect it to Vcc or does it have to be controlled? What happens with the 5V side if I tristate the memory side and the LV pins are left floating? I’m asking because the enable time Ten is 1uS and it is a killer.  :palm:

Cheers,
Miti
« Last Edit: January 07, 2025, 03:38:03 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #20 on: January 07, 2025, 09:38:09 pm »
I have a question about the bidirectional level translators such as TXB0108. I see it has an OE pin for the LV side. Can I connect it to Vcc or does it have to be controlled? What happens with the 5V side if I tristate the memory side and the LV pins are left floating? I’m asking because the enable time Ten is 1uS and it is a killer.  :palm:

Cheers,
Miti
You might want to control OE if you have a partial power-down application (meaning power-down on the VCCB side).  Otherwise it does not need to be controlled, which is the situation here.  You should tie it to VCCA since it is referenced to VCCA.

However, you should read the section about pullups in the datasheet: 7.3.5 Pullup or Pulldown Resistors on I/O Lines, and 8.2.2 Detailed Design Procedure.  The TXB0108 presents weak pullups and pulldowns to both sides of the translation so that either side can force the bus to the desired state.  If there's other pullups or pulldowns it can interfere with this operation.  The 859xE series has a 10k resistor array (U11) plus R19 (for qty 16) to provide pullups on the data bus (see block E on the processor schematic).  These pullups are going to interfere with the TXB0108.

Also, the data bus goes a lot of places, so 7.3.3 Output Load Considerations, which talks about capacitive load, could also be a concern.

I would recommend to design with standard bus drivers and create the logic to control direction.  These automatic bidirectional drivers sound like a dream come true, but I've always found a reason not to use them in my designs.
 
The following users thanked this post: Miti

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #21 on: January 09, 2025, 07:59:24 pm »
Thanks Mark, yes I saw the 4K resistors series with the drivers but I missed the 10K pull-ups. Would 74LVC4245 be a good choice? And what would be the direction and the OE logic?
I’m thinking LUSERRAM0 and LUSERRAM1 would control buffers OE and module OE would control direction. When FRAM OE is high, direction is CPU to memory.

Cheers,
Miti

Edit: Or maybe 74ALVC164245 but it may be harder to layout.
« Last Edit: January 09, 2025, 10:44:55 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #22 on: January 10, 2025, 08:42:35 pm »
The 74LVC4245 looks like a good choice.

The direction and OE control I think would have to be some combination of LUSERRAMx, LLW, and LOE.

Take a look at the existing memory HM628128 datasheet.  The /OE input going low does not always mean "from memory", specifically during Write Cycle Mode 2 (truth table below).  I don't know which mode HP is using and there is a PAL (U114) involved in the memory signal controls, so the behavior can't be determined by the schematic alone.  To be safe you should probably emulate all combinations of the HM628128, but you could also scope the memory control lines and figure out exactly what they're doing, which may allow you to simplify the new control logic (for example, they only use Write Cycle Mode 1).

I think 74ALVC164245 would work too.  The layout doesn't look too bad.  At least all the A's and B's are on opposite sides, so it's still flow-thru.
 
The following users thanked this post: Miti

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #23 on: January 11, 2025, 06:21:32 pm »
Ok, I've checked. OE is always high when either LLW or LUW goes low. I'll assume mode 1. Do you have any reason to believe it uses mixed modes?
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #24 on: January 11, 2025, 11:38:45 pm »
I wouldn't expect them to mix modes.  As long as you didn't catch it doing Mode 2 you should be ok.  I think they would probably only use Mode 2 if they decided not to control /OE at all.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #25 on: January 12, 2025, 02:41:15 am »
Ok, I think I have a schematic and a very preliminary PCB. Could you please take a look and see if you can find any error?

Thanks,
Miti
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #26 on: January 14, 2025, 09:03:07 pm »
I would suggest a 10k pullup on /CE to make sure it stays high through power cycle, as per the FM22L16 datasheet.

In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?
 

Offline GreybeardTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
  • Country: de
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #27 on: January 15, 2025, 12:40:15 am »
Very well done.  :-+
U6 is missing in the PCB view.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #28 on: January 15, 2025, 01:38:32 am »
Very well done.  :-+
U6 is missing in the PCB view.

This is dynamic. I've already modified the schematic. As I said, the PCB was very preliminary.
Fear does not stop death, it stops life.
 
The following users thanked this post: Greybeard

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #29 on: January 15, 2025, 02:01:48 am »
I would suggest a 10k pullup on /CE to make sure it stays high through power cycle, as per the FM22L16 datasheet.

In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Good catch with the pull-up resistor, thanks!
OK, I will in the weekend. Meanwhile here's a scope shot with LLW (CH1), LOE (CH2) and the address LSB (CH3). It looks like I caught a read, two write cycles, and another partial read.
« Last Edit: January 15, 2025, 02:06:14 am by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #30 on: January 15, 2025, 08:13:33 pm »
In parallel with the RAM board design I’m thinking of a solution to copy the content of the HP module into my FRAM module. I don’t want to go through the pain of entering the calibration constants and the EMC personality. I’m thinking of two possible (approachable) solutions:
1. Make an adapter from the Molex connector to a DIL connector, together with some logic as needed, and use a programmer, such as TL866, to read and write the memory. Select a 5V 256k x 16  flash for the device.
This would be the preferred solution to save the content in a binary file.
2. Make an adapter with two Molex connectors and a header for an Arduino Mega 2560. I would connect both modules in the same time, data and address lines are connected together, and Arduino would give the address lines and the control signals to copy from the source into the destination. The disadvantage of this approach is that it would be a blind copy.

I would prefer the first approach but for that I would need to know the pinout of the adapter used with TL866. For example AM29F400 is a 5V only flash that seems to be a good candidate but needs an adapter from 44 pin SOP or from 48 pin TSOp to 40 pin ZIF socket and I don’t have the pinout or the schematic.
Does anyone have the schematic of such adapter?

Cheers,
Miti
« Last Edit: January 15, 2025, 08:57:41 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #31 on: January 15, 2025, 09:58:17 pm »
In parallel with the RAM board design I’m thinking of a solution to copy the content of the HP module into my FRAM module. I don’t want to go through the pain of entering the calibration constants and the EMC personality. I’m thinking of two possible (approachable) solutions:
1. Make an adapter from the Molex connector to a DIL connector, together with some logic as needed, and    use a programmer, such as TL866, to read and write the memory. Select a 5V 256k x 16  flash for the device.
This would be the preferred solution to save the content in a binary file.
2. Make an adapter with two Molex connectors and a header for an Arduino Mega 2560. I would connect both modules in the same time, data lines are connected together, and Arduino would give the address lines and the control signals to copy from the source into the destination. The disadvantage of this approach is that it would be a blind copy.

I would prefer the first approach but for that I would need to know the pinout of the adapter used with TL866. For example AM29F400 is a 5V only flash that seems to be a good candidate but needs an adapter from 44 pin SOP or from 48 pin TSOp to 40 pin ZIF socket and I don’t have the pinout or the schematic.
Does anyone have the schematic of such adapter?

Cheers,
Miti
I've done approach #2 with a Silabs C8051F581, except I made the processor spit out on its serial port a hex dump of what it was reading and then captured that on a computer.  So, I ended up with a binary image of the SRAM.  See:

   https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1013805/#msg1013805

I had to do it in 2 or 4 passes because the Silabs part did not have enough GPIO pins.  If I were to do it again, I would use something with enough pins to cover all the address and data pins, like a STM32F767 on a NUCELO dev board (NUCLEO-F767ZI, about USD$25).  The GPIO pins on the STM32F767 are almost all 5V tolerant (109 out of 112 pins), so you could go with direct jumpers with no intervening logic or current limiting resistors.  Since you're dealing with SRAM, there are no timing issues and you can go as slow as you want.

I did not do the SRAM writer part, but once the SRAM binary image was available, it would be easy to plug the connector into the new SRAM and go the other way.  The STM32F767 has 2MB of flash, so once you have the SRAM image, you could build it into the binary, load it into the STM32F767, and proceed with the writing.

The EMC personality and flatness correction constants can both be reloaded via GPIB, but I agree it is a pain.  The EMC personality can also be copied to an intermediate 128k RAM card (HP 85702A), and then copied back, but they are hard to find for sane prices.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #32 on: January 15, 2025, 11:49:48 pm »
I've done approach #2 with a Silabs C8051F581, except I made the processor spit out on its serial port a hex dump of what it was reading and then captured that on a computer.  So, I ended up with a binary image of the SRAM.  See:

   https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1013805/#msg1013805

I had to do it in 2 or 4 passes because the Silabs part did not have enough GPIO pins.  If I were to do it again, I would use something with enough pins to cover all the address and data pins, like a STM32F767 on a NUCELO dev board (NUCLEO-F767ZI, about USD$25).  The GPIO pins on the STM32F767 are almost all 5V tolerant (109 out of 112 pins), so you could go with direct jumpers with no intervening logic or current limiting resistors.  Since you're dealing with SRAM, there are no timing issues and you can go as slow as you want.

I did not do the SRAM writer part, but once the SRAM binary image was available, it would be easy to plug the connector into the new SRAM and go the other way.  The STM32F767 has 2MB of flash, so once you have the SRAM image, you could build it into the binary, load it into the STM32F767, and proceed with the writing.

The EMC personality and flatness correction constants can both be reloaded via GPIB, but I agree it is a pain.  The EMC personality can also be copied to an intermediate 128k RAM card (HP 85702A), and then copied back, but they are hard to find for sane prices.

Isn't this more like approach #1 but using the Silabs instead of the programmer?
In approach #2 the Arduino boards does not see the data, it only generates the addresses and the control signals for both, source and destination.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #33 on: January 16, 2025, 12:08:12 am »
...
Isn't this more like approach #1 but using the Silabs instead of the programmer?
In approach #2 the Arduino boards does not see the data, it only generates the addresses and the control signals for both, source and destination.
Yes.  I was seeing the difference between your approaches as using a processor vs. using a programmer.  But I get it now - #2 goes back-to-back with the modules.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #34 on: January 16, 2025, 06:52:03 pm »
The programmer approach is a good idea.

Since the memory module is writable on a byte basis, you could read/write the image in two slices, first lower bytes and then upper bytes.  On the TL866, you could select a 256k x 8 NVRAM chip, such as the 5V Dallas DS1249AB or DS1249Y.  The DS1249 is a 32-pin DIP and does not need a mystery adapter, and I think is supported by the TL866 (and a lot of other programmers).

If you wanted a contiguous SRAM image for some reason, there are tools to re-interleave the lower and upper byte-wide images.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #35 on: January 16, 2025, 11:11:53 pm »
The programmer approach is a good idea.

Since the memory module is writable on a byte basis, you could read/write the image in two slices, first lower bytes and then upper bytes.  On the TL866, you could select a 256k x 8 NVRAM chip, such as the 5V Dallas DS1249AB or DS1249Y.  The DS1249 is a 32-pin DIP and does not need a mystery adapter, and I think is supported by the TL866 (and a lot of other programmers).

If you wanted a contiguous SRAM image for some reason, there are tools to re-interleave the lower and upper byte-wide images.

That's a very good idea, thank you Mark!
I got stuck with the 16 bit idea and it didn't occur to me that by reading/ writing 8 bits at a time I don't need the adapter anymore.
In fact I think TL866 II Plus is 8 bit and the adapter multiplexes the upper and lower block. :-+

Edit: Tested with an FRAM chip and it works.  :clap:
Edit 1: And if I select DS1250 instead of DS1249, the /LB , /UB multiplexing can be done automatically using the address MSB and it creates a single file.
« Last Edit: January 17, 2025, 03:22:38 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #36 on: January 17, 2025, 08:24:47 pm »
Interesting idea on using the MSB to control the upper/lower byte selection.  But when connecting the memory module, how does the upper byte get multiplexed onto the DS1250 [D7..D0] pins on the programmer?

I thought of another thing wrt the memory module: LUSERRAM0 and LUSERRAM1 are mutually exclusive, so they can't be wired to address lines.  More properly, those are really select inputs so they should be handled by connecting them to the pin assigned to /CE pin on the programmer.

At the moment, I'm seeing a four pass solution using a DS1245Y or DS1245AB (128k x 8 ).

    Programmer      Module         
    ----------      ----------
1)  /CE        -->  LUSERRAM0   
    [D7..D0]   ---  [MD7..MD0]
    /WE        -->  LLW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]
 
2)  /CE        -->  LUSERRAM1   
    [D7..D0]   ---  [MD7..MD0]
    /WE        -->  LLW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]

3)  /CE        -->  LUSERRAM0   
    [D7..D0]   ---  [MD15..MD8]
    /WE        -->  LUW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]
 
4)  /CE        -->  LUSERRAM1   
    [D7..D0]   ---  [MD15..MD8]
    /WE        -->  LUW         
    /OE        -->  LOE         
    [A16..A0]  -->  [MA17..MA1]


For the read operations on the original module, I would probably tie LLW and LUW high through a resistor to whatever is supplying power to the module, independent of what the programmer is doing, just to make sure no writes are triggered by accident.

Edit:  I guess it's really 8 passes, if you want to multiply by a pass for read and a pass for write.
« Last Edit: January 17, 2025, 08:28:15 pm by MarkL »
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #37 on: January 17, 2025, 09:23:49 pm »
I'll throw this out there, but it's also possible to read the entire SRAM via GPIB.  It could serve as a backup, but to be honest I've never tried to put the GPIB output back into SRAM to see if it works.

There is an undocumented command:

  mbrd START,BYTES

where START is the starting address, and BYTES is the number of bytes to dump.  Both are in decimal.  Results are returned in "A-block" format.  See the programmer manual for details on A-block (page 3-24), but I'll summarize by saying it's a binary format and limited to 32767 bytes.  So, BYTES can't exceed 32767.

The SRAM module is mapped into the processor memory starting at 0x00f80000 (16252928 decimal), and ends at 0x00ffffff (16777215 decimal).  That's 524288 bytes.

If you wanted to try dumping all of SRAM, you would need to set up a loop and submit GPIB commands like this:

  mbrd 16252928,16384
  mbrd 16269312,16384
  mbrd 16285696,16384
  ...
  mbrd 16760832,16384

It would be interesting to know if this roughly matches whatever you extract from the original module.  Of course it won't be exact because it's a running system.  And you could also try writing the mbrd output into the new module with the programmer and see if everything is there, like your cal constants and EMC personality.

Obviously none of this is needed for your approach.  I disassembled my SRAM module reader long ago and I'm mostly curious if this works, having discovered the hidden mbrd command sometime later.

So, if you're in the mood in the future...

EDIT: Bummer, but this doesn't work.  See: https://www.eevblog.com/forum/repair/has-anyone-replaced-hp8591(e)-sram-by-fram/msg5801109/#msg5801109
« Last Edit: January 30, 2025, 08:47:33 pm by MarkL »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #38 on: January 17, 2025, 10:29:43 pm »
Interesting idea on using the MSB to control the upper/lower byte selection.  But when connecting the memory module, how does the upper byte get multiplexed onto the DS1250 [D7..D0] pins on the programmer?

Two 4451 to multiplex 16 bit to 8 bit. The selection line is A18 ( DS1250 has A18 to A0 address lines).

I thought of another thing wrt the memory module: LUSERRAM0 and LUSERRAM1 are mutually exclusive, so they can't be wired to address lines.  More properly, those are really select inputs so they should be handled by connecting them to the pin assigned to /CE pin on the programmer.

Yes they can. LUSERRAM0 is connected directly to A17 and LUSERRAM1 through an inverter to the same A17.
/CE cannot be used in this case.

For the read operations on the original module, I would probably tie LLW and LUW high through a resistor to whatever is supplying power to the module, independent of what the programmer is doing, just to make sure no writes are triggered by accident.

Yes, for reading the source, LLW and LUW are connected through pull-ups to Vcc and disconnected from /WE for write protection For writing I have to create the logic between /WE and A18 that holds LLW or LUW low as needed. Something similar to what’s in my FRAM schematic.

Edit: I’ll put it in a schematic, I may be missing something, it’s all in my head for now.
« Last Edit: January 17, 2025, 10:38:15 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #39 on: January 18, 2025, 12:37:13 am »
Certainly with the addition of various logic it's possible to make any scenario work.

Since moving the SRAM contents only needed to be done once, I was trying to keep it simple and make the programmer do all the work without building any additional circuitry.  My 8 step proposal uses jumpers and a resistor or two.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #40 on: January 18, 2025, 04:34:45 am »
Certainly with the addition of various logic it's possible to make any scenario work.

Since moving the SRAM contents only needed to be done once, I was trying to keep it simple and make the programmer do all the work without building any additional circuitry.  My 8 step proposal uses jumpers and a resistor or two.

By the time I draw the schematic, I cut the wires, I strip, I solder, I curse... I'd rather have it done right and order it together with the main board.

Edit: This also can be used as test platform. If reading and writing works on this adapter, it is more likely to work in the spectrum analyzer.
« Last Edit: January 18, 2025, 01:38:25 pm by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #41 on: January 18, 2025, 07:00:47 pm »
Something like this. I've looked for a proper switch instead of a jumper but boy oh boy! $10 for a proper slide switch? What a world, what a world...
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #42 on: January 18, 2025, 09:33:57 pm »
In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Here it is. Ok, LLW (and I assume LUW as well, from my previous scope shots most writes are 16bits, but I ran out of channels  ;D) does toggle with peripherals, so what? If no RAM is selected, both FRAM and the buffer are disabled. The write cycle is ignored.
Do you see any conflict in the attached scope shots? What else do you think I should look at?

Cheers,
Miti
« Last Edit: January 18, 2025, 09:42:46 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #43 on: January 21, 2025, 11:48:14 pm »
In the scope capture in Reply #18, it would be better to trigger on LUSERRAMx == LOW (HM638128 /CE == LOW).  LLW and LUW might be toggling with peripheral accesses, and if so, you're not necessarily capturing exclusively what the HM638128 is experiencing.

Can you post a capture of LxW, LOE, LUSERRAMx signals during a memory read cycle, and during a memory write cycle?

Here it is. Ok, LLW (and I assume LUW as well, from my previous scope shots most writes are 16bits, but I ran out of channels  ;D) does toggle with peripherals, so what? If no RAM is selected, both FRAM and the buffer are disabled. The write cycle is ignored.
Do you see any conflict in the attached scope shots? What else do you think I should look at?

Cheers,
Miti
I don't see anything that might be problem.

Yes, I agree it doesn't matter if LLW or LUW or anything else toggles on peripheral access.  I was asking for triggering on LUSERRAMx so that various signal timings could be verified only when the SRAM is active.  The previous trigger settings were capturing ALL writes (on LLW), which included SRAM and everything else.

The only other thing you could poke at is some of the address lines to make sure they are stable before or exactly when LUSERRAMx goes low.  The FRAM address setup time (tAS) is 0ns and is latched on /CE going low.  The original SRAM does not latch the address, so it operates a little differently.  But I would be surprised if any address lines are changing after LUSERRAMx goes low.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #44 on: January 22, 2025, 03:22:28 pm »
Thanks Mark, I appreciate your input!
I think our write cycle is controlled by /WE.
The thing is that LUSERRAM0 is part of the FRAM address so the address changes when it goes low so address and /CE may change in the same time when RAM0 is selected. Maybe I should delay /CE through two more inverters. I’ve also delayed the /LB and /UB through two more inverters each so they are delayed relative to LLW and LUW when they, and consequently /WE, go high. One more thing that worries me is changing /LB and /UB after /CE goes low. Those lines are set before /CE in /WE controlled cycle, but they do change after in /CE controlled cycle, in the FRAM data sheet.  :-//
I guess I’ll have to test to be sure it works.

Edit: I think my write cycle looks something like this.
« Last Edit: January 22, 2025, 03:45:08 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #45 on: January 22, 2025, 08:53:01 pm »
Hmmm...  I was thinking you would control the write cycle with /CE (Mode 2):

Addresses would be stable (presumably - need to verify) before or conincident with /CE.  /CE is LUSERRAM0*LUSERRAM1.  A17 is LUSERRAM0.  When /CE falls, the correct address is latched, and it doesn't matter yet on /LB and /UB.

For read, /OE is LOE, LLW and LUW stay high.

For write, LLW and LUW would drive /LB and /UB, respectively, and /WE is LLW*LUW.  LOE stays high.  The write happens on the rising edge of /CE.  The timing diagram is not showing any constraints on /WE since the cycle is terminated by /CE (although I would have liked to see *something* on the diagram).

If this doesn't work out for some reason, a possible fallback could be 2x 8x256k FRAMs.  Or even 4x 8x128k FRAMs.  The memory interface has already de-multiplexed the control signals, and it would be more of a "drop-in" application for which this FRAM was designed.

Also, it would be worthwhile to validate the behavior of /CE on power up and power down cycles.  The DS1210 is providing protection against spurious writes for the old memory.  The FRAM requires that /CE (or /WE) follows Vdd down to 0V and back up again to prevent spurious writes.  This may be a concern since the FRAM will still be operating after the processor has gone out to lunch due to low voltage.  The processor is probably being held in reset during those times, but even reset circuits bail out when the voltage gets low enough, and I'm not seeing a lockout voltage specification for the FRAM.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #46 on: January 22, 2025, 09:21:03 pm »
I wish those chips existed. Check Digikey, Mouser, LCSC. This is the only chip with healthy stock and decent price. I may go with two FM22L16 and use half of each.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #47 on: January 23, 2025, 12:06:36 am »
I wish those chips existed. Check Digikey, Mouser, LCSC. This is the only chip with healthy stock and decent price. I may go with two FM22L16 and use half of each.
Sorry, I didn't look first.  You're right, there doesn't seem to be a 8x256k.  But there is FM28V100 which is 8x128k for $21 ea. at Mouser.  Four of them would be a little more expensive than two FM22L16, so probably doesn't make sense.  A solution that uses a single FM22L16 is worth jumping through some hoops.

If you read the operation detail in the FM22L16 datasheet, I think the write cycle I described would work.  There's just not a timing diagram that represents it.

Cypress has another technology call nvSRAM, e.g. CY14B104 which is 8x512K or 16x256K.  It has 20 year retention, which is less than FRAM, but the interface is pure SRAM so might be a little easier.  One oddity is that it has a 20ms startup time and an 8ms shutdown time, but that's probably ok (would need to verify 859x reset circuit).  Another nice thing is that it has a specified lockout threshold of 2.65V.  Availability is ok.  Something to think about if the FRAM doesn't work out.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #48 on: January 23, 2025, 12:20:33 am »
Sorry, I didn't look first.  You're right, there doesn't seem to be a 8x256k.  But there is FM28V100 which is 8x128k for $21 ea. at Mouser.  Four of them would be a little more expensive than two FM22L16, so probably doesn't make sense.  A solution that uses a single FM22L16 is worth jumping through some hoops.

Check FM22L16 at LCSC.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #49 on: January 23, 2025, 01:35:33 am »
Hmmm...  I was thinking you would control the write cycle with /CE (Mode 2):

Addresses would be stable (presumably - need to verify) before or conincident with /CE.  /CE is LUSERRAM0*LUSERRAM1.  A17 is LUSERRAM0.  When /CE falls, the correct address is latched, and it doesn't matter yet on /LB and /UB.

For read, /OE is LOE, LLW and LUW stay high.

For write, LLW and LUW would drive /LB and /UB, respectively, and /WE is LLW*LUW.  LOE stays high.  The write happens on the rising edge of /CE.  The timing diagram is not showing any constraints on /WE since the cycle is terminated by /CE (although I would have liked to see *something* on the diagram).

If this doesn't work out for some reason, a possible fallback could be 2x 8x256k FRAMs.  Or even 4x 8x128k FRAMs.  The memory interface has already de-multiplexed the control signals, and it would be more of a "drop-in" application for which this FRAM was designed.

Also, it would be worthwhile to validate the behavior of /CE on power up and power down cycles.  The DS1210 is providing protection against spurious writes for the old memory.  The FRAM requires that /CE (or /WE) follows Vdd down to 0V and back up again to prevent spurious writes.  This may be a concern since the FRAM will still be operating after the processor has gone out to lunch due to low voltage.  The processor is probably being held in reset during those times, but even reset circuits bail out when the voltage gets low enough, and I'm not seeing a lockout voltage specification for the FRAM.

Actually I am considering connecting /CE to GND and playing with /WE, /OE only. The way I see the signals in the spectrum analyzer, it uses /WE controlled writing so it would need a bit more intelligence that some gates to change that... I think.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #50 on: January 23, 2025, 02:59:05 pm »
I’ve checked a professional design for the FRAM safe power up schematic. They pull /ZZ low with the reset line from the supervisor.  :-//
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #51 on: January 24, 2025, 01:30:39 am »
Actually I am considering connecting /CE to GND and playing with /WE, /OE only. The way I see the signals in the spectrum analyzer, it uses /WE controlled writing so it would need a bit more intelligence that some gates to change that... I think.
Sure, a grounded /CE could work too.  LUSERRAM0 and LUSERRAM1 need to be involved to gate /WE and /OE since you already have at least one scope capture where LLW is going low with LUSERRAM0 and LUSERRAM1 staying high, and another where LOE is going low with LUSERRAM0 and LUSERRAM1 staying high.

If you use /CE, the gating can stay in the FRAM instead of doing it externally.  But I think either approach will work.

Great idea to look at how other implementations do controlled power up/down.  But interesting that Cypress didn't point out /ZZ explicitly in the datasheet as an option to help with power up/down.

The FRAM needs 450us to wake up after /ZZ high, so using /ZZ not completely a slam dunk.  If tied to the processor /RESET, the processor might have already started before the FRAM wakes up.  I'm not seeing a timing spec for /RESET high to start execution in the 68HC000 datasheet.  Maybe you could use a local reset supervisor driving /ZZ that triggers on +5D reaching 3.0V or so.  At that point the processor is being held in reset and it's a matter of the voltage ramp on +5D passing 3.0V and HPWRUP going high (wherever that's coming from - looks like the power supply).

Or you could keep /WE (or /CE) tracked to Vdd until you know the processor is safely being held in reset (like until 4.5V).  That's what the datasheet wants and it's more of a deterministic approach since this design is not in control of the processor, reset circuit, or power supply characteristics.

EDIT:  In the design you were looking at that used /ZZ, they could have anticipated the FRAM wakeup time in the firmware and delayed before accessing it.  In which case /ZZ is an easy and simple approach.
« Last Edit: January 24, 2025, 01:47:25 am by MarkL »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #52 on: January 24, 2025, 03:38:59 am »
Thanks Mark!
I did some basic timing analysis of a write cycle and I think I have a winner... or a wiener, we'll see what the proper spelling is when I test it.
I am using CE in the end and I'll have to think a bit more about the power up/dn protection but basically this schematic should work.
One unknown part is changing /LB, /UB after address and /CE change, but figure 13 in the datasheet gives me hope.
The time division is 10ns. I may need to use slower 74HC14 for longer delays if 74LVC is too fast. The oscillator may also need experimental tuning but as I like to say, electronic engineering is not an exact science... all the time.

Edit: Maybe this would work for power up/dn. Schematic updated.
« Last Edit: January 24, 2025, 05:07:14 am by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #53 on: January 24, 2025, 04:07:07 am »
Great idea to look at how other implementations do controlled power up/down.  But interesting that Cypress didn't point out /ZZ explicitly in the datasheet as an option to help with power up/down.

The FRAM needs 450us to wake up after /ZZ high, so using /ZZ not completely a slam dunk.  If tied to the processor /RESET, the processor might have already started before the FRAM wakes up.

.................

EDIT:  In the design you were looking at that used /ZZ, they could have anticipated the FRAM wakeup time in the firmware and delayed before accessing it.  In which case /ZZ is an easy and simple approach.

Yes, I saw that 450us and I didn't like it. And as you said, the SW may wait for the FRAM in that application.

Maybe you could use a local reset supervisor driving /ZZ that triggers on +5D reaching 3.0V or so.

There is a reset supervisor on the HP RAM board and on my board. Actually I think it is the only reset supervisor, it doesn't make sense to have more than one as you cannot run the SA without the RAM board.

Or you could keep /WE (or /CE) tracked to Vdd until you know the processor is safely being held in reset (like until 4.5V).  That's what the datasheet wants and it's more of a deterministic approach since this design is not in control of the processor, reset circuit, or power supply characteristics.

That is what I have to explore. If the LUSERRAMx signals came from the processor, I could assume they are held hi-z during reset and just pull high the U11 inputs, but they come from U114 (PAL) and it doesn't have a reset input so I don't know what is doing during reset. LxW come from some gates so no luck there either.

Miti
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #54 on: January 24, 2025, 04:00:12 pm »
...
There is a reset supervisor on the HP RAM board and on my board. Actually I think it is the only reset supervisor, it doesn't make sense to have more than one as you cannot run the SA without the RAM board.

There is indeed a TL7705ACD supervisor (U3) on the memory board, but it is not providing reset functions to the rest of the unit.  The only thing it's doing is protecting the RTC (U106, RTC72421) from spurious writes when +5D is out of spec.  It's the only place where the LPF (power fail detect) signal is going.  Why they chose to put this function on the memory board, I don't know.

The system reset is controlled via a signal coming out of the power supply, HPWRUP (J13-37, aka "WRUP").  This eventually makes it to the LRST (/RESET) input on the processor. See "POWER UP" block K on the processor schematic.

The two DS1210S on the memory card (U4, U5) are providing the write protection for the old memory by preventing LUSERRAM0 and LUSERRAM1 from getting to the chip selects when +5D is out of spec (<4.62V typ).
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #55 on: January 24, 2025, 05:08:45 pm »
Thank you Mark for the info!
In this case I’ll need to do some scoping. TL7705 reset pulse, with 100pF capacitor is only 1.3us, the supervisor that I selected is 1.7ms. We may have a problem here.

Edit1: I may have to use the same TL7705 supervisor, it is still active.
Edit2: Wait a minute, the FRAM power up time is 450us…. I knew that but it didn’t occur to me until now that this may not work. If the reset time from the power supply is less than that, this FRAM cannot be used.  |O
« Last Edit: January 24, 2025, 06:43:35 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #56 on: January 24, 2025, 10:13:23 pm »
Thank you Mark for the info!
In this case I’ll need to do some scoping. TL7705 reset pulse, with 100pF capacitor is only 1.3us, the supervisor that I selected is 1.7ms. We may have a problem here.

Edit1: I may have to use the same TL7705 supervisor, it is still active.
Edit2: Wait a minute, the FRAM power up time is 450us…. I knew that but it didn’t occur to me until now that this may not work. If the reset time from the power supply is less than that, this FRAM cannot be used.  |O
That's what I would do - just duplicate their circuit for the TL7705.  That chip and its supporting components is really an island on this board, and it's driving the RTC which has nothing to do with the new memory design.  Substituting a different reset circuit could only introduce issues for the RTC.  Maybe you could take advantage of the LPF output for your FRAM write protect scheme.

The FRAM power up time may be ok.  The FRAM Vdd_min is 2.7V.  So, the FRAM gets a head start as +5D ramps to 5.0V, plus whatever timer the power supply is using to release the reset line.  You should take a look with a scope.  You want a really wide margin here since you don't know what the variability will be from system to system.  Unfortunately there are no schematics or detailed enough specs for the power supply to even guess at what the HPWRUP delay might be.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #57 on: January 24, 2025, 11:24:21 pm »
re: FRAM power up time...

The MC68HC000 datasheet says in AC Electrical Specifications footnote (pg 3-54):

   4.  For power-up, the MC68HC000 must be held in the reset state for 100 ms to allow stabilization of on-chip circuitry.

So, if HP did their design correctly to meet this spec, the FRAM will have plenty of time for its 450us power up.  But I would still check it with a scope.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #58 on: January 25, 2025, 03:19:12 am »
re: FRAM power up time...

The MC68HC000 datasheet says in AC Electrical Specifications footnote (pg 3-54):

   4.  For power-up, the MC68HC000 must be held in the reset state for 100 ms to allow stabilization of on-chip circuitry.

So, if HP did their design correctly to meet this spec, the FRAM will have plenty of time for its 450us power up.  But I would still check it with a scope.

Yes, they designed it well. The first ... something, I cannot call it activity, on the LUSERRAM0 line happens after more than 200ms of stable 5V.
The real activity starts after almost 1ms.
What do you think about my timing diagram in reply #52?

Edit: I've added the power down sequence. The LUSERRAM0 activity stops at about 4.6V, can't be very precise with an 8 bit scope. That means that if I use the  monitor on my board to disconnect /CE at power up/dn, I cannot do it in the middle of an access, so the threshold of my monitor must be below 4.6V to start the power down sequence for the FRAM after the processor stops accessing it.
« Last Edit: January 25, 2025, 02:39:02 pm by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #59 on: January 25, 2025, 09:33:51 pm »
So, there's gobs of time on startup - that's good.

The idling on power up after 200ms (after the very brief LUSERRAM0 blip) could be a further startup delay implemented by the firmware, or maybe it's polling a sub-system waiting for it to be ready.  But it doesn't really matter; just an observation.

Good idea to look at the power down.

On power down, the processor is not paying attention to any impending power fail signal that I can see.  Either the power supply pulls down /RESET and stops it, or the DS1210 inhibits access to the SRAM chips and it crashes.  It would be good to know who is calling it quits first.

The DS1210 triggers between 4.50V and 4.74V, with a typical value of 4.62V.  Given your scope capture, it could be /RESET (HPWRUP from the power supply) or one or both of the DS1210.  You can find out for certain by capturing the processor /RESET and both memory /CE. 

If it is the DS1210, I guess it's possible the processor could be in the middle of a 16-bit word write and one of the DS1210 has not triggered yet, resulting in only one byte of the word being written.  Software can deal with that scenario for critical data, but who knows what they did.  I'm hoping it's the /RESET that stops everything, since that is being driven by the power supply and it certainly knows when power is going out, but your scope capture implies otherwise.

I will look at the timing diagram.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #60 on: January 25, 2025, 11:56:42 pm »
...
What do you think about my timing diagram in reply #52?
The timing looks like it would work for the FRAM, but I'm not sure you need to go through all the trouble for extra delays on /LB, /UB, and /WE.  I also looked the schematic.  Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

If you read the text of how the various signals work, the FRAM is very forgiving in the order in which things happen.  As I mentioned before, the write occurs on the rising edge of /WE or /CE.  /LB and /UB have to be setup 25ns before that (tBLC).  /LB and /UB can coincide with /WE (or /CE) since it's the rising edge that matters and the /LB and /UB hold time is 0ns (tBH).  Said another way, /LB and /UB must not change 25ns before either /WE or /CE goes high.

The address has to be stable 0ns (tAS) before /CE goes low, but if they change afterwards the new address is latched and it operates in a /CE low cycle.

Maybe try this:  You have the following control signals coming into the board: LUSERRAM0, LUSERRAM1, LOE, LLW LUW.  The FRAM inputs are /CE, /UB, /LB, /WE, /OE.  Write the logic equations for the FRAM inputs in terms of the incoming signals.  Or sometimes it's clearer to write out all the combinations in a truth table, in this case 32 rows, with inputs on the left and the desired outputs on the right.  Then it might be easier to see if any gate delays, one-shots, or any other signal massaging is necessary.

EDIT: And another FRAM input to include, if you do equations or a table, is A17.
« Last Edit: January 26, 2025, 12:05:36 am by MarkL »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #61 on: January 26, 2025, 03:43:20 am »
Good idea to look at the power down.

On power down, the processor is not paying attention to any impending power fail signal that I can see.  Either the power supply pulls down /RESET and stops it, or the DS1210 inhibits access to the SRAM chips and it crashes.  It would be good to know who is calling it quits first.

The DS1210 triggers between 4.50V and 4.74V, with a typical value of 4.62V.  Given your scope capture, it could be /RESET (HPWRUP from the power supply) or one or both of the DS1210.  You can find out for certain by capturing the processor /RESET and both memory /CE. 

If it is the DS1210, I guess it's possible the processor could be in the middle of a 16-bit word write and one of the DS1210 has not triggered yet, resulting in only one byte of the word being written.  Software can deal with that scenario for critical data, but who knows what they did.  I'm hoping it's the /RESET that stops everything, since that is being driven by the power supply and it certainly knows when power is going out, but your scope capture implies otherwise.

I will look at the timing diagram.

It must be the power supply because I'm probing on the connector, before DS1210. I need to make sure I don't reset the memory before the power supply resets the processor.
« Last Edit: January 26, 2025, 03:45:41 am by Miti »
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #62 on: January 26, 2025, 04:08:24 am »
The timing looks like it would work for the FRAM, but I'm not sure you need to go through all the trouble for extra delays on /LB, /UB, and /WE.

I think you're right about the WE, maybe it doesn't need a delay, I'll reevaluate. However, without delay on LB, UB and A17, I risk that LB, UB or the address changes right before or in the same time with LxW or LUSERRAMx.

Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

They are, U8 takes care of that. They are both low when LxWs are either low or hi, and only one is low when a byte write happens.

Maybe try this:  You have the following control signals coming into the board: LUSERRAM0, LUSERRAM1, LOE, LLW LUW.  The FRAM inputs are /CE, /UB, /LB, /WE, /OE.  Write the logic equations for the FRAM inputs in terms of the incoming signals.  Or sometimes it's clearer to write out all the combinations in a truth table, in this case 32 rows, with inputs on the left and the desired outputs on the right.  Then it might be easier to see if any gate delays, one-shots, or any other signal massaging is necessary.

EDIT: And another FRAM input to include, if you do equations or a table, is A17.

I honestly don't have time for that, I've put enough time in this project. I'll grow a Greybeard soon... :-DD
« Last Edit: January 26, 2025, 04:42:11 am by Miti »
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #63 on: January 26, 2025, 06:25:23 pm »
Note that for a 16-bit read, both /UB and /LB need to be pulled low along with /OE (and qualified by LUSERRAMx).

They are, U8 takes care of that. They are both low when LxWs are either low or hi, and only one is low when a byte write happens.
My mistake - sorry.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #64 on: January 26, 2025, 10:48:39 pm »
I drew the time diagrams for writing without any delay and with delay on A17, LB, UB only, no flip flops. The one without delay is worrisome, I see troubles.
The one with delays on A17, LB, UB looks ok.
Noooow, I also drew the reading cycle aaand it does not look good. Or it may be ok, depends where the data is strobed.
The strobe interval is only about 30ns before LUSERRAMx goes high because that line is part of the address and the address to data valid is 110ns.
HM628128 allows about 50ns more data valid.
Can you guess at what point in my scope captures the read data is latched in the processor?
An exercise of imagination...? I may have to go to two chips only to eliminate the LUSERRAMx from the address and keep the LB, UB scheme.

Cheers,
Miti
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #65 on: January 27, 2025, 01:35:12 am »
Going with two FRAM chips might preserve your sanity, but I still think it's doable with one.

The CPU strobing control is implemented with gates and not inside a PAL, thankfully, so read and write timing can be determined.  The gates are in the processor schematic block B "Address Decoding".

I'll save you some time and say that data is latched into the CPU on the rising edge of LOE.  LOE is derived from LAS (address strobe) and the R/LW signal.  Perhaps the name is misleading, but the rising edge of LAS is when the incoming data is latched.

LAS also goes to PAL U114 where it is combined which a bunch of address lines to create strobes for specific address ranges, two of which are LUSERRAM0 and LUSERRAM1.  So, LUSERRAMx will coincide with LOE.  But I would base timing off LOE since it does not go through a PAL black box.

You have a couple of examples showing LOE and RAM0 (LUSERRAMx) coinciding: DS1Z_QuickPrint1.png and DS1Z_QuickPrint12.png.

In terms of using LUSERRAMx as an address input and /CE, that is ok as long as the FRAM address inputs [A17:A0] change before or exactly when /CE goes low.  This is because tAS (address setup time) is specified as 0ns.  And if you meet this requirement, the access time is tCE (55ns).  If you don't, access time is tAA (110ns).  This seems a little odd when you compare to regular SRAM, but the datasheet acknowledges that is the way it works (but unfortunately doesn't give any further explanation which I'd be interested in hearing why).

EDIT: The timing diagram is from here (pg 5-3), plus all the detail you'd ever want to know: https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf
« Last Edit: January 27, 2025, 01:42:18 am by MarkL »
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #66 on: January 27, 2025, 03:37:06 am »
Going with two FRAM chips might preserve your sanity, but I still think it's doable with one.

The CPU strobing control is implemented with gates and not inside a PAL, thankfully, so read and write timing can be determined.  The gates are in the processor schematic block B "Address Decoding".

I'll save you some time and say that data is latched into the CPU on the rising edge of LOE.  LOE is derived from LAS (address strobe) and the R/LW signal.  Perhaps the name is misleading, but the rising edge of LAS is when the incoming data is latched.

Phew  :phew: thanks Mark! That means I'm safe with one FRAM.

In terms of using LUSERRAMx as an address input and /CE, that is ok as long as the FRAM address inputs [A17:A0] change before or exactly when /CE goes low.  This is because tAS (address setup time) is specified as 0ns.  And if you meet this requirement, the access time is tCE (55ns).  If you don't, access time is tAA (110ns).  This seems a little odd when you compare to regular SRAM, but the datasheet acknowledges that is the way it works (but unfortunately doesn't give any further explanation which I'd be interested in hearing why).

In this case I should delay CE just enough so it comes after A17 is stable. Regardless, LB and UB need delay otherwise they may change before WE rising edge.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #67 on: January 27, 2025, 12:09:06 pm »
Me like this with delay on CE and LB, UB. I think this is it. And it will give me 55ns to data valid for reading as well.
What do you think Mark?
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #68 on: January 27, 2025, 04:45:13 pm »
That looks pretty good.

LUSERRAM0 can go directly to A17.  /CE is derived from LUSERRAM0 and LUSERRAM1, requiring additional gates, so you're automatically going to get your delay there.

I think you're right you may need to delay /UB and /LB a little.  /CE could beat them going high at the end of the cycle instead of /WE, which should also work.

It would be nice if the datasheet provided more detail on /UB and /LB internal operation.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #69 on: January 28, 2025, 03:35:00 am »
Thanks Mark!
Here's the final schematic, I hope, and a preliminary to final layout. It was surprisingly easy to layout.
I've added an option for another inverter, in case I need more delay on /CE which is unlikely.

Cheers,
Miti
Fear does not stop death, it stops life.
 
The following users thanked this post: bingo600

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #70 on: January 28, 2025, 07:15:25 pm »
Looks good.  I think this is what we discussed.

The only minor comment I have is that the 2-4 decoder and six inverters could be simplified to be a pair of AND gates, /LB=LLW*LOE /UB=LUW*LOE, but the logic works as drawn.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #71 on: January 28, 2025, 07:47:40 pm »
FWIW, I set up a quick test on my 8595E to look at the DS1210 behavior vs. the power supply HPWRUP (--> processor reset) to see who wins the race on power off.

By monitoring LUSERRAMx input and LUSERRAMBx output, it's possible to tell when the DS1210 cuts out due to low voltage.

It's close, but the power supply triggers the /RESET first at 4.70V.  This value is above the DS1210 typical spec of 4.62V, but still overlaps with the DS1210 max spec of 4.74V.  So, the weird scenario of a half-word write could happen, but there's too many pre-requisites to be worried about it.  Probably HP should have selected the lower voltage threshold for the DS1210 of 4.37V typ (4.49V max) to have a better margin.

Below is a scope capture of the power off event.  Channel 4, which is monitoring the 5V power supply, was calibrated using a DMM, so I am confident of the voltage value shown on the screen.  You can see the LRAM0 input with the LRAMB0 output continuing to be repeated through the DS1210 right up until the reset stopped the processor.

A test of the other DS1210 on LUSERRAM1 and LUSERRAMB1 showed the same result.

Doesn't affect anything in your design, but I was curious to know.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #72 on: January 29, 2025, 03:22:23 am »
Looks good.  I think this is what we discussed.

The only minor comment I have is that the 2-4 decoder and six inverters could be simplified to be a pair of AND gates, /LB=LLW*LOE /UB=LUW*LOE, but the logic works as drawn.

Yes, you're right, I didn't think to use the LOE line. However, one AND gate would not give me the necessary delay, so I still need to use a series of buffers.
Also, the cost of two gates is about the same as one decoder and I don't have to route another line so I'll keep it as is for now.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #73 on: January 29, 2025, 03:28:47 am »
FWIW, I set up a quick test on my 8595E to look at the DS1210 behavior vs. the power supply HPWRUP (--> processor reset) to see who wins the race on power off.

By monitoring LUSERRAMx input and LUSERRAMBx output, it's possible to tell when the DS1210 cuts out due to low voltage.

It's close, but the power supply triggers the /RESET first at 4.70V.  This value is above the DS1210 typical spec of 4.62V, but still overlaps with the DS1210 max spec of 4.74V.  So, the weird scenario of a half-word write could happen, but there's too many pre-requisites to be worried about it.  Probably HP should have selected the lower voltage threshold for the DS1210 of 4.37V typ (4.49V max) to have a better margin.

Below is a scope capture of the power off event.  Channel 4, which is monitoring the 5V power supply, was calibrated using a DMM, so I am confident of the voltage value shown on the screen.  You can see the LRAM0 input with the LRAMB0 output continuing to be repeated through the DS1210 right up until the reset stopped the processor.

A test of the other DS1210 on LUSERRAM1 and LUSERRAMB1 showed the same result.

Doesn't affect anything in your design, but I was curious to know.

Interesting test and ...woow, NICE SCOPE!!!
I selected a supervisor with a threshold voltage of 4.63V but I may need to go down to 4.38V to avoid any issues.
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #74 on: January 29, 2025, 03:58:57 am »
...
Interesting test and ...woow, NICE SCOPE!!!
Thanks - It's an R&S MXO4 4-ch 12-bit 1.5GHz.  I'm still learning to be proficient with it and I really like the screen.  Unfortunately it's not ready to be my daily driver as it's still a bit green.  I submitted six bugs on it today, and there's a seventh that I'm having trouble re-creating.  But that's a topic for another thread.  I used it on this test because I wanted the extra precision for the single-shot capture.

Quote
I selected a supervisor with a threshold voltage of 4.63V but I may need to go down to 4.38V to avoid any issues.
I think the reset you have is going to be fine.  The likelihood of the weird case happening is extremely small, and it's no worse than the old SRAM module.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #75 on: January 30, 2025, 08:46:35 pm »
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.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #76 on: January 30, 2025, 09:15:09 pm »
Thanks Mark! No, I won’t bother, I go hardware.
Fear does not stop death, it stops life.
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #77 on: January 31, 2025, 02:19:14 am »
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
Fear does not stop death, it stops life.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2330
  • Country: us
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #78 on: January 31, 2025, 09:50:49 pm »
Yum, test points everywhere.  Should be interesting...
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1487
  • Country: ca
Re: Has anyone replaced HP8591(E) SRAM by FRAM?
« Reply #79 on: February 02, 2025, 02:35:12 am »
Boards are on order. Now I can focus on another project out of 25 currently in the pipe.  :-DD
Fear does not stop death, it stops life.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf