Still have that old development kit kicking around from college or high school? Yeah, me too. Don’t have a programmer on hand? Yeah, me too. I had the dire need to dump some parallel NOR flash memory recently and could not find a good tutorial on how to do it cheaply and consistently with free software. So I created my own tutorial, and I invite you to follow along.
Earlier this year, I needed to read out some parallel NOR flash memory. I did not have a programmer (a device that can read flash memory through preprogrammed means via software created by the manufacturer) and did not want to buy one due to cost and shipping time. I found some software—UrJTAG (works well with Linux) and TopJTAG (works well with Windows)—and hooked my JTAG-compatible board to a parallel NOR flash chip. I wound up putting voltage on one of the incorrect pins and it cut its way through the parallel NOR chip to ground. Consequently, the memory was gone forever and I was more interested than ever in getting this working. After some tweaking and learning to use the tools, I found this method to be a very cheap and easy way to read out parallel NOR flash on both Linux and Windows with some basic hardware.
If you are interested in putting this project together yourself here are links to the parts used. These links should bring you to an appropriate component which will work, but probably won’t be the cheapest. Doing your own searches for these parts and components on other applications or online stores may drastically decrease the price of this project.
Parallel NOR flash is a storage medium for electronics. It is used for its accessing abilities in that it can grab single bytes or words randomly rather than pages of memory, which NAND flash cannot. There are other advantages, such as standby power consumption and storage lifespan, that make it a better component to use with systems that do not need to store a lot of information but need accurate data all the time. Parallel NOR flash is employed in an array of embedded devices and IoT systems that are used throughout industry and in home appliances. DVD players, thermostats, Amazon products, and vehicle electronic control units (ECUs) typically contain flash memory.
Parallel NOR flash comes in an array of different integrated circuit (IC) packages. The ones referenced in this article will be thin small outline package (TSOP) components. Some come in ball grid array (BGA) packages and other packages and sizes. In most cases, a simple Google search confirms what your part is and leads you to some sort of datasheet for the component. Here are some parallel NOR flash ICs and the device I found them in:
![]() | ![]() |
![]() | ![]() |
A simple Google search of the text on either of these ICs brings up relevant datasheets and explains it is parallel NOR flash. Pins are also typically in buses and have an “address in” and “data out” side. Some NAND ICs have similarities so it is best to read and refer to the datasheet about the pinout of the IC and the type.
Taking the router’s flash chip identification markings (for example, EN29LV160AB-70TCP in Figure 2) and putting it in Google (Figure 3) retrieves datasheets to which you could refer to learn more about the part.

Clicking the first datasheet in Figure 3 pulls up relevant information about this flash chip. Looking at Digikey.com also gives a simple overview of the IC (Figure 4).

