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

Miti and 1 Guest are viewing this topic.

Online Miti

  • Super Contributor
  • ***
  • Posts: 1405
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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: 269
  • 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: 1405
  • 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: 1405
  • 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: 1405
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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: 1405
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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: 1405
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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 »
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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...
 

Online Miti

  • Super Contributor
  • ***
  • Posts: 1405
  • 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.
 

Offline MarkL

  • Supporter
  • ****
  • Posts: 2302
  • 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: 1405
  • 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: 1405
  • 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: 1405
  • 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf