VOGONS


First post, by kinetix

User metadata
Rank Member
Rank
Member

Here's the code I expanded to test 4164 and 41246 memory chips, based on the DRAMarduino project: https://forum.defence-force.org/viewtopic.php?t=1699
It has been expanded with the help of Copilot and tested with an Arduino Uno R4 Wifi, but it should work with others, taking the pins into account. See the electronics side of the project.
I focused on this project because it's very simple, inexpensive, and just what I needed for the memory chips I wanted to test. I tested MB8264, MN4164, MB81256, MN41256 and D41256 chips.

The tests included are:
• Fill: Fills cells with zeros, ones, or a specific pattern. This is more or less the original test, but chips with some problem may pass this test but fail one or all of the following. This is why the original project is quite limited, unless the tests are expanded.
• Checkerboard: Alternating zeros and ones.
• Retention: Writes to memory and reads the data after a timeout.
• Inversion: Checks for bits that change their value after being written.
• WalkingBits: Checks for stuck cells.
• MATS++, MarchC, MarchA: These three tests expand the scope to include:
- Stuck-at errors (cell always at 0 or 1)
- Coupling faults
- Transition faults (cell does not transition correctly from 0 to 1)
- Addressing faults
- Interference faults between neighboring cells
- Conditional access faults (reading or writing fails depending on the state of other cells)
• Address Aliasing: Check if different row and column combinations accidentally access the same memory cell, indicating a fault in the address logic. However, this test still needs further work (made faster) and is disabled.

The code requires the digitalWriteFast library. Install it into the IDE.
After turning on the Arduino, or changing the chips, press the Reset key once to avoid possible errors.
Sometimes, a single error in $0 may immediately appear at the start of the first test. Reset until the tests start correctly, unless it's a real error.
The code allows you to run a given sequence of tests (you need to modify and recompile the code) or use a menu via the terminal (tested in the Arduino IDE) at 9600. The terminal displays the running tests and their results. It is recommended to use the terminal console.
During the tests, the green LED keep flashing. At the end of a partial or full test, both flash. After all the tests, if everything is OK, the green LED remains lit; if there is at least one error, the red LED remains lit.
If during the tests there are more than 100 errors, the remaining tests are canceled.
There are unused or commented-out parts of the code; this is a WiP.
You can do whatever you want with the code, modify it, adapt it to your needs, etc. If anyone tries it, please share your thoughts. I'm sure Copilot or I made mistakes or added unnecessary things.

Last edited by kinetix on 2025-07-13, 14:31. Edited 5 times in total.

Reply 1 of 5, by weedeewee

User metadata
Rank l33t
Rank
l33t

The one thing I'm always missing in these is an actual speed test.
Where the device is tested to operate properly at its rated speed, and can be tested at lower & higher speeds.

I wonder if it's even possible with just an arduino.

Right to repair is fundamental. You own it, you're allowed to fix it.
How To Ask Questions The Smart Way
Do not ask Why !
https://www.vogonswiki.com/index.php/Serial_port

Reply 2 of 5, by kinetix

User metadata
Rank Member
Rank
Member
weedeewee wrote on Yesterday, 06:48:

The one thing I'm always missing in these is an actual speed test.
Where the device is tested to operate properly at its rated speed, and can be tested at lower & higher speeds.

I wonder if it's even possible with just an arduino.

I think so, by controlling access and signals with waiting times. Rigth now the only delay is 1 microsecond and that can be too high,.
Tests can also be conducted to determine operating limits. The topic can be studied. I will try some modification and do some tests.

Last edited by kinetix on 2025-07-13, 03:16. Edited 3 times in total.

Reply 3 of 5, by weedeewee

User metadata
Rank l33t
Rank
l33t

I have no idea how slow the slowest dram can be, though the ones I do know of have a specification of 180ns.
So 1 microsecond is already 5 times too slow to properly test the device.

Right to repair is fundamental. You own it, you're allowed to fix it.
How To Ask Questions The Smart Way
Do not ask Why !
https://www.vogonswiki.com/index.php/Serial_port

Reply 4 of 5, by kinetix

User metadata
Rank Member
Rank
Member
weedeewee wrote on Yesterday, 21:22:

I have no idea how slow the slowest dram can be, though the ones I do know of have a specification of 180ns.
So 1 microsecond is already 5 times too slow to properly test the device.

that can be done. Some one did it using NOPs, like this:
__asm__("nop\n\t"); //62.5ns
__asm__("nop\n\t"); //62.5ns
__asm__("nop\n\t"); //62.5ns
As most of the Arduinos runs at 16MHz and NOP take 1 cycle. You can read the F_CPU constant or other method to know the speed in Hz and create a dynamic delay. So you can have ~62 (too fast for 100ns chips?), ~120 and ~180 ns.

I will replace the delays, and maybe add a speed selector to the menu. I have 100, 120 and 150 ns chips for testing.

UPDATE:
I did a test with the NOPs and it worked, BUT... I removed the delay... and it worked too!
The problem is the inherent delay of digitalWrite/digitalRead. Even the Fast version, which is dozens of times faster, the delay can be on the order of 250ns on a 16MHz Arduino Nano, I read (but as low as 20ns in other non-Arduino dev boards, I read too). I'm using an Arduino Uno R4 WiFi (48 MHz) and I'm not sure if the library is using the faster operation and not falling back to the standard operation, nor that the pin toggle time is lower because it has a higher clock speed.

UPDATE: I just read the Uno R4 WiFi pin toggle time with FastWrite/Read is around ~180ns, and with some register tricks, can be lowered to ~80ns. So, that is my testing limit.

Anyway, I'll do a toggling cycle on a pin and measure with the scope.

So far I've tested 30 chips; 3 were completely dead, and four failed only in the most stringent tests. Some addresses that failed one test failed every test, and in other tests that measured cell relationships, some additional ones appeared. So the code doesn't work that badly as it is.

Last edited by kinetix on 2025-07-13, 14:14. Edited 3 times in total.

Reply 5 of 5, by weedeewee

User metadata
Rank l33t
Rank
l33t

Thank you for the effort.

To be sure, checking with an oscilloscope would be best to measure the timings of the signals.

Right to repair is fundamental. You own it, you're allowed to fix it.
How To Ask Questions The Smart Way
Do not ask Why !
https://www.vogonswiki.com/index.php/Serial_port