Has anyone replaced HP8591(E) SRAM by FRAM? - Page 1
Forum section: electronics / repair

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 09, 2024, 11:15:11 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: December 12, 2024, 11:41:21 pm
content: 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,MitiEdit: There is an old model of memory board and a new one. I have the new type.

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 13, 2024, 01:40:25 pm
content: I don't know if my memory board is new or old but it's the same as described in the attached pdf.

author: squadchannel
author_rank: Frequent Contributor
timestamp: December 13, 2024, 02:03:05 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: December 13, 2024, 03:48:42 pm
content: @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 elementsand they save the content at power down.

author: MarkL
author_rank: Unknown
timestamp: December 13, 2024, 04:48:28 pm
content: Quote from: Greybeard on December 09, 2024, 11:15:11 pmThat 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.

author: Miti
author_rank: Super Contributor
timestamp: December 13, 2024, 05:04:46 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: December 13, 2024, 06:37:51 pm
content: I think the part number for the connector is 1734101-5 from TE Connectivity.

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 14, 2024, 06:48:57 pm
content: Quote from: Miti on December 12, 2024, 11:41:21 pmDon'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.

author: Miti
author_rank: Super Contributor
timestamp: December 14, 2024, 10:29:12 pm
content: Quote from: Greybeard on December 14, 2024, 06:48:57 pmYou 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.

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 15, 2024, 12:33:33 am
content: OK, that sounds “a little” more difficult than I had hoped…

author: Miti
author_rank: Super Contributor
timestamp: December 15, 2024, 12:56:48 am
content: Quote from: Greybeard on December 15, 2024, 12:33:33 amLooking 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.

author: squadchannel
author_rank: Frequent Contributor
timestamp: December 15, 2024, 01:05:55 am
content: 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.also, yeah, it slow.my choice the 90ns FM28V100, but at$40(each $10).used to be able to get it for $10, but it's getting so expensive. jlc sell $10.

author: Miti
author_rank: Super Contributor
timestamp: December 18, 2024, 02:14:10 pm
content: Does anybody knows an IC that can delay a falling edge of a digital signal with minimum delay on the rising edge?Thanks,Miti

author: Miti
author_rank: Super Contributor
timestamp: December 20, 2024, 03:53:07 am
content: I have a preliminary schematic. Can you please review and comment? What's missing is a supervisor.

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 25, 2024, 01:48:47 pm
content: 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 twoOECE signals.

author: Miti
author_rank: Super Contributor
timestamp: December 27, 2024, 03:02:20 am
content: Quote from: Greybeard on December 25, 2024, 01:48:47 pmWhich two OE signals?

author: Greybeard
author_rank: Frequent Contributor
timestamp: December 27, 2024, 09:16:01 pm
content: Quote from: Miti on December 27, 2024, 03:02:20 amSorry, I meant CE ...

author: Miti
author_rank: Super Contributor
timestamp: December 30, 2024, 05:11:25 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 07, 2025, 03:00:42 pm
content: 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.Cheers,Miti

author: MarkL
author_rank: Unknown
timestamp: January 07, 2025, 09:38:09 pm
content: Quote from: Miti on January 07, 2025, 03:00:42 pmYou 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.

author: Miti
author_rank: Super Contributor
timestamp: January 09, 2025, 07:59:24 pm
content: 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,MitiEdit: Or maybe 74ALVC164245 but it may be harder to layout.

author: MarkL
author_rank: Unknown
timestamp: January 10, 2025, 08:42:35 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 11, 2025, 06:21:32 pm
content: 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?

author: MarkL
author_rank: Unknown
timestamp: January 11, 2025, 11:38:45 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 12, 2025, 02:41:15 am
content: 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

author: MarkL
author_rank: Unknown
timestamp: January 14, 2025, 09:03:07 pm
content: 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?

author: Greybeard
author_rank: Frequent Contributor
timestamp: January 15, 2025, 12:40:15 am
content: Very well done.U6 is missing in the PCB view.

author: Miti
author_rank: Super Contributor
timestamp: January 15, 2025, 01:38:32 am
content: Quote from: Greybeard on January 15, 2025, 12:40:15 amThis is dynamic. I've already modified the schematic. As I said, the PCB was very preliminary.

author: Miti
author_rank: Super Contributor
timestamp: January 15, 2025, 02:01:48 am
content: Quote from: MarkL on January 14, 2025, 09:03:07 pmGood 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.

author: Miti
author_rank: Super Contributor
timestamp: January 15, 2025, 08:13:33 pm
content: 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

author: MarkL
author_rank: Unknown
timestamp: January 15, 2025, 09:58:17 pm
content: Quote from: Miti on January 15, 2025, 08:13:33 pmI'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/#msg1013805I 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.

author: Miti
author_rank: Super Contributor
timestamp: January 15, 2025, 11:49:48 pm
content: Quote from: MarkL on January 15, 2025, 09:58:17 pmIsn'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.

author: MarkL
author_rank: Unknown
timestamp: January 16, 2025, 12:08:12 am
content: Quote from: Miti on January 15, 2025, 11:49:48 pmYes. 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.

author: MarkL
author_rank: Unknown
timestamp: January 16, 2025, 06:52:03 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 16, 2025, 11:11:53 pm
content: Quote from: MarkL on January 16, 2025, 06:52:03 pmThat'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.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.

author: MarkL
author_rank: Unknown
timestamp: January 17, 2025, 08:24:47 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 17, 2025, 09:23:49 pm
content: 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,BYTESwhere 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,16384mbrd 16269312,16384mbrd 16285696,16384...mbrd 16760832,16384It 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

author: Miti
author_rank: Super Contributor
timestamp: January 17, 2025, 10:29:43 pm
content: Quote from: MarkL on January 17, 2025, 08:24:47 pmTwo 4451 to multiplex 16 bit to 8 bit. The selection line is A18 ( DS1250 has A18 to A0 address lines).Quote from: MarkL on January 17, 2025, 08:24:47 pmYes they can. LUSERRAM0 is connected directly to A17 and LUSERRAM1 through an inverter to the same A17./CE cannot be used in this case.Quote from: MarkL on January 17, 2025, 08:24:47 pmYes, 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.

author: MarkL
author_rank: Unknown
timestamp: January 18, 2025, 12:37:13 am
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 18, 2025, 04:34:45 am
content: Quote from: MarkL on January 18, 2025, 12:37:13 amBy 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.

author: Miti
author_rank: Super Contributor
timestamp: January 18, 2025, 07:00:47 pm
content: 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...

author: Miti
author_rank: Super Contributor
timestamp: January 18, 2025, 09:33:57 pm
content: Quote from: MarkL on January 14, 2025, 09:03:07 pmHere 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) 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

author: MarkL
author_rank: Unknown
timestamp: January 21, 2025, 11:48:14 pm
content: Quote from: Miti on January 18, 2025, 09:33:57 pmI 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.

author: Miti
author_rank: Super Contributor
timestamp: January 22, 2025, 03:22:28 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 22, 2025, 08:53:01 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 22, 2025, 09:21:03 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 23, 2025, 12:06:36 am
content: Quote from: Miti on January 22, 2025, 09:21:03 pmSorry, 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.

author: Miti
author_rank: Super Contributor
timestamp: January 23, 2025, 12:20:33 am
content: Quote from: MarkL on January 23, 2025, 12:06:36 amCheck FM22L16 at LCSC.

author: Miti
author_rank: Super Contributor
timestamp: January 23, 2025, 01:35:33 am
content: Quote from: MarkL on January 22, 2025, 08:53:01 pmActually 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.

author: Miti
author_rank: Super Contributor
timestamp: January 23, 2025, 02:59:05 pm
content: I’ve checked a professional design for the FRAM safe power up schematic. They pull /ZZ low with the reset line from the supervisor.

author: MarkL
author_rank: Unknown
timestamp: January 24, 2025, 01:30:39 am
content: Quote from: Miti on January 23, 2025, 01:35:33 amSure, 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.

author: Miti
author_rank: Super Contributor
timestamp: January 24, 2025, 03:38:59 am
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 24, 2025, 04:07:07 am
content: Quote from: MarkL on January 24, 2025, 01:30:39 amYes, I saw that 450us and I didn't like it. And as you said, the SW may wait for the FRAM in that application.Quote from: MarkL on January 24, 2025, 01:30:39 amThere 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.Quote from: MarkL on January 24, 2025, 01:30:39 amThat 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

author: MarkL
author_rank: Unknown
timestamp: January 24, 2025, 04:00:12 pm
content: Quote from: Miti on January 24, 2025, 04:07:07 amThere 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).

author: Miti
author_rank: Super Contributor
timestamp: January 24, 2025, 05:08:45 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 24, 2025, 10:13:23 pm
content: Quote from: Miti on January 24, 2025, 05:08:45 pmThat'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.

author: MarkL
author_rank: Unknown
timestamp: January 24, 2025, 11:24:21 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 25, 2025, 03:19:12 am
content: Quote from: MarkL on January 24, 2025, 11:24:21 pmYes, 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 1S.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.

author: MarkL
author_rank: Unknown
timestamp: January 25, 2025, 09:33:51 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 25, 2025, 11:56:42 pm
content: Quote from: Miti on January 25, 2025, 03:19:12 amThe 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.

author: Miti
author_rank: Super Contributor
timestamp: January 26, 2025, 03:43:20 am
content: Quote from: MarkL on January 25, 2025, 09:33:51 pmIt 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.

author: Miti
author_rank: Super Contributor
timestamp: January 26, 2025, 04:08:24 am
content: Quote from: MarkL on January 25, 2025, 11:56:42 pmI 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.Quote from: MarkL on January 25, 2025, 11:56:42 pmThey 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.Quote from: MarkL on January 25, 2025, 11:56:42 pmI honestly don't have time for that, I've put enough time in this project. I'll grow a Greybeard soon...

author: MarkL
author_rank: Unknown
timestamp: January 26, 2025, 06:25:23 pm
content: Quote from: Miti on January 26, 2025, 04:08:24 amMy mistake - sorry.

author: Miti
author_rank: Super Contributor
timestamp: January 26, 2025, 10:48:39 pm
content: 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

author: MarkL
author_rank: Unknown
timestamp: January 27, 2025, 01:35:12 am
content: 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

author: Miti
author_rank: Super Contributor
timestamp: January 27, 2025, 03:37:06 am
content: Quote from: MarkL on January 27, 2025, 01:35:12 amPhewthanks Mark! That means I'm safe with one FRAM.Quote from: MarkL on January 27, 2025, 01:35:12 amIn 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.

author: Miti
author_rank: Super Contributor
timestamp: January 27, 2025, 12:09:06 pm
content: 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?

author: MarkL
author_rank: Unknown
timestamp: January 27, 2025, 04:45:13 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 28, 2025, 03:35:00 am
content: 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

author: MarkL
author_rank: Unknown
timestamp: January 28, 2025, 07:15:25 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 28, 2025, 07:47:40 pm
content: 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.

author: Miti
author_rank: Super Contributor
timestamp: January 29, 2025, 03:22:23 am
content: Quote from: MarkL on January 28, 2025, 07:15:25 pmYes, 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.

author: Miti
author_rank: Super Contributor
timestamp: January 29, 2025, 03:28:47 am
content: Quote from: MarkL on January 28, 2025, 07:47:40 pmInteresting 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.

author: MarkL
author_rank: Unknown
timestamp: January 29, 2025, 03:58:57 am
content: Quote from: Miti on January 29, 2025, 03:28:47 amThanks - 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.QuoteI 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.

author: MarkL
author_rank: Unknown
timestamp: January 30, 2025, 08:46:35 pm
content: 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/#msg5786259In 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.

author: Miti
author_rank: Super Contributor
timestamp: January 30, 2025, 09:15:09 pm
content: Thanks Mark! No, I won’t bother, I go hardware.

author: Miti
author_rank: Super Contributor
timestamp: January 31, 2025, 02:19:14 am
content: 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

author: MarkL
author_rank: Unknown
timestamp: January 31, 2025, 09:50:49 pm
content: Yum, test points everywhere. Should be interesting...

author: Miti
author_rank: Super Contributor
timestamp: February 02, 2025, 02:35:12 am
content: Boards are on order. Now I can focus on another project out of 25 currently in the pipe.

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

author: Uup
author_rank: Regular Contributor
timestamp: February 17, 2025, 05:17:27 am
content: Actually, your reasoning is sort of right.Your reasoning for the failure is on the correct path, however, the cause is not.The reason why it is not working is because you have a logic error, or mistake, in your schematic.Take a closer look at the upper address line (A18) and you will see your error.edited poor grammar

author: Miti
author_rank: Super Contributor
timestamp: February 17, 2025, 11:05:09 am
content: Quote from: Uup on February 17, 2025, 05:17:27 amI don’t see it. Can you please elaborate?

author: Uup
author_rank: Regular Contributor
timestamp: February 17, 2025, 11:35:39 am
content: Quote from: Miti on February 17, 2025, 11:05:09 amThere is an I/O logic error with A18. Take another look… and think aboutI/OPerhaps the notion where ‘the ability to see a mistake is inversely proportion to the amount of times it is checked’ applies here.I haven’t read this thread but was curious and wanted to help with troubleshooting, so looked over the schematic.It must be why the error stood out to me and not to you, since you’ve looked at it so many times and I looked at it for the first time.

author: Uup
author_rank: Regular Contributor
timestamp: February 17, 2025, 12:02:50 pm
content: Here’s another clue.I/OA0 / MA1A1 / MA2A2 / MA3...A18 / ?

author: Miti
author_rank: Super Contributor
timestamp: February 17, 2025, 12:22:18 pm
content: Quote from: Uup on February 17, 2025, 12:02:50 pmAh, exactly what I thought. There’s no A18 on the FRAM board. It is only used to read/ write the 16 bits memory in two chunks of 8 bits. When A18 is low I access the LB, when it is high I access the UB. No error in logic there. Also, the address lines are not I/Os. From the memory perspective, they’re Is only.

author: Uup
author_rank: Regular Contributor
timestamp: February 17, 2025, 12:39:42 pm
content: Quote from: Miti on February 17, 2025, 12:22:18 pmYou wrote above "when it is high" but...A18 is all input. There is no driver or source signal for A18.Since you don’t see the error, then perhaps the error is with me and I’m interpreting your schematic incorrectly?I just took another look at your schematic and there is no driver source for A18.Every other (used) input in the schematic has a corresponding driver source, either from the header or from a device, with the exception of A18.What is the driver source for A18?

author: Miti
author_rank: Super Contributor
timestamp: February 17, 2025, 12:58:24 pm
content: Quote from: Uup on February 17, 2025, 12:39:42 pmSame as all the other address lines. The header, the programmer.

author: Uup
author_rank: Regular Contributor
timestamp: February 17, 2025, 01:06:41 pm
content: Quote from: Miti on February 17, 2025, 12:58:24 pmThat's not in the schematic.What pin on the header is connected to?

author: Miti
author_rank: Super Contributor
timestamp: February 17, 2025, 01:39:27 pm
content: Quote from: Uup on February 17, 2025, 01:06:41 pmOk, I think I know where the confusion comes from. The schematic that you attached is NOT of the FRAM module, it is the programming adapter, an interface between a regular programmer, such as TL866II Plus, Xeltek, etc. to the FRAM module, and it's intended to copy the content of the battery backed RAM module used in the HP859x spectrum analyzers into the FRAM module. First picture in reply #77. U1 is just a header, not the memory itself.

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

