+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: How to test memory in an HP48 RAM card (/thread-13070.html)
Pages: 1 2
How to test memory in an HP48 RAM card - mfleming - 06-04-2019 06:17 PM
Hi all,
Hope someone might help with this question. After months of scanning TAS for a reasonably priced 128K RAM card for a 48SX/GX, I finally gave up and decided to make my own. Using plans from hpcalc.org and updating the BOM to a Cypress memory device, I managed to assemble a half dozen cards. Each one came up with the initial Invalid Card Data warning, after which I initialized by storing and purging a port variable (HP48SX). All seems well - I can store and recall variables, merge memory, and retain content on battery power when the card is removed from the calculator.
I wonder, does initialization test every byte of the memory on the card? Visual inspection indicates every pin is properly soldered. I'd just like to be sure all is well, and that I haven't left an address line floating or something.
Thanks,
~Mark
RE: How to test memory in an HP48 RAM card - rprosperi - 06-04-2019 06:36 PM
Mark,
You may want to try using PINIT to ensure it behaves the same as a 'normal' card. It should complete w/o errors/messages, but also should not affect any of your data that was already on the card. It's purpose is to initialize all ports that aren't already initialized; so for a brand-new card, it should initialize it, but leave a used one as-is.
Also, a real card will lose its contents if you change the card battery while the card is inserted in a 48GX, if the 48 is not powered-on. For some odd reason, the 48 only provides power to the card while turned-on. If your card does not lose memory when doing this, I suppose it's not necessarily a problem per-se, but you may want to track down why it behaves differently.
As far as further memory testing, make some huge 127KB object, e.g. a list containing the index of a FOR NEXT loop, and save it to the port/card, then add smaller objects until all the RAM is 'used up'. Then recall those smaller objects at the end of port RAM to verify they are intact. If so, the home-made card is probably OK.
RE: How to test memory in an HP48 RAM card - mfleming - 06-04-2019 10:36 PM
Bob,
When first working on my own card, I was surprised to find that power was removed when the calculator is shut off. I should have known better though, hot-plugging wasn't the fashion back then. The capacitor across the device power pins does keep memory alive for a short time after power and battery are removed thanks to a 1 uA standby current draw.
I'm limited to an HP 48SX at the moment, so the PINIT command is not available. There is a noticeable pause when purging a variable for the first time which leads me to suspect some sort of memory test or "formatting" is going on, but I've never read about any details.
I'm probably concerned over nothing, but I may try the brute force approach you mention. Having the address space wrap around a given address bit would certainly cause corruption at some point!
~Mark
RE: How to test memory in an HP48 RAM card - rprosperi - 06-05-2019 12:28 AM
I thought of another pretty simple thing to try.
Download PCT 5.55/S from hpcalc: https://www.hpcalc.org/details/2456
This is semi-graphical PC-Tools type file manager, which uses port memory extensively, plus it's fast and much easier to use for managing files. The GX version has been around on hpcalc forever, but it took me a long time to find a stable version for 48SX. This one seems to be the final SX version; all later versions were GX only.
Also, contact me off list if you'd like me to do some testing on a GX.
RE: How to test memory in an HP48 RAM card - pdo - 06-08-2019 12:17 PM
Hello Mark,
Hope you're having fun with your memory card experiments! When I first tried mine (RC48-512) I remember coming across 7394, which I tried for a while before discarding it for some reason, but I think that may be G/GX only. I had intended to write my own test software, but so far have not got round to it :-(
My experience with my own card design has been largely positive, but with an intermittent fault that I have not yet fully resolved. I have been meaning to write this up for a while now, so maybe I should take this opportunity to describe the symptoms. Here goes...
Occasionally, when I switch on the calculator (HP48GX with one of my cards in slot 1), I will get an "invalid data" alert and see that some (possibly all) of the objects I had stored in port 1 are missing. This is accompanied by a low battery warning for the card, even though the battery is relatively fresh.
If I move the card to slot 2 (same battery) then the card will function correctly (after I have reinitialized its contents). It will stay functioning in slot 2 until the card battery naturally expires, which seems to be after about 9 months -- not as long as I was hoping for, but seems reasonable).
This fault event only ever occurs with cards in slot 1, whether or not I have another card in slot 2. I have two prototype cards, both exhibit the same behaviour.
Recently I have been thinking more about this, wanting to track down the issue, so I reinstalled a card in slot 1 with a fresh battery and also fresh calculator batteries (Eneloop rechargeables). However, it's now been two months since I did that and I'm still waiting for the fault to happen again -- sod's law at work here I think!
Meanwhile I was looking at my schematic and wondering about the way I have connected the CdDet signal (pin 37 of the slot connector) as a pullup to VccOn. Should this instead be a pullup to VCC (i.e. card battery power)? My thinking is that maybe there is circuitry in the Yorke chip that only ensures a high-impedance state on CE2 (pin 21 of the connector) when the calculator is off only when CdDet is pulled high or low. But this is just a guess. Also, maybe the pullup/down resistor values I have used are too high and should be reduced.
Any insight you may have in this area would be gladly received :-)
Paul
RE: How to test memory in an HP48 RAM card - rprosperi - 06-08-2019 01:24 PM
(06-08-2019 12:17 PM)pdo Wrote: Occasionally, when I switch on the calculator (HP48GX with one of my cards in slot 1), I will get an "invalid data" alert and see that some (possibly all) of the objects I had stored in port 1 are missing. This is accompanied by a low battery warning for the card, even though the battery is relatively fresh.
If I move the card to slot 2 (same battery) then the card will function correctly (after I have reinitialized its contents). It will stay functioning in slot 2 until the card battery naturally expires, which seems to be after about 9 months -- not as long as I was hoping for, but seems reasonable).
This fault event only ever occurs with cards in slot 1, whether or not I have another card in slot 2. I have two prototype cards, both exhibit the same behaviour.
Have you tested this in more than 1 48GX? I had a GX that behaved very much the same as this with both 3rd party and original HP cards, so I eventually concluded that port-1 in this machine may have had some slight corrosion or intermittent connections.
RE: How to test memory in an HP48 RAM card - pdo - 06-08-2019 01:56 PM
(06-08-2019 01:24 PM)rprosperi Wrote: Have you tested this in more than 1 48GX? I had a GX that behaved very much the same as this with both 3rd party and original HP cards, so I eventually concluded that port-1 in this machine may have had some slight corrosion or intermittent connections.
That's interesting! No, I have only the one 48GX. I've been looking around for another to test against, but they're all so expensive these days :-(
Paul
RE: How to test memory in an HP48 RAM card - mfleming - 06-08-2019 04:41 PM
Hi Paul,
Thanks for the pointer to the port memory test program. Just the thing I was looking for! I'll give it a try this morning.
I remember running across and bookmarking your RAM Card project. I was specifically looking to make a 128K RAM card, and chose the Cypress CY62128ELL memory device. My own design is just an update of several found on hpcalc.org in the Miscellaneous section. The same dual-Schottky power circuit but with a 470K pulldown on the chip CE input. This device conveniently has both a positive and negative logic chip enable.
Have a look at the Cypress Application Note for designing battery-backed systems. It contains some useful information, and refers to the dual-Shottky diode approach we both use as a "legacy design" technique - a nice way of saying old school. One problem the AN identifies is a path to ground from any pull-up connected to the SRAM Vcc through an unpowered processor pin via an input protection diode. You have two pullups on OE/ and WE/, and at 47K they could sink tens of uA. Perhaps that's the source of your battery life conundrum! They shouldn't be needed anyway, since they are don't-care when chip enable is deasserted.
I do drive the CdDet input from Vcc rather than VccOn, but that could be a problem given the AN warning. Although the other card designs do the same thing, I may do one more design change to address that. I've been monitoring card and calculator battery levels but haven't seen anything of note to worry about.
(06-08-2019 01:56 PM)pdo Wrote: That's interesting! No, I have only the one 48GX. I've been looking around for another to test against, but they're all so expensive these days :-(Do as I do and get the "For Parts or Repair" TAS offerings. They're a pain to open but easy to repair, and you don't shell out as much. OTOH, even the high price a pristine model goes for is a fraction of the original retail price! I guess it's the Scot in me that refuses to crack the purse that wide if I don't have to...
Paul
~Mark
RE: How to test memory in an HP48 RAM card - pdo - 06-08-2019 07:12 PM
(06-08-2019 04:41 PM)mfleming Wrote: Have a look at the Cypress Application Note for designing battery-backed systems. It contains some useful information, and refers to the dual-Shottky diode approach we both use as a "legacy design" technique - a nice way of saying old school. One problem the AN identifies is a path to ground from any pull-up connected to the SRAM Vcc through an unpowered processor pin via an input protection diode. You have two pullups on OE/ and WE/, and at 47K they could sink tens of uA. Perhaps that's the source of your battery life conundrum! They shouldn't be needed anyway, since they are don't-care when chip enable is deasserted.
Thanks for pointing out that application note, I hadn't seen it before. The idea that the OE and WE pullups could be draining the battery is certainly worth investigating -- I'll do some experimenting (they're only there as a "just-in-case" measure anyway).
Quote:I do drive the CdDet input from Vcc rather than VccOn, but that could be a problem given the AN warning. Although the other card designs do the same thing, I may do one more design change to address that. I've been monitoring card and calculator battery levels but haven't seen anything of note to worry about.
If you do make the mod I'd be very interested to know if you see any change in behaviour!
Happy hardware hacking :-)
Paul
RE: How to test memory in an HP48 RAM card - BruceH - 06-13-2019 08:51 PM
(06-04-2019 06:17 PM)mfleming Wrote: Hi all,
Hope someone might help with this question. After months of scanning TAS for a reasonably priced 128K RAM card for a 48SX/GX, I finally gave up and decided to make my own. Using plans from hpcalc.org and updating the BOM to a Cypress memory device, I managed to assemble a half dozen cards.
What did you use for the actual board? Is the edge connector a standard size?
(Sorry if this is a dumb question but it's not my area of expertise and I don't even know what to Google for.)
RE: How to test memory in an HP48 RAM card - mfleming - 06-14-2019 02:31 AM
(06-13-2019 08:51 PM)BruceH Wrote: What did you use for the actual board? Is the edge connector a standard size?
I used a 0.8 mm PCB (that's 1/32" in American) and attached a 0.8 mm plastic strip on the other side from the edge connector contacts to get a snug fit in the connector. Two reasons for the undersized PCB; I had originally planned to build up a case from layers of 0.8 mm sheet, and because the PCB maker charged quite a bit more for the non-standard 1.6 mm thick board. I dropped the idea of a built up case since once the card is in a calculator it usually stays there, so who cares what it looks like?
The edge connector contacts are spaced 0.05" apart, but I didn't find a connector that matched on Mouser. I didn't really try anywhere else, so I can't say if it's standard or not. I've spent the last few weeks validating the cards to make sure there's no design flaw that can lead to premature battery exhaustion or calculator problems. I'll provide schematics and Gerber files once I'm sure I won't embarrass myself
HTH,
~Mark
RE: How to test memory in an HP48 RAM card - mfleming - 06-27-2019 01:24 AM
For those who may be interested, I've submitted the design material for the RAM card to hpcalc.org, and you can also find information on github at
https://github.com/mafleming/HP48RamCard
~Mark
RE: How to test memory in an HP48 RAM card - wan - 01-18-2021 06:30 AM
I made a 512k based on Paul's, but there are some modifications: gold fingers flip to the back; the corners of the card is rounded ; 1.6mm board is too thick, change to use 0.6mm board instead(with a 1.2mm small circuit board pasted on the back of the gold finger); cancel two pull-up resistors of we and oe lines.
The card works well so far.
I think the 330 ohm series resistors for data line can be cancelled.
RE: How to test memory in an HP48 RAM card - Jonathan Busby - 01-20-2021 10:14 PM
(06-04-2019 06:17 PM)mfleming Wrote: Hi all,
Hope someone might help with this question. After months of scanning TAS for a reasonably priced 128K RAM card for a 48SX/GX, I finally gave up and decided to make my own. Using plans from hpcalc.org and updating the BOM to a Cypress memory device, I managed to assemble a half dozen cards. Each one came up with the initial Invalid Card Data warning, after which I initialized by storing and purging a port variable (HP48SX). All seems well - I can store and recall variables, merge memory, and retain content on battery power when the card is removed from the calculator.
I wonder, does initialization test every byte of the memory on the card? Visual inspection indicates every pin is properly soldered. I'd just like to be sure all is well, and that I haven't left an address line floating or something.
Thanks,
~Mark
Back in 2015 I bought two 128KiB SRAM cards and two 2MiB SRAM cards for two of my three HP48GXs. I got them from Oleg Rodionov who had designed several sizes of SRAM and F-RAM cards and was selling them on eBay. All the cards worked fine until late last year when the 128KiB RAM card that was merged with IRAM in my Indonesian made HP48GX "crapped out" and gave me a TTRM ( Suffice it to say that I was upset because I had a substantial amount of data, mainly source code, saved on that calc and I don't know where my most recent backup is -- I've moved to Colorado and the backup would probably be in an external HDD in storage but it might be weeks before all my possessions are shipped up here ). I used Oleg's "chkmem" which didn't report any errors, *but*, the built in HP48GX self test *did* report an error on the 128KiB RAM card. I'm in correspondence with Oleg and he said it might be a bad solder joint.
So, my recommendation is to use Oleg's "chkmem" as it seems to be very thorough.
NOTE : I'm also currently in the process of designing high capacity ( 2MiB and 4MiB ) F-RAM cards for my HP48GXs using Cypress Semiconductor "Exelon" Ultra Low Power 8Mbit SPI F-RAM chips because they have a 1000 trillion ( one quadrillion ) write endurance. I've had to start designing a serial SPI to parallel SRAM interface ( using an ultra low power PIC12 -- will switch to a Xilinx CPLD or a Microsemi FPGA if the PIC12 MCU solution doesn't work out ) but the timings are tight and I'm not sure if the required clock cycle stretching I need to do will upset the F-RAM chips.
Regards,
Jonathan
RE: How to test memory in an HP48 RAM card - mfleming - 01-21-2021 12:29 AM
Now that's a project I'd like to hear more about. I'd especially be interested in the serial <-> parallel bridge approach you use.
RE: How to test memory in an HP48 RAM card - wan - 01-21-2021 09:54 AM
(01-20-2021 10:14 PM)Jonathan Busby Wrote: Back in 2015 I bought two 128KiB SRAM cards and two 2MiB SRAM cards for two of my three HP48GXs. I got them from Oleg Rodionov who had designed several sizes of SRAM and F-RAM cards and was selling them on eBay. All the cards worked fine until late last year when the 128KiB RAM card that was merged with IRAM in my Indonesian made HP48GX "crapped out" and gave me a TTRM ( Suffice it to say that I was upset because I had a substantial amount of data, mainly source code, saved on that calc and I don't know where my most recent backup is -- I've moved to Colorado and the backup would probably be in an external HDD in storage but it might be weeks before all my possessions are shipped up here ).
For a card with a capacity of 2M, there are 16 ports, and backing up so much data is a hassle.
HP's connection kit can only access the data in HOME, not the ports, which makes the backup and recovery of the whole card tedious. Is there any way to easily backup and restore the entire ram card with all ports?
RE: How to test memory in an HP48 RAM card - Jonathan Busby - 01-24-2021 07:04 PM
(01-21-2021 12:29 AM)mfleming Wrote: Now that's a project I'd like to hear more about. I'd especially be interested in the serial <-> parallel bridge approach you use.
Well, the project is still in the design stage. The current problem I'm having is that even the "fast" ultra low power F-RAM chip made by Cypress Semiconductor has an SPI clock of only 40MHz. You might think that that's fast enough, *but* the clock period is 25ns. The reason this is a problem comes from the fact that one must issue one SPI opcode to the F-RAM chip before a read operation can take place. The problem is that each opcode is 8-bits ( one byte ). Furthermore, one also has to drive a three byte address onto the SPI bus. The problem comes from the fact that the HP48GX has about a 250ns setup time before the NCE chip select line is asserted. So, one has to sample the address bus on the HP48 side to detect an address change and the WE ( write enable ) line. When these lines settle, one has to transmit, *serially*, the 8-bit SPI read opcode, the three byte address and then the data before the NCE line is asserted,. This means that, when the HP48GX wants to read one byte, one has to transmit all the aforementioned signals on the SPI bus to the F-RAM device, which means that the minimum time taken by a read on the F-RAM side is : 25ns*8 + 25ns*8*3 + 25ns*8 = 1000ns , which is *WAY* over the maximum setup time for a read on the HP48 side.
Writes to the F-RAM chip have the same problem but it can be gotten around by some clever buffering. As for the reads, I don't think it's a fatal flaw and I am considering several ways to get around the problem, but I make no guarantees.
If the Cypress F-RAM chip had a, say, 192MHz clock instead of just 40MHz, then there'd be no problem. I've been in correspondence with a Cypress Semiconductor engineer, so we might find out if Cypress Semi is planning on releasing faster chips any time soon.
Regards,
Jonathan
RE: How to test memory in an HP48 RAM card - Jonathan Busby - 01-24-2021 10:12 PM
(01-21-2021 09:54 AM)wan Wrote:(01-20-2021 10:14 PM)Jonathan Busby Wrote: Back in 2015 I bought two 128KiB SRAM cards and two 2MiB SRAM cards for two of my three HP48GXs. I got them from Oleg Rodionov who had designed several sizes of SRAM and F-RAM cards and was selling them on eBay. All the cards worked fine until late last year when the 128KiB RAM card that was merged with IRAM in my Indonesian made HP48GX "crapped out" and gave me a TTRM ( Suffice it to say that I was upset because I had a substantial amount of data, mainly source code, saved on that calc and I don't know where my most recent backup is -- I've moved to Colorado and the backup would probably be in an external HDD in storage but it might be weeks before all my possessions are shipped up here ).
For a card with a capacity of 2M, there are 16 ports, and backing up so much data is a hassle.
HP's connection kit can only access the data in HOME, not the ports, which makes the backup and recovery of the whole card tedious. Is there any way to easily backup and restore the entire ram card with all ports?
Well, years ago, I wrote a utility in mostly Saturn ASM for my own use that took a list or range of ports and backed them all up to a Kermit server running on a PC. I also started on another branch of this code which did incremental backups but I never finished it ( A common fate with a lot of my projects ). IIRC, the program that just did full backups of ports via Kermit wasn't very hard to code. I say this because the calculator on which I wrote said program TTRMed not too long ago, so I may have to re-code the program. I doubt that the source is completely lost as I'm pretty sure I made backups to my Linux box, but, currently I'm nearing the end of my house remodel as I've moved from Texas to Colorado and the external HDD on which the backup(s) might be stored is in storage right now and it's going to be a while before I have access to all my belongings.
Regards,
Jonathan
RE: How to test memory in an HP48 RAM card - mfleming - 01-25-2021 12:15 AM
(01-24-2021 07:04 PM)Jonathan Busby Wrote: If the Cypress F-RAM chip had a, say, 192MHz clock instead of just 40MHz, then there'd be no problem. I've been in correspondence with a Cypress Semiconductor engineer, so we might find out if Cypress Semi is planning on releasing faster chips any time soon.
I've looked at a number of persistent memories and the fastest clock I can remember seeing was 66 MHz. See what's available in quad-SPI memory. With a higher clock rate that might get you in range, though I know of no low end microcontroller with hardware QSPI support.
RE: How to test memory in an HP48 RAM card - Jonathan Busby - 01-25-2021 06:26 PM
(01-25-2021 12:15 AM)mfleming Wrote:(01-24-2021 07:04 PM)Jonathan Busby Wrote: If the Cypress F-RAM chip had a, say, 192MHz clock instead of just 40MHz, then there'd be no problem. I've been in correspondence with a Cypress Semiconductor engineer, so we might find out if Cypress Semi is planning on releasing faster chips any time soon.
I've looked at a number of persistent memories and the fastest clock I can remember seeing was 66 MHz. See what's available in quad-SPI memory. With a higher clock rate that might get you in range, though I know of no low end microcontroller with hardware QSPI support.
Well, the reason I want to stick with Cypress Semiconductor F-RAM is that, AFAIK, they make F-RAM chips with the highest read / write endurance in the industry, which is 1000 trillion or one quadrillion read / write cycles. This makes it ideal for use as normal RAM on the HP48GX and HP48SX as it would be something like 100+ years before the F-RAM wore out, and, that would have to be a contrived case as one would have to continuously write or read the same memory block continuously.
Thanks for the tip regarding the higher clocked F-RAMs
Do you remember which manufacturer makes them? Also, thanks for the tip on QSPI. That *may* solve the problem but I'd probably have to use an ultra low power Xilinx CPLD, Microsemi or Lattice FPGA for the serial-parallel conversion. Also, I really would prefer to stick with Cypress Semi for reasons I've already stated -- maybe there is another manufacturer who makes F-RAM chips with the same or better endurance compared to the Cypress Semi ones.Regards,
Jonathan