How to dump flash memory with SPI?

Question

Often flash memory is connected via SPI (Serial Peripheral Interface Bus) to a processing unit like an ARM core or a micro controller.

• How can one dump the memory?
• Can there be protection mechanisms?
• Are there pitfalls to avoid?

Answer 1

Although I think the questions are too broad and I agree with @cb88 that the datasheet should give you all you need to know, I'll try to answer some.

How to dump the memory

1. Desoldering

   First option is desoldering the chip from the board. After having done so you have 2 options

   • Read the chip out using a chip programmer like e.g. Dataman that supports your chip ($$$ expensive solution).
   • Or use a cheap micro controller based solution like a Bus Pirate, an Ardunio or code your own dumper (which is generally not too hard).

2. In Circuit

   When you can't or don't want to remove the chip you have again 2 options.

   • First one is again using a professional programmer or the cheap micro controller based ones mentioned above. There are definitely some pitfalls with this method which I'll describe when answering your 3rd question
   • Alternatively you can monitor the SPI lines and use a Logic Analyzer or micro controller to decode the signals. The downside is that you don't control the addresses that are being read and so you have to somehow generate activity to the SPI Flash and then reconstruct the flash image based on the addresses that are being accessed.

You can also use a clip that is designed to attach the analyzer to the chip in-system.

In general I'd really recommend to desolder the chip. They're almost, if not always edge packaged (e.g. having clearly visible pins on the outside of the package) and not Ball Grid Array (BGA) packages. This makes them easy to remove and also easy to put back. It will save you the headaches you might encounter that I described in the pitfalls section below.

Protection mechanisms

• OTP memory Some of these chips can include One-Time Programmable (OTP) memory in which they store protection bits. I've only seen this being used for locking down area's against writing, not against reading. Otherwise what's the point of having the flash memory?

• Encryption I have never seen nor could I quickly find any SPI flash chips that offer encryption. This is usually implemented in a memory controller on the System on a Chip (SoC) side that does it on the fly keeping it nice and transparent for the host CPU.

Pitfalls to avoid

Some things to keep in mind;

• I have nearly no good experiences while trying to dump the memory while keeping the device in-circuit. There are allot of reasons why this could go wrong.
  1. The host processors keeps the SPI Flash busy while running it's own program
  2. A watch-dog on the host side resets the board because it's peripheral became inaccessible for too long due to you accessing it
  3. When you choose to provide the power to the chip yourself, then your programmer/reader might not be able to supply enough current if there's multiple components on the same power rail

• In case you're writing your own sniffer make sure it can sample the signals fast enough. For example the bus pirate will fail in all cases because it can only sample at max ~32MHz where allot of SPI Flashes start at 40+MHz. So you'll need at least double the target speed (Sampling Theorem)

  The flash devices can work at various speeds up to 100+MHz which relate to the various modes (normal read, fast read, dual read, quad read etc) they're in. Such a mode does not only change the speed, but also the way data is transferred. For example in Quad Read mode the flash clocks out 4 bits bits at a time using the SI/SO/WP/Hold signals instead of 'classic' mode where you read out 1 bit per clock cycle from SO (Serial Out).

• When acting as the host just make sure you provide enough power and that the signals are high/low at the right times. All this information can be found in the datasheet of the flash chips.