author: MarkL
author_rank: Unknown
timestamp: February 18, 2025, 01:32:10 am
content: Quote from: Miti on February 17, 2025, 07:50:38 pmLPF doesn't control RESET. LPF only goes to the RTC. RESET is controlled by HPWRUP coming from the power supply.It looks like the 3.3V is stable before any activity starts in Power_Up.png.QuoteWhy is /CE always low? Are the scope captures not zoomed out enough?/WE (or /CE) going high should be ending the write cycle. That's where everything needs to be stable.Why do you name one of your captures "Writing_LB_Fall.png"? What's failed? In the datasheet, Write Cycle Timing 3 allows /WE going low to preceed changes in /UB/LB.More importantly, does the analyzer boot? Does it say anything? Are any of the DS1 thru DS16 status LEDs lit? (These LEDs are not populated on all boards, unfortunately, but the pads are there, near U57.)

author: Miti
author_rank: Super Contributor
timestamp: February 18, 2025, 03:07:05 am
content: Quote from: MarkL on February 18, 2025, 01:32:10 amI meant local reset on my board, not system reset.Quote from: MarkL on February 18, 2025, 01:32:10 amYes but not before LPF, which also acts as local reset, goes high.Quote from: MarkL on February 18, 2025, 01:32:10 amThese scope shots are from the programmer, not from the SA. That's how the programmer works.Quote from: MarkL on February 18, 2025, 01:32:10 amFalling edge and rising edge of WE.Quote from: MarkL on February 18, 2025, 01:32:10 amI haven't tried yet. I want to see it running with the programmer first.

author: MarkL
author_rank: Unknown
timestamp: February 18, 2025, 02:51:41 pm
content: Quote from: Miti on February 18, 2025, 03:07:05 amSorry - guess I missed that.

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

author: Miti
author_rank: Super Contributor
timestamp: February 22, 2025, 03:05:18 pm
content: Quote from: MarkL on February 18, 2025, 01:32:10 amIt does this, I forgot to look at the LEDs. Does it need to be initialized? Are the characters stored in the RAM? If the battery and the supercap die, are the calibration constants the only things that we lose?Cheers,Miti

author: MarkL
author_rank: Unknown
timestamp: February 22, 2025, 06:49:40 pm
content: Well, that's good sign that it boots! It wouldn't get very far if the FRAM wasn't performing its duty as the system's SRAM, at least partially. Even though garbage is being displayed, does it respond to any controls? Can you talk to it via GPIB? Is anything working?I asked about the LEDs because there are some low-level checks performed at boot on the various buses, SRAM, ROM, etc., and results are displayed on the LEDs. If the FRAM wasn't working right, the unit should fail the SRAM tests (at a minimum) and the LEDs may provide clues. See page 632 in the Assembly Repair Manual for detail on the LEDs. If you don't have the LEDs populated, maybe just run down the pads with a pair of probes attached to an LED."Characters stored in the RAM"? No, not that I'm aware. Maybe the FRAM card is interfering with the video controller bus access? Or interfering with a region of EPROM where the characters are stored? The video controller has a DMA controller in it, but HP is not using it in these units. It's all memory mapped I/O for the processor to talk to the video controller.There is an initialization procedure in the Assembly Repair Manual on page 204. Even if you can manage to navigate through it, I don't think it's going to resolve the garbage.If the battery dies, yes, the calibration constants are gone, which are the most important thing. You're also going to lose DLP's, stored setups, traces, variables, video setup, display units, serial number, and possibly the model number.For the calibration constants, Tom over on HPAK io.groups has developed a GPIB utility to restore them using the output from "CAL DUMP":https://groups.io/g/HP-Agilent-Keysight-equipment/message/149983If you manage to get control of the unit, you could grab a "CAL DUMP" snapshot from your old SRAM and restore them to the new FRAM after doing the initialization procedure.

author: Miti
author_rank: Super Contributor
timestamp: February 22, 2025, 07:57:10 pm
content: Bingo!Dead bug working!My first instinct to delay /WE was correct. Once I've moved the /WE after the /LB, /UB, all the stars aligned. I copied the RAM into FLASH and everything is there.It woks fine for more than 30 minutes.Back to the drawing board to add the flip-flops. I will also change the package for U3, U4 to TSSOP because what I have now is smaller, but not readily available.Meanwhile I've also laid out the two chip version. I may clean up and order that version as well.Cheers,MitiEdit: Oops, looks like I need a diode series with the battery. The clock wasn't showing up and I figured out that it was charging my battery, I assume through the RTC interrupt line and R105. I'll think a bit about the circuit around the battery. A Schottky diode has too much reverse current, a silicon diode has a high forward voltage drop. I may need a more elaborate circuit in that area.

