The following describes problems commonly found when trying to access flash chips in systems that are not designed properly for this job, e.g. ad-hoc setups to flash in-situ (see there for ISP-specific problems as well).
Symptoms indicating you may have at least one of these are for example inconsistent reads or probing results. This happens basically because the analog electrical waveforms representing the digital information get too distorted to by interpreted correctly all the time. Depending on the cause different steps can be tried...
- The easiest thing to try is lowering the (SPI) clock frequency if your programmer supports it. That way the waveforms have more time to settle before being sampled by the receiver which might be enough. Depending on the design of the driver and receiver as well as the actual communication path this might not change anything as well.
- Wires are too long. Shortening them to a few cm (i.e. < 20, the lesser the better) might help.
- The impedances of the wires/traces do not match the impedances of the input pins (of either the circuit/chip on the mainboard or the external programmer). Try using shorter wires, adding small (<100 Ohm) series resistors or parallel capacitors (<20pF) as near as possible to the input pins (this includes also the MISO line which ends near the programmer) and/or ask someone who has experience with high frequency electronics.
- The supply voltage of the flash chip is not stable enough. Try adding a 0.1 µF - 1 µF (ceramic) capacitor between the flash chip's VCC and GND pins as near as possible to the chip.
Retrying in case of bad connection
When using flashrom -r, make sure to read the data more than once. Compare the resulting files with "cmp" or checksum utilities (like sha512sum) to see if they changed.
When using flashrom -w, having a bad connection to the flash chip can result in the data not being written correctly to it:
Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x000001b8! Expected=0xff, Found=0x7f, failed byte count from 0x00000000-0x001fffff: 0x10ec7 Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail email@example.com, thanks!
However, flashrom works that way: it first reads the flash, then it will only write the zones that need to be changed. So sometimes retrying several times may work. To see if this strategy is successful, you can use vbindiff to diff the data you want to write, and what you read from the flash chip.
Since flashrom first reads the flash, then only writes the zones that needs to be changed, in case of too much errors, or to reflash faster, you could try to have as few differences as possible with what is already on the flash chip.