Strange behaviour trying to include NV RAM controller in breadboard computer

[8BPogle]

Hi All

I’ve got a problem which has got me really stumped.
I have been trying to battery protect an 128K RAM chip on my breadboard computer to effectively turn it into NV RAM. From my research, this should be very, very straightforward.
My breadboard computer runs just fine for hours, so appears to be pretty stable.

Having done a bit of research, I came across nonvolatile controller ICs and these looked to be just what I needed. Indeed, such ICs are used in the production of commercial NV RAMs.

I have written a basic monitor for my system, which includes a ‘lite’ xmodem based upload function, so I can populate chuncks of RAM with a nice big blocks of text. I'm only using the lower 57K of the ram chip in the system, so A16 is tied directly to ground.

I wired up a DS1210 NV controller and battery to my system, fired everything up loaded some text and powered off. After a few cycles, of this it was apparent that RAM contents do indeed persist – but usually only for a few tens of minutes.
After about 10-20mins (usually - This period can vary - sometimes RAM contents persist up to an hour) though, when I power up & check RAM, contents are ALL set to 0x00.
That's the entire 57K, except for memory used by my monitor program, set to 0x00!

If I disconnect the battery and operate the system, RAM contents are random on power up, just as one would expect. So I'm pretty sure I don't have some 'rogue set all RAM to 0x00' routine accidentally running at startup!


I have tried various configurations of the DS1210, changing the tolerance pin from VCCO to G to change the trigger voltage. I have tied the /chip enable in (/CEI) low and not connected /chip enable out(/CEO), so I only use the battery protect function and no RAM write control.
I have connected CEO to the AS6C1008 /CE, and also tried an inverted select signal to connect it to the CE2. I have used a different battery.
Whatever I do, I seem to get the same result.
So, I wondered if I have a duff DS1210 chip (bought from eBay from a UK seller).
So I ordered a Maxim DS1321 NV controller to test this hypothesis, wired it all up, and I have exactly the same behaviour.
I have even swapped out the original AS6C1008 RAM chip for an Hitachi HM628128LP - same behaviour.

The NV controller is obviously doing SOMETHING, as I’m getting zeroised  RAM contents (i.e. 0x00) on power up instead of random contents.

With my MM ground lead at the RAM ground pin, when the system is powered up, the RAM VCC is at 4.7V. When I turn the system off, the RAM VCC is at 3V, as expected from the battery & DS1321. The DS1321 /CEO is at 3V, the battery warning is at 3.8V and the battery anode is at 3.3V. All as expected.
I leave it for 15 min, and contents are all 0x00, but voltages all seem OK still


I have built a few 8 bit breadboard computers in the past but I’m doing it to learn about electronics in my retirement. I'm therefore pretty much an electronics novice and I'm probably doing something stupid somewhere. Quite possibly something obvious to those more educated in electronics than I!
This system is all breadboarded. 5v is supplied from an old SONOS bridge mains adapter which I have used in the past. I have tried an alternative 5v adaptor and had the same results.

Given there is a time aspect here (and that time can vary), I'm wondering if it could be some kind of capacitance issue - something charging/discharging and causing an issue.  a while after the system has shut down? But I can't even construct any form of hypothesis regarding WHAT sort of spike/wobbly/fault could cause the RAM contents to get so neatly set to 0x00???

I had to prove I had understood the DS1210 / DS 1321 datasheets properly, even though there are only 8 pins on the DS1210, so I wired up an Arduino Mega to the AS6C1008 RAM, connected up a DS1210 and wrote a short sketch to display RAM contents, and allow me to set RAM contents.
On this testbed, the AS6C1008 RAM has retained contents for 20 hours now, so it looks like that its working.
So that's a RAM chip AND NV controller from the original system, on a breadboard with an Arduino, and it all works as expected.

I’ve been struggling with this for over a fortnight, and I'm starting to get a bit frustrated, so any suggestions and/or pointers would be very welcome indeed!

Many thanks

[m k]

My guess is that one of your control signals is floating, has an incorrect level and you can't access the RAM.

[8BPogle]

I finally found out what was causing the problem. It took quite a while - I thought the issue may have been time related, so was testing RAM contents after overnight waits etc. I also wondered if I had some kind of wiring problem, so rebuilt the entire system with a different, neater breadboard layout. It’s been a hugely frustrating experience, but – having asked about it on this forum - I thought I would share my experience in case it ever helps anyone else.

Firstly, I created a ‘minimal’ program with a lot of inline code rather than subroutine calls which just initialised the ACIA and then offered the option to read or write memory to a series of predefined locations. Having written memory, subsequent reads after power down/up were always showing expected contents (no NULLs), irrespective of elapsed time or number of power ups/downs.

Consequently, I became more convinced it was something to do with my code rather than being somehow hardware related.  I amended my initialisation routine so that it hex dumped some specific areas of memory on power up.  This meant only my initialisation code would run before I could check memory – no command line interaction or other code was being executed before the memory dumps.
Capturing and studying these dumps, I eventually identified that the NULLs always started from a bit of memory I had allocated as a 30-character input buffer for characters input via the 6850 ACIA. As a test, I relocated this buffer in my memory definition and, and – sure enough - the NULLs subsequently began at wherever the new input buffer memory location started. Very significant, I thought.
My minimal program didn’t use an input buffer – it just checked any character captured for ‘r’ for read or ‘w’ for write and discarded anything else, so I now knew it was something to do with the command line processing.

But, I still had the issue that something very random appeared to be triggering when the NULLs turned up, and also how much memory they actually filled. It was always a lot of memory, but could also sometimes be almost all the available RAM.

A serendipitous appearance of NULL’s directly after I noticed I had connected my USB-FTDI cable while the system was powered up, led to a further bit of investigation. I subsequently confirmed that the NULLs appeared if I connected or disconnected the UBS-FTDI cable while my breadboard system was powered up. i.e they did NOT actually appear on system power up or down after all

So, now I had a pretty good hypothesis. – It looked like ‘noise’ manifesting as a stream of NULLs was being generated whilst dis/connecting the USB-serial cable if the system happened to be powered up.

I didn’t have any bound checking on my ACIA fill routine, and so what was happening was the buffer was being overrun with thousands of NULLs which would fill up an undefined amount of memory. This is a Z80 build and I was using a 16 bit register for the input buffer index. If the buffer was in high in memory, it would ‘roll over’ ROM in low memory (with no effect) then and start trashing lower memory. If the buffer was in low memory, NULLs would fill up to varying upper limits. With a 16 bit index, it could loop the whole 64K if enough NULLs were generated.

So, a combination of no boundary checking on the ACIA input buffer AND the unexpected generation of huge volumes of NULLs when dis/connecting the USB FTDI cable if the system happened to powered up first, was the source of my apparent random filling of memory with NULLs. If this happened BEFORE I finally powered down, then the NULLed memory was being preserved by the DS1210 NV controller. If I happened to connect while the system was powered up, then whatever was preserved in RAM before power-up was being overwritten by NULLs.

If I hadn’t been checking RAM contents to check my NV controller was working, I wouldn’t have ever noticed any of this, as it made no difference to ‘normal’ operation 
So there we are!