author: Miti
author_rank: Super Contributor
timestamp: February 22, 2025, 10:17:04 pm
content: Hey Mark,I think lesson learned from here is, /LB and /UB are latched, most likely on the falling edge of /WE, any change after that is ignored.I don't understand why they don't mention this in the data sheet and we need to discover it the hard way.Edit: I've added some new scope screen shots. I need a faster clock, somewhere around 30 to 33MHz may be ideal, now I'm using 25MHz.Edit1: Wait, cannot be latched on the falling edge of /WE, at least not in the /CE controlled cycle. Are there different rules in /CE vs /WE controlled?

author: MarkL
author_rank: Unknown
timestamp: February 24, 2025, 07:04:01 pm
content: Interesting that a delay on /WE makes this work.Without the delay added, granted the design is not explicitly represented in the timing diagrams, but at the same I don't think violates any timing specifications. Plus the text description of operation says that it's the rising edge of /WE and /CE that matter.Maybe a case of the datasheet being overly ambiguous and/or sloppily written?I've ordered a FM22L16 to see if I can discover the reality. I can use an STM32H7 nucleo board that I have laying around as a pattern generator which will allow me to independently control each FRAM control signal with 2.5ns granularity. With software it will be easy to put things in any arbitrary order. Do you have a scope capture when the FRAM board is not working (e.g., without the delay)?It's even more interesting that your analyzer booted at all. I pulled the SRAM from mine and it doesn't boot. So, in the non-delay case, the FRAM module is *partially* working or marginal.Instead of a faster oscillator, you might want to consider a SN74LVC1G123 monostable multivibrator with some additional logic, or even a simple RC with some Schmitt triggered logic inputs. This would provide a more predictable delay than a free-running oscillator. There are also silicon delay lines (e.g., DS1100L-xx series), but not cheap.

author: Miti
author_rank: Super Contributor
timestamp: February 24, 2025, 07:38:49 pm
content: Quote from: MarkL on February 24, 2025, 07:04:01 pmNo, I don’t have. I only started saving screenshots after the programmer, and the SA, started working.I’m curious what you find out with your experiment.Quote from: MarkL on February 24, 2025, 07:04:01 pmMy guess is because the 16bit was working. It’s only the 8bits that wasn’t working.Quote from: MarkL on February 24, 2025, 07:04:01 pmI’ll take a look at the monostable. I can’t use delay line, the delay must happen only on the falling edge, rising edge must be fast.Edit: Yes, I could use an AND gatebut at $12 they are expensive.

author: Miti
author_rank: Super Contributor
timestamp: February 25, 2025, 03:06:40 am
content: Quote from: MarkL on February 24, 2025, 07:04:01 pmDo you have a schematic? I can't figure out how to do this.Edit: Looking at the application data sheet, I don’t think I can get a delay below about 80nS with 74LVC123.

author: MarkL
author_rank: Unknown
timestamp: February 25, 2025, 08:33:32 pm
content: Quote from: Miti on February 25, 2025, 03:06:40 amYes, it looks like the LVC can't get below that. There are some other series that are a little faster, but still probably not what you want. I can draw it if you're still curious how it could be used to delay a leading edge.A plain RC delay can do 1's or 10's of nanosecond speeds. See below. Any kind of delay element or circuit, like a series of slow gates or the silicon delay line, can take the place of the RC. An 8 channel bus driver with the gates daisy-chained is another way to get a pile of gate delays.There's a somewhat oddball and dated part that's cheaper than a silicon delay line: 74LS31 ($1.27 at Mouser). It's a collection of elements with different delays. The elements are controlled to specific tolerances in manufacture and they are in the delay range you want.

author: MarkL
author_rank: Unknown
timestamp: February 25, 2025, 08:56:01 pm
content: Eh, the 74LS31 is not so great after looking deeper into the datasheet at min/max delay bounds over extreme temperature and Vcc. Probably remove that from consideration.

author: Miti
author_rank: Super Contributor
timestamp: February 26, 2025, 04:42:02 pm
content: Quote from: MarkL on February 24, 2025, 07:04:01 pmActually, I simulated the circuit that you posted and it is not as predictable as one may think. If the repetition rate is high the delay is one, after a long high level, it is different. To be honest I never liked timing circuits that depend on RC circuits. At least with the oscillator I clearly know that the delay is between a bit over one period and a bit under two periods, and that interval is very well defined.I have the new layout for one chip and two chips boards, but I will hold for awhile pending the results from your experiment.Cheers,Miti

author: MarkL
author_rank: Unknown
timestamp: February 27, 2025, 12:03:20 am
content: Quote from: Miti on February 26, 2025, 04:42:02 pmWith the RC delay it's also possible to add some steering diodes: one to limit the peak voltage on the capacitor, and another to discharge it more quickly. Something like below. But point taken it may still not be as predictable as desired.The xx123 is more predictable since internally it's using comparators. The fastest one I can find is about 40ns. It's also possible to build a one-shot out of a pair of high speed comparators to get into the 10ns range, but again those comparators don't come cheap.The pile of gates for delay may not be so bad.Have you tried clocking your delay flip-flops with a function generator? Is there any delay range where the analyzer stops working?I'm working through some issues with the board support package for this STM32H7 Nucleo board that I have. I can get get it working the way I want for this test, but cite the 53 page thread "Is ST Cube IDE a piece of buggy crap?" The answer is "yes".https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/

author: Miti
author_rank: Super Contributor
timestamp: February 27, 2025, 04:02:35 am
content: Quote from: MarkL on February 27, 2025, 12:03:20 amNo, I have not but the good part about the oscillator is that I can calculate its frequency exactly, based on where I want my /WE pulse to land.Edit: I looked again at the /WE spread scope shot and realized it gives me a lot of info. I think the timing is acceptable as is, proof is that the SA works well for many hours. The minimum /WE pulse is 16nS, the shot shows about 20nS. To make it even better, I could move it to the left about 6-7 nS (change the oscillator from 25MHz to 30MHz), and that should also shorten the spread by 13.34nS.

author: Miti
author_rank: Super Contributor
timestamp: March 04, 2025, 11:26:07 am
content: Hi Mark,Did you have any success with the FRAM and the Nucleo?Miti

