If you are simply looking for a way to program the Winbond SPI flash with 'pre-loaded' data that your microcontroller would read for use when it is running then what you will want to look into is a programmer that can do in-circuit programming of the SPI Flash chip. This also known as in-system-programming (ISP). One choice is the.
SmartRF Flash Programmer 2 can be used to program the flash memory in Texas Instruments ARM based low-power RF wireless MCUs over the debug and serial interfaces. I'm working on an audio application where instead of storing audio data on an SD card (Waveshield on Arduino) I'm storing it on an SPI flash memory IC and rolling my.
This USB connected device can program in circuit if you design your board correctly. They even sell an adapter clip that can attach into the SOW-16 package without having to design in a separate programming header on your board. DediProg has application information bulletins available to help with correct design for in circuit use. The main strategy for the design is to find a simple way to isolate the SPI interface drivers in your MCU system so that they do not interfere with the drivers in the SPI programming pod. The simplest way to do this is to put series resistors in the MCU driven lines between the MCU and the SPI Flash.
The programmer would connect on the SPI flash side of the series resistors. Alternate methods could include adding a MUX or analog switches in the driven interface lines.
An even more clever scheme is to add a 'programming enable' input to the MCU that makes the software disconnect all the SPI I/Os from the SPI Flash chip (i.e. Make all those GPIOs as inputs). A second choice to also consider is. The Presto is able to do various types of SPI and I 2C devices including SPI Flash devices. I have one of these devices specifically for programming Atmel MCUs and various types of SPI Flash devices. It is a more cost effective solution than the above unit but not quite as flexible. Their more expensive device called the Forte is able to do more things because it has more target interface pins.
Sometimes it can be beneficial to be able to connect a programmmer to a target board without having to add a programming header. One nice solution for this is to place a small set of pads in a special footprint defined. They manufacture and sell a series of quick connect programming cables that have pogo pins that engage the special footprint on the board. There are 6-pin, 10-pin and 14-pin versions of the cable available to suit a range of applications.
Cost of the cables are very reasonable. I have never heard of any other tools talking SPI directly to such a chip, and I think it is impossible since 'all' chips require different calls for different operations. The chip needs SPI calls for write, read, change sector, data size etc.
Under 7.2 Instructions chapter in the datasheet you can see all the SPI commands you can send to it. Hence, since all external flash memories does not have the same instruction set, you need to write a customized application for this one. EDIT: Being a follow up, I would really recommend one of Atmels own SPI flash memories, since most of them already has written open available code for them. Looking at from will provide you with code for some of Atmels AT45xxxx serial flash chips.
I purchased a ' programmer from Embedded Computers for about $30 US. It was surprisingly easy to connect to the PC via USB and write files to the Winbond flash memory. The methods and programmers in other answers are probably just as good, some more expensive or DIY, but this is a cheap and simple way that fits what I was seeking. Here's a picture of the setup: The FlashCAT programmer is at left, connected to USB. It's running the SPI programming firmware (as opposed to JTAG) and supplying power to the flash memory. The supplied power is selectable (3.3V or 5V) with a jumper.
I have a SOIC to DIP socket on the breadboard to make it easy to program multiple chips. (You can see another flash memory IC sitting on the breadboard as well.) I haven't yet converted my audio file to the proper binary format, but I wrote a 211KB WAV file to memory just to test, pictured above. I then read it back and saved it as a new file, renamed it to.wav, and it plays correctly on the PC.
The next step will be to properly encode the file, and write the AVR software to read the data and send it through a DAC. Disclaimer: I am not affiliated with Embedded Computers, I'm just a customer who picked something inexpensive and am sharing information about the experience with the product. Contrary to some of the statements here, while there are some quirky SPI PROMs out there, there are also some standard instructions used by a large variety of SPI PROMs, including the one you've chosen. As vicatcu already mentioned, there are good 'bit-bash' cables available that can directly program SPI. Signal-wise, SPI looks a lot like JTAG, so any bit-bash type of cable should be able to be used provide the interface is open source. The internal protocol of the flash is fairly simple. We use the big brother of the part you're looking at to boot our FPGA boards (256M - 2G).
The addressing has an extra byte to handle the storage volume, but otherwise the commands are basically identical. The type of PROM you're using has to be erased by sector, then programmed by page. Reading is significantly faster than writing (in the case of the ones we use, programming can take half an hour, but reading the whole PROM takes under a second at 108MHz). Now for the commands: There are way more commands available in these devices than are actually required to program them.
You actually only need the following:. RDID (read ID) - just to verify the PROM and signalling before you do anything more complex.
WREN (write enable) - needed before every write. PP (0x02 - page program) - needed to program a page. SE (0x20 - sector erase) - returns bits in sector to '1'. RDSR (0x05 - read status register) - needed to monitor erase / write cycle. FREAD (0x0B - fast read) - read PROM data and verify write.
If you want more information look at answer notes on SPI programming for Xilinx FPGAs on their website (They implement a reduced subset of commands so their FPGAs can boot from these devices. I designed my own programmer to do this based on what I have available and wrote a programmer script in Python, but you can do the same using a cable. In your case, I would seriously consider doing everything indirectly through the MCU as Michael Karas suggests.
You don't need to program the whole PROM from the MCU in one go - you can do it by sector. Kind of late to the discussion, but for anyone reading it after a search. One thing I did not see mentioned, which is absolutely critical when programming SPI Flash chips is control of the Chip Select (CS) pin. The Chip Select pin is used to punctuate commands to the SPI Flash. In particular, a transition from CS high to CS low must immediately precede the issuance of any Write operation op code (WREN, BE, SE, PP). If there is activity between the CS transition (i.e. After CS has gone low) and before the write op code is transmitted, the write op code will usually be ignored.
Also, what's not commonly explained in SPI Flash datasheets, because it's an inherent part of the SPI protocol, which is also critical, is that for every byte one transmits on the SPI bus, one receives a byte in return. Also, one cannot receive any bytes, unless one transmits a byte.
Typically, the SPI Master that the user is commanding, has a Transmit Buffer, which sends bytes out on the MOSI line of the SPI bus and a Receive Buffer, which receives bytes in from the MISO line of the SPI bus. In order for any data to appear in the Receive buffer, some data must have been sent out the Transmit Buffer. Similarly, any time one sends data out of the Transmit buffer, data will appear in the Receive Buffer.
If one is not careful about balancing Transmit writes and Receive reads, one will not know what to expect in the Receive buffer. If the Receive buffer overflow, data is usually just spilled and lost.
So, when one sends a read command, which is a one byte op code and three address bytes, one will first receive four bytes of 'garbage' in the SPI Master Receive buffer. These four bytes of garbage correspond to the op code and three address bytes. While those are being transmitted, the Flash does not yet know what to Read, so it just returns four words of garbage. After those four words of garbage are returned, in order to get anything else in the Receive Buffer, you must Transmit an amount of data equal to the amount that you want to Read.
After the op code and address, it doesn't matter what you transmit, it's just filler to push the Read DAta from the SPI Flash to the Receive Buffer. If you didn't keep careful track of those first four returned garbage words, you might think that one or more of them is part of your returned Read Data. So, in order to know what you are actually getting from the receive buffer, it's important to know the size of your buffer, know how to tell whether it's empty or full (there's usually register status bit to report this) and keep track of how much stuff you've transmitted and how much you've received. Before starting any SPI Flash operation, it's a good idea to 'drain' the Receive FIFO. This means check the status of the receive buffer and empty it (usually done by performing a 'read' of the Receive Buffer) if it is not already empty. Usually, emptying (reading) an already empty Receive Buffer does no harm. The following information is available from the timing diagrams in datasheets of SPI Flashes, but sometimes folks overlook bits.
All commands and data are issued to the SPI flash using the SPI bus. The sequence to read a SPI Flash is: 1) Start with CS high. 2) Bring CS low. 3) Issue 'Read' op code to SPI Flash. 4) Issue three address bytes to SPI Flash.
5) 'Receive' four garbage words in Receive Buffer. 6) Transmit as many arbitrary bytes (don't cares) as you wish to receive. Number of transmitted bytes after address equals size of desired read. 7) Receive read data in the Receive Buffer.
8) When you've read the desired amount of data, set CS high to end the Read command. If you skip this step, any additional transmissions will be interpreted as request for more data from (a continuation of) this Read. Note that steps 6 and 7 must be interleaved and repeated depending on the size of the read and the size of your Receive and Transmit Buffers.
If you Transmit a larger number of words at one go, than your Receive Buffer can hold, you'll spill some data. In order to preform a Page Program or Write command perform these steps. Page Size (typically 256 bytes) and Sector Size (typically 64K) and associated boundaries are properties of the SPI Flash you are using. This information should be in the datasheet for the Flash. I will omit the details of balancing the Transmit and Receive buffers.
1) Start with CS high. 2) Change CS to low. 3) Transmit the Write Enable (WREN) op code. 4) Switch CS to high for at least one SPI Bus clock cycle.
This may be tens or hundreds of host clock cycles. All write operations do not start until CS goes high. The preceding two notes apply to all the following 'CS to high' steps.
5) Switch CS to low. 6) Gadfly loop: Transmit the 'Read from Status Register' (RDSR) op code and one more byte.
Spi Serial Flash Programmer Schematics For Sale
Receive two bytes. First byte is garbage. Second byte is status. Check status byte. If 'Write in Progress' (WIP) bit is set, repeat loop.
(NOTE: May also check 'Write Enable Latch' bit is set (WEL) after WIP is clear.) 7) Switch CS to high. 8) Switch CS to low. 9) Transmit Sector Erase (SE) or Bulk Erase (BE) op code.
If sending SE, then follow it with three byte address. 10) Switch CS to high. 11) Switch CS to low. 12) Gadfly loop: Spin on WIP in Status Register as above in step 6. WEL will be unset at end. 13) Switch CS to high. 14) Switch CS to low.
15) Transmit Write Enable op code (again). 16) Switch CS to high. 17) Switch CS to low.
18) Gadfly loop: Wait on WIP bit in Status Register to clear. (WEL will be set.) 19) Transmit Page Program (PP = Write) op code followed by three address bytes. 20) Transmit up to Page Size (typically 256 bytes) of data to write. (You may allow Receive data to simply spill over during this operation, unless your host hardware has a problem with that.) 21) Switch CS to high. 22) SWitch CS to low. 23) Gadfly loop: Spin on WIP in the Status Register.
24) Drain Receive FIFO so that it's ready for the next user. 25) Optional: Repeat steps 13 to 24 as needed to write additional pages or page segments. Finally, if your write address is not on a page boundary (typically a multiple of 256 bytes) and you write enough data to cross the following page boundary, the data that should cross the boundary will be written to the beginning of the page in which your program address falls. So, if you attempt to write three bytes to address 0x0FE. The first two bytes will be written to 0x0fe and 0x0ff. The third byte will be written to address 0x000.
If you transmit a number of data bytes larger than a page size, the earlies bytes will be discarded and only the final 256 (or page size) bytes will be used to program the page. As always, not responsible for consequences of any errors, typos, oversights, or derangement in the above, nor in how you put it to use.
This codec offers superb sound quality and requires 64kbps of bandwidth. This is standard for most calls traveling in corporate intranets and is also widely used for calls over the public Internet. Install ilbc codec asterisk key.
You should be able to re-purpose the USBtiny to program a flash memory instead of a target MCU if you are comfortable changing it's programming. However, there may not be enough memory on that to make it versatile enough to program both the MCU and the flash. Somewhere I have a board from a project which has both an ATTINY and an SPI flash, and uses as an Arduino as a readily available 'programmer'. A slight modification of the ISP sketch is used to program the MCU with avrdude, then a custom utility sends a sequence which puts the sketch in a special mode and writes blocks of data to the SPI flash.
DLP-USB1232H based SPI programmer schematics In order to use the DLP-USB1232H device as SPI programmer you have to setup a small circuit (e.g. On a breadboard). See the schematics for details (you can also for easier printing). What you will need: Quantity Device Footprint Value Comments 1 — —. 1 Breadboard — —. Many Jumper wires — —. 1 DIP-8 SPI chip — — This is the chip you want to program/read/erase.
1 3.3V voltage regulator TO-220 3.3V E.g. LD33V or LD1117xx.
1 Electrolytic capacitor single ended 100nF. 1 Electrolytic capacitor single ended 10uF. Instructions and hints:. You must connect/shorten pins 8 and 9, which configures the device to be powered by USB.
Without this connection it will not be powered, and thus not be detected by your OS (e.g. It will not appear in the lsusb output). You need a 3.3V voltage regulator to convert the 5V from USB to 3.3V, so you can power the 3.3V SPI BIOS chip. You can probably use pretty much any 3.3V voltage regulator, e.g. LD33V or LD1117xx.
For usage on a breadboard the TO-220 packaging is probably most useful. You have to connect two capacitors (e.g. 100nF and 10uF as per datasheets, but using two 10uF capacitors, or even two 47uF capacitors also works in practice) as shown in the schematics, otherwise the voltage regulator will not work correctly and reliably. Connect the following pins from the DLP-USB1232H to the SPI BIOS chip:.
18 (SK) to SCLK. 16 (DO) to SI. 2 (DI) to SO. 5 (CS) to CS#. The WP# and HOLD# pins should be tied to VCC!
If you leave them unconnected you'll likely experience strange issues. All GND pins should be connected together ( pins 1 and 10 on the DLP-USB1232H, pin 8 on the SPI chip, pin 1 on the voltage regulator). You have to invoke flashrom with the following parameters: $ flashrom -p ft2232spi:type=2232H,port=A On older flashrom versions the syntax was: $ flashrom -p ft2232spi:ft2232type=2232:port=A Photos:. Module and parts FTDI FT2232H Mini-Module The can be used with flashrom for programming SPI chips.
Where to buy: FTDI FT4232H Mini-Module The can be used with flashrom for programming SPI chips. Where to buy: openbiosprog-spi is an Open Hardware USB-based programmer for SPI chips, designed. It uses an FTDI FT2232H chip and features either a DIP-8 socket or a pinheader where jumper-wires can be attached. The user-space source code is part of flashrom, the schematics and PCB layouts are licensed under the license and were created using the open-source EDA suite (GPL, version 2). For more information and downloads, including a parts list, Gerber file downloads, recommended Kicad settings, and recommended PCB manufacturer settings, see.
Usage: $ flashrom -p ft2232spi:type=2232H,port=A Photos:. RushSPI v0.1 Amontec JTAGkey/JTAGkey2/JTAGkey-Tiny The can be used with flashrom for programming SPI chips. And should work, if you add them to ft2232spi.c ( untested). Where to buy: Usage: More info can be found on on. You need a 3.3V voltage source - see above for details. Connect the following pins from the JTAGkey2 to the SPI BIOS chip:. 1 (Vref) to VCC.
Spi Serial Flash Programmer Schematics Diagram
5 (MOSI/TDI) to SI. 7 (CS#/TMS) to CS#.
9 (CLK/TCK) to SCLK. 13 (MISO/TDO) to SO. 20 (GND) to GND. The WP# and HOLD# pins should be tied to VCC. The 'Cable pinout' picture below shows the colors on the breakout cable.
Amontec JTAGkey-tiny Olimex ARM-USB-TINY/-H and ARM-USB-OCD/-H The (VID:PID 15BA:0004) and (15BA:0003) can be used with flashrom for programming SPI chips. The (15BA:002A) and (15BA:002B) should also work, though they are currently untested. The following setup can then be used to flash a BIOS chip through SPI. Pin (JTAG Name) SPI/Voltage Source 1 (VREF) VCC (from Voltage Source) 2 (VTARGET) VCC (to SPI target) 4 (GND) GND (from Voltage Source) 5 (TDI) SI 6 (GND) GND (to SPI target) 7 (TMS) CE# 9 (TCK) SCK 13 (TDO) SO On the ARM-USB-TINY, VREF, and VTARGET are internally connected, and all the GND lines (even numbered pins, from 4 to 20) share the same line as well, so they can be used to split VCC/GND between the voltage source and the target. The voltage source should provide 3.0V to 3.3V DC but doesn't have to come from USB: it can be as simple as two AA or AAA batteries placed in serial (2 x 1.5V). Invoking flashrom: You first need to add the -p ft2232spi option, and then specify one of arm-usb-tiny, arm-usb-tiny-h, arm-usb-ocd or arm-usb-ocd-f for the type. For instance, to use an ARM-USB-TINY, you would use: $ flashrom -p ft2232spi:type=arm-usb-tiny Openmoko The openmoko debug board(which can also do serial+jtag for the openmoko phones, or for other phones) has Informations The openmoko debug board can act as an SPI programmer bitbanging the FTDI(no need of an openmoko phone), you just need:.
a breadboard. some wires.
The openmoko debug board(v2 and after,but only tested with v3) The voltage is provided by the board itself. The connector to use is the JTAG one(very similar to what's documented in the previous section(Olimex ARM-USB-TINY/-H and ARM-USB-OCD/-H ) Building WARNING this was tested with 3.3v chips only. Here's the pinout of the JTAG connector of the openmoko debug board(copied from ARM-USB-tiny because it's the same pinout): Pin (JTAG Name) SPI/Voltage Source BIOS Chip connector name 1 (VREF) VCC (from Voltage Source) VCC (3.3v only) 2 (VTARGET) VCC (to SPI target) Not connected 4 (GND) GND (from Voltage Source) Ground 5 (TDI) SI DIO (Data Input) 6 (GND) GND (to SPI target) Not connected 7 (TMS) CE# CS (Chip select) 9 (TCK) SCK CLK (Clock) 13 (TDO) SO DO (Data output). Also connect the BIOS chip's write protect(WP) to VCC. Also connect the BIOS chips's HOLD to VCC Pictures. Pictures. Performances # time./flashrom/flashrom -p ft2232spi:type=openmoko -r coreboot.rom flashrom v0.9.5.2-r1545 on Linux 3.0.0-20-generic (x8664) flashrom is free software, get the source code at Calibrating delay loop.
Found Winbond flash chip 'W25X80' (1024 kB, SPI) on ft2232spi. Reading flash. Real0m19.459s user0m1.244s sys0m0.000s # time./flashrom/flashrom -p ft2232spi:type=openmoko -w coreboot.rom flashrom v0.9.5.2-r1545 on Linux 3.0.0-20-generic (x8664) flashrom is free software, get the source code at Calibrating delay loop. Found Winbond flash chip 'W25X80' (1024 kB, SPI) on ft2232spi. Reading old flash chip contents. Erasing and writing flash chip. Erase/write done.
Verifying flash. Real1m1.366s user0m7.692s sys0m0.044s Advantages/disadvantages. fast(see above). easily available(many people in the free software world have openmoko debug board and they don't know what to do with them), can still be bought. stable. SPI only.