Examining the datasheet, we find the pinout diagram (Figure 5). A pinout diagram typically shows all the pins that can connect to the IC mapped to their specific function. In this case, 48 pins are on the target IC that are shown in the diagram with their respective function (that is, Vss for ground, WE# for write enable, and so on). With these two pieces of information, you can put the IC in an adapter and pull memory.


As shown in Figure 6, a read requires the chip enable (CE) and output enable (OE) to be low and the write enable (WE) and reset pins to be high. Address requests can then be sent to A0-A19 as bits, and the flash chip serves back the data to the requester on pins D0-D15.
It is important to examine and test your equipment thoroughly before extracting flash memory. If pins are not connected correctly and power is misconfigured, you can lose data and damage or destroy the flash chip. Following these steps can mitigate damage and data loss before attempting to extract data using JTAG.
To test your JTAG-able board (we will refer to it as board from now on), retrieve the BSDL for the board by searching for it on https://bsdl.info/. A BSDL file is the Boundary Scan Description Language file that pertains to your specific make/model and allows you to control some of the registers that in turn give access to reading and writing to I/O pins. The BSDL file is written in a format similar to VHDL (VHSIC Hardware Description Language) to describe a low-level circuit. JTAG compatible components can also use BSDL files to perform boundary scans on the board’s blocks internally to analyze the logic and find/use external busses (like flash memory or another component). If your equipment works and you are in a Linux environment, scroll down to this post’s UrJTAG section. Programs such as TopJTAG Probe can assist in ensuring a board is operating correctly and that a board can send and receive data on I/O pins. After opening the GUI, an empty project should appear (Figure 7).

Go to File > New Project Wizard. A dialogue box displays the new project wizard (Figure 8). Choose your interface in the Device field. In this case I am using a USBBlaster. It is a cheap and compatible USB adapter for Altera products from Intel.

Click Next. If your board is hooked to your connection device, it will enumerate as shown in Figure 9.

Click Next. Click CLICK HERE TO SET. Browse and select your BSDL file downloaded for your board (Figure 10). Then click Finish.

A new project now displays (Figure 11). Short one of the I/O pins on your board with a jumper to ground and select Run on the top taskbar. Lift the jumper to see if any of the pins change color from black to red. With the exception of the oscillator (changes black to red repeatedly without any interaction), if one changes, your board is probably good and the BSDL file will work. If not, you may need a different BSDL file or different board.




Removing the flash chip may require some skill and finesse. Using a heat gun, slowly heat the area that is soldered down. Slowly moving the heat gun in circular motions or side to side in patterns is effective in heating the solder and will minimize melting the IC. Using a pair of tweezers, lightly pull the IC off or “shuffle” it off its pads to get it off. Be careful. Components will be hot.

After removing the flash chip, inspect its package size and shape in comparison to different packages listed on Wikipedia. With some searching, you can find the exact package of the flash IC. Get an adapter based on the package size if you do not have one on hand. In this case, I am using a TSOP 56 adapter for a flash chip that has 48 pins. Due to the dimensions and standardization of TSOP, the flash chip fits and I can use 48 of the 56 pins on the adapter. An adapter with the same package size but different pin count can work if the adapter pin count is higher than the pin count on the flash chip. Flash adapters can be found on most online shopping sites. Mine was from eBay.

Up to this point, this project has been a breeze. Now for the hard part. Take the jumper wires and pin them out to the BSDL file pins for your board. You can see the pins in the BSDL file pin map of the board.

It is important to note in some cases the datasheet and BSDL will not overlap and the pins will be different depending on who generated the BSDL file. Write out what I/O pins you intend to connect to the parallel NOR flash. In this case, I mapped CE to IO193 and connected a jumper wire between the two. I mapped A15 to IO105 and connected a jumper wire between the two. For each pin on the flash chip (with the exception of the power rails) there must be an I/O pin connected. Power pins can connect to whatever pins are available to coincide with the voltage required to power the flash chip. Mine is 3.3V so I powered it with the 3.3V my board provided. Hook up all I/O pins to their respective flash pins. Connect the interface from the computer you are using to the JTAG header on the board. Keep track of everything on a text editor or on a piece of paper. Here is an example of the map I used:


Go to Setup > Signal Pins. Here is where all flash mapped pins must be input to communicate with the flash chip. Match the datasheet.






Until now, this post has demonstrated the tool TopJTAG, which is typically used in a Windows environment. In this section, we demonstrate using the tool UrJTAG in a Linux environment.
Start by installing UrJTAG with sudo apt install urjtag. After installing, plug in your board with the flash chip attached and mapped out. Refer above for mapping and connecting components. After connecting everything, run jtag as root. This drops you into a JTAG REPL. You can issue commands to the board now and are able to interact with the hardware as necessary.

With UrJTAG up and running, you must specify an interface to connect to the board. Without a method of communicating with the board, UrJTAG cannot issue commands. In this case, I am using an Altera USBBlaster. There are many knockoffs out there and they are dirt cheap. Typing help cable lists all available interfaces.


To create a bus in UrJTAG with what is known as the prototype function, some editing must be done to the pins detected from the BSDL file. I/O pins must be named into whatever bus they connect to. Figure 28 below is an example from the UrJTAG documentation.

Looking at Figure 17, you can remap the pins using the salias command so they fit the UrJTAG naming convention to initialize the flash memory. Salias creates a signal alias for the pin and changes the name in the instance of UrJTAG open. The syntax is salias rename currentname. The figure below shows a screenshot of how I mapped my pins.

Then, depending on your datasheet, you can use the set command in UrJTAG to put pins in a high or low state. In this case, looking at Figure 7, I must put my CE and OE low and RESET and WE high. You can try to use the format in UrJTAG to do this, but I found just setting the pins themselves easiest. I referred to Figure 17 to where these pins connected.

After this, you can initialize the bus using the initbus prototype command. Some JTAG devices have the EJTAG ability and can bypass this method. Please refer to Joe Grand’s video about the JTAGulator as he shows how to use the EJTAG functionality. Because the CE, OE, and WE pins were set to desired values, they can be grounded out in the initbus command. The format for this command is initbus prototype asmb=highestaddresspin alsb=lowestaddresspin dmsb=highestdatapin dlsb=lowestdatapin cs=gnd oe=gnd we=gnd amode=youroperationmode.

A bus should now be initialized and the command readmem in UrJTAG can automatically read the memory. It sends the required data across the JTAG lines to instruct the JTAG-compatible device to send addresses to the flash and read the data pins out to the application. The format to readmem is readmem startaddr size outputfile. In this case, I was reading 2097152 total bytes.

After the flash has been read, there should be a prompt that states done. This means the flash memory has been dumped if all steps were followed correctly.
Running some simple commands can give more insight on what may be stored on the device. In this case, the flash was removed from the Linksys router imaged in Figure 2. Unfortunately, the Oppo DVD player in Figure 1 was sacrificed in the making of this blog 🙁 This was due to a mismatch of pins and can be avoided by using schematics and boards with strong, contrasted silkscreens to avoid pin confusion. Examining the dump with a simple cat, hexedit, or xxd and head can display if what was read is legitimate data.

This is a good sign. Failures in reads or misconfigurations result in repeating characters, 0s or FFs depending on the state and failure. Binaries may have magic numbers, repeating hex, empty space (filled with 0xFF), and repeating characters as in the figure above. It is important to understand that consistent patterns of the same hex value may be a failed dump if the entire file is filled with the same data. If the entire read is failed, all data in the dump may look like what is shown in the following figure.

It is possible the flash may have sections that are filled with no data, so it is important to look throughout the flash for non-repeating patterns and strings. To see if parsable files with known formats are in the dump, use binwalk, which looks for file magic (headers) and sizes and can extract them for further analysis. Syntax to extract is binwalk -e filename. The figure below shows an output of files extracted from the dump.

There may be some data hiding in other locations or you may need to extract files using data duplicator (also known as dd). In this case, the data was extracted successfully through JTAG and confirmed using these tools. If you are getting strange results, check the pinout and your connection points as simple movements such as plugging in one pin can cause another pin to disconnect and errors with the read.
With some superglue after a successful read, you can put your adapter permanently on the board and have a crude parallel NOR programmer. This method is a quick, cheap, and dirty way to get data in a pinch or time crunch and teaches engineers and enthusiasts about tools they can use with the JTAG chain. These tools can also be used to communicate with other hardware devices and components directly connected to the I/O pins on a board. I encourage readers to try to communicate with components connected other than flash memory.
If you found this article interesting or have any questions, please email us at hello@zetier.com!