Testing MK4096-16

9 posts / 0 new
Last post
Offline
Last seen: 1 week 3 days ago
Joined: May 30 2019 - 00:29
Posts: 49
Testing MK4096-16

Hi!

 

I recently bought a few MK4096-16 chips and wanted to test these. I could not (easily) find anything out there that did this, so for that reason I put together a Nucleo STM32F401 board, a ZIF socket and some batteries (with some adjustment diodes to get correct voltages).

 

The unit isn't completely working yet, timing is off here and there, but I hope to get it up and running (soon?). Anyway, I noticed that some of the MK4096 seems to have a few of their address lines stuck at LOW. That is, the STM32 can't drive them to 3.3 Volt (the 4096-16 should switch at 3.0 Volt). Only some of the chips have this, the rest seems fine. 

 

Is this a particular normal way for a MK4096 to fail? Has anyone analyzed what failures that they usually experience? I am going to test for a number of things, adjacent flipped bits being one. Hopefully I can get 8 working ICs out of the 18 I bought...

 

Offline
Last seen: 3 weeks 2 days ago
Joined: Jun 5 2008 - 07:26
Posts: 475
In my mind, the most common

In my mind, the most common fault for those early generation DRAMs, is the inability to maintain data over time.  In other words, write a bit and read it back immediately and it's OK, but read it a couple of minutes later and it's changed.  If you had an Apple II with an early circuit board with those jumper blocks, you could set up a block for 4096 DRAMs and use that to test those DRAMs.

 

regards,

Mike Willegal

Offline
Last seen: 1 week 6 days ago
Joined: Oct 9 2011 - 12:54
Posts: 1352
Mike,

Mike,

 

  I wonder if that is a thermal issue with the early chips where the timing needs to be tighter to spec when the DRAMs warm up.  I have never experienced it on an Apple II with 4K blocks and the Apple II has better timing for DRAM refresh than the Apple-1.

Offline
Last seen: 1 week 3 days ago
Joined: May 30 2019 - 00:29
Posts: 49
 

 

Well, at last I got the bugs out of it.. and was able to do some simple testing of the MK4096:

 

Some arduino code and random address bit write/read test result  after 10 million cycles (which took around 10 seconds).

 

A Nucleo-64 board (running at 84MHz) with some stash and a ZIF socket (the one I had around). Batteries (+diode) to get -12V and -4.75V.

 

It writes and reads with a 600ns cycle time, about 100 reads after each write. 100000 random locations (which is going to be the full chip).

Next thing will be to look for flip-bits.

 

Offline
Last seen: 1 week 3 days ago
Joined: May 30 2019 - 00:29
Posts: 49
I also got the flipped bit

I also got the flipped bit test going:

 

It writes "0" to an random address (column and row), then it writes "0" to column+1, column -1, row+1 and row-1.

Then it writes "1" to the random address above and checks all the locations for correct content (or flipped bits).

 

The test does this 1000000 times in around 35 seconds and I have not found a single chip that failed it. The above posted fail rate was due to a bug in the setup and not related to the chips.

 

This makes me wonder if the MK4096 is such prone to failure as stated by others. Since I do not know anything about the history of these chips, its hard to generalise based on these tests.

Offline
Last seen: 3 weeks 2 days ago
Joined: Jun 5 2008 - 07:26
Posts: 475
Memory testing is an

Memory testing is an interesting exercise .

 

You test addressing by running what is called an address in address test.  This is basically loading a different value into each location -  with a single bit memory chip,  you can write all ones or zeros to the entire chip and then flip a single bit and read all of memory to make sure no other locations changes.  Then repeat for each memory location.

 

You also need to check persistance of memory by writing all of memory with a pattern before reading back and verifying all of memory.   Writing a location followed imediately by reading it back may miss several types of errors, including the aforementioned address problems.

 

If you encounter an error, report what you read, do not go back and read memory again when you report the error, you may get a different result.

 

The 6502 memory test on my web site has test cases for the most common types of memory errors.

 

http://www.willegal.net/appleii/6502mem.htm

 

regards,

Mike Willegal

 

 

Offline
Last seen: 1 week 3 days ago
Joined: May 30 2019 - 00:29
Posts: 49
The reason I test memory

The reason I test memory location +1 and -1 on both row and column is that each cell is organized in a 2D pattern with row and column being their respective index in each dimension into the DRAM 2D array. If an error occurs due to a bit being flipped, this could to be caused by one of the cells next to it leaking its charge (into it).  The test repeats the writing of "1" into the same cell about 100 times with subsequential checking of the cells with +/-1 on row and column (just after each write), thus it should also pick up slower charge leaks that take some time to build up (and flip the bit).

 

On the other hand, leakage from a memory cell can result in that cell loosing its state (it discharges too fast). This is probably not something I catch with the current tester design. In fact, if the DRAM refresh time is small enough, it may not show up as an error at all, but if the refresh time is long enough it will result in poor DRAM cells loosing their state first.

 

All-in-all it would be interesting to see if the DRAM refresh rate could be changed on the Apple-1. Reducing the time between cell refreshes could potentially enable less than optimal DRAM chips to work.

 

What do you think?

 

Offline
Last seen: 2 years 9 months ago
Joined: Sep 20 2019 - 10:37
Posts: 18
Would tou be willing to post

Would tou be willing to post your test code?  I would like to build an arduino based tester.  I would be helpful to have a starting point.

Offline
Last seen: 1 week 3 days ago
Joined: May 30 2019 - 00:29
Posts: 49
The Arduino boards are not

The Arduino boards are not fast enough to get the required timing resolution and the source code would not be able to run on them either. You need a STM32 based solution at (or above) about 84MHz for my code to work.

Log in or register to post comments