author: MarkL
author_rank: Unknown
timestamp: March 04, 2025, 03:26:12 pm
content: Hi Miti,I've resolved the SW issues with the Nucleo board, and have the FRAM and a break-out board in-house. I need to assemble it and write the test SW. Still a bit more to do. I have some other activities getting in the way at the moment, and I apologize for the delay.I know you want to get your board done. You have a working solution, and I won't be insulted if you decide to proceed.The general plan is to be able to read/write the FRAM under SW control via GPIO bit-bang for initialization and read-back with known data, and then use the FMC (memory controller) peripheral to stream control pin changes clocked at 200MHz to the FRAM control inputs. The data I/O pins from the FMC will drive the control inputs on the FRAM, so any arbitrary sequence of control ordering can be created, and at any timing, by crafting the data out pattern. After streaming some high-speed test writes using this method, all locations will be read back at slower speed and checked for valid writes in the expected locations, and invalid data or writes to a wrong location.Previously, I thought I could achieve 2.5ns granularity, but there is a "CLK+1" in the FMC timing specifications, so I will get 5ns granularity with a 400MHz processor clock (that's the max). I verified the 5ns FMC timing with a scope on the Nucleo board, so I am confident this approach will work. 5ns should be sufficient for our purposes, but if something is really close, there's always physical coax delays that can be introduced.I kind-a wish I hadn't sold my 300MHz 24-channel Agilent 16720A pattern generator several years ago. I never used it, but it would have been perfect for this.I will post updates.

author: Miti
author_rank: Super Contributor
timestamp: March 04, 2025, 04:20:33 pm
content: Insulted? No, I don’t think there’s reason to feel insulted. There’s a more selfish reason behind this waiting. I want to see if there is an eureka moment that allows me to simplify the board. Now I hope this confession doesn’t insult you.

author: Miti
author_rank: Super Contributor
timestamp: March 07, 2025, 01:56:37 pm
content: What do you think about this circuit instead of the flip-flop or RC delay. Three 74HC buffers give me a delay of a bit under 20nS, six should delay by almost 40nS. No clock, no RC. I should give it a try.

author: MarkL
author_rank: Unknown
timestamp: March 07, 2025, 04:09:33 pm
content: I like the gate delay approach. That diagram works.If you're still in the experimenting frame of mind, you could use non-inverting buffers (e.g., xx244, xx365, xx367) and zero-ohm SMD links between the gates. Then you could experiment with delay between 0 and 8/6 gates.On the test setup, I had some time to build the FRAM breakout board. Next step is to get it wired up to the Nucleo board. I'll probably need to use some tiny coax runs + series termination for the control pins because of the edge speed. The header pins stick out the bottom about 0.4" so it's convenient to do the Nucleo connections all on one side, and probing on the other.

author: Miti
author_rank: Super Contributor
timestamp: March 08, 2025, 02:27:03 pm
content: Quote from: MarkL on March 07, 2025, 04:09:33 pmNo, I'm not, so I will do this. Options on the final board.

author: Miti
author_rank: Super Contributor
timestamp: March 29, 2025, 08:47:48 pm
content: Hi, I'm back.I have finalized three version of this FRAM boards. Single FRAM chip with flip flop delay on /WE, single chip with buffer delay, and dual chip. I decided to order only the last two, not only because of the boards cost, but because the shipping for two boards was $2.15 CAD, while for 3 boards it jumped to over $ 15.I received the boards yesterday and to my surprise one has the mounting holes plated and one un-plated. Whyyyyyy?The boards are copy -> paste -> modify so why are they different? 3D view in Kicad shows un-plated and so does the JLCPCB 3D view.Miti

author: Miti
author_rank: Super Contributor
timestamp: April 08, 2025, 02:22:55 am
content: Ok, so the answer to the question "Has anyone replaced HP8591(E) SRAM by FRAM?" is yes, I have.Here is the version with single FRAM chip and the /WE control signal is delayed with 74HC14 inverters only, no flip-flops and oscillator. I've made theHCbold because is important for the correct delay. Not LVC, not AHC, but HC. For D1, or D2, pick one, whichever you prefer, they should be both low reverse current and low forward voltage drop so they should work, I have not tested long term though. I also have the boards for a dual FRAM version, the glue logic is simpler but the main cost is the FRAM so it doesn't make sense to spend more if the single chip works so well. I have the parts, I may populate and test one board just for fun one rainy day.If anybody is interested in this project, likes it, and wants to make a small contribution to my effort, please PM me and I'll send you my Paypal.Cheers,Miti

author: Miti
author_rank: Super Contributor
timestamp: April 08, 2025, 02:54:29 am
content: The programmer:Here is an adapter board that helps with the transfer of content from the original HP8590 RAM to the FRAM using a memory programmer.Tested with Xeltek SP5000 and TL 866II Plus. Xeltek works very well, TL 866 needs external 5V on the pins 16 and 32 of the pin header, otherwise it will not supply the voltage to release the reset line. I have used a programmable power supply set to 5V, 100mA. Calibration constants are there, personalities, settings, you just need to set the date and time. Make sure you remove the jumper while reading the original RAM to avoid any risk of altering the content, and install it to write into the FRAM. Also save it somewhere.Enjoy!

author: MarkL
author_rank: Unknown
timestamp: April 08, 2025, 03:01:48 pm
content: Great - glad everything is working with the HC delay!I've been traveling for the last several weeks but will get back to finishing the FRAM characterization, if only for informational purposes at this point. Will post here when done.