Moving the Setup

After preparing the chip for connection to the Arduino, I realized that the VR table I had was missing the cables to connect the pins to the base of the table. To resolve this and to hopefully prevent further issues from a lack of equipment, I tore down the setup and moved it to the Leahy Center. Then, I re-set up the chip on the VR table, now with the cords, as seen below.

The VR pins were attached in a counterclockwise manner, starting with the top left (L5). The below version of the chip diagram is reversed to match the face-up chip (as per the previous progress report) and the utilized pins on the chip are highlighted.

The pins on the chip correspond to the ports on the VR table as follows:

Address Pin (A2): L5

Chip Enable (CE): L4

Input/Output Pin (I/O0): L3

Write Enable(WE): L2

Output Enable (OE): R5

Byte Low Enable (BLE): R4

Ground (Vss): R3

Voltage (Vcc): connected directly to the 1.8V port on the VR table.

In order to test that none of the pins connected to the VR table arms were touching, I used an AstroAI AM33D multimeter to test for crossover. Two cords were connected to the multimeter, each with pins on the end. Then, I held those pins to two of the plugs at the end of the cords connected to the pins on the VR table (the black and red cords seen in the earlier image). If the pins on the VR table connected to those cords were touching, the multimeter would make a sound. I repeated this process for each pair of pins that were closely situated on the chip, and none were touching.

The next step was to connect the VR table to a breadboard, then connect the breadboard to an Arduino Mega 2560 microcontroller, as well as a Saleae logic analyzer. The cord for the VR pin attached to Voltage (Vcc) was plugged directly into the VR table's 1.8V port, and the VR table was connected to power. Then, the pins at the bottom of the VR table that corresponded to the utilized ports (ex. L5) were connected to separate horizontal lines on the breadboard. A breadboard's horizontal lines on either side of the vertical line separating its two sides run the same connection, so it can be used to string multiple connections together. Therefore, additional slots in the horizontal lines were used to connect the VR table lines to the Arduino's digital ports. Ground was connected to the GND port, Write Enable was connected to port 43, Input/Output was connected to port 45, Chip Enable was connected to port 47, the Address pin was connected to port 49, and Byte Low Enable was connected to port 53. Connections were then run from the lines on the breadboard connected to Ground and Write Enable to the Logic Analyzer, which was connected to a laptop running the Saleae Logic 2 application. The screenshot below shows the full setup.

The logic analyzer allowed easy troubleshooting of the Arduino program written for this chip, since it displays the movement of data in its raw form. For Write Enable, Chip Enable, and Byte Low Enable, a modified version of the program found here was run to ensure that the pins were actually being set from HIGH to LOW as directed in the program. The modified version of the program simply commented out the for loop calling the send_address function and the declaration of the send_address function, since that function didn't involve any of the pins currently being tested. The results in the Logic 2 application were as seen below: a steady switching from high to low.

This confirmed that all three pins were functioning as intended with the program. Next, the address pin was connected to the logic analyzer to test the flow of data through the address pin. The send_address function was uncommented and it was called in the loop function, but without the for loop to run through multiple addresses.

First, the address 0x01 was tested, and the results were as seen below:

Then, the data flow of the Input/Output pin was tested with the same program running:

Next, the memory address was changed to 0x32 and the data flow of the Input/Output pin was tested again. This verified that the data coming from the Input/Output pin was changing based on the memory address, which is a good sign:

Finally, the full program was tested and the data flow of the Input/Output pin was recorded for ten seconds and saved to a .bin file:

That file was opened in 010 Editor to get a quick view of the contents (obviously, none of it is readable, but it is data).

Next Steps

The final step of this project is to gather all of the data on the chip and format it so it is usable.