Jump to navigation Jump to search
WARNING,if you don't add the resistors, the SPI levels are at 5V, while I tried it with 3.3V chip and that it worked(but DIO was at 4.3v which was over the maximum of 4v, during all the time that the chip was connected to the programmer), it may not work for you and break the chip...
Building the flasher
This flasher require the following hardware parts:
- An arduino uno or an arduino Duemilanove(way faster) and its usb cable
- some wires(optionally some connectors to solder on(for easier plugin and more reliability)
a 10k resistor
- 3 x 10k resistors (for the 3.3v version)
- 3 x 15k resistors (for the 3.3v version)
- A flash chip with the following characteristics:
- supported by flashrom
- 3.3v or 5v(the arduino has a 3.3v and a 5v output, only 3.3v was tested...)
Left pins of the BIOS chip: -------------------------------------------------------- [pin1 of the bios chip] /CS<->10k resistor<->VCC [pin1 of the bios chip] /CS<->Arduino pin10(SS, PORTB2) [pin2 of the bios chip] DO<->Arduino pin12(MISO, PORTB4) [pin3 of the bios chip] /WP<->VCC [pin4 of the bios chip] GND<->GND on the power pins Right pins of the BIOS chip: -------------------------------------------------------- [pin8 of the bios chip] VCC<->+3.3V on the power pins of the Arduino [pin7 of the bios chip] /HOLD<->VCC [pin6 of the bios chip] CLK<->Arduino pin13(SCK, PORTB5) [pin5 of the bios chip] DIO<->Arduino pin11(MOSI, PORTB3) The Bios chip used is a W25X80. The Arduino is an arduino uno.
WARNING, I was told that by Simon Inns by mail: "The 3V3 fritzing example on the Wiki (the diagram of the breadboard) is quite wrong... The 3V3 output from the Uno is shorted to GND and the CLK and DI pins of the EEPROM are connected together after the 10K resistors. Might be a good idea to fix it before you get "You broke my Uno" emails ;)"
Improved version by Simon Inns
Compatibility, software and setup
There are some differences between the various arduinos that are relevant for this flasher:
- Only the AVR architecture is supported for now, because the code depends on avr-libc. In one hand that makes it portable across other non-arduino AVR boards, but it also makes it incompatible with the arduinos that don't have an AVR.
- Some Arduinos have an FTDI USB<->Serial converter, we can achieve a very high speed of 2000000 bauds with ir.
- Some Arduino have a 8u2/16u2 instead: This is an extra microcontroller which does the USB<->serial conversion trough a firmware build on LUFA. While that brings lower cost and more flexibility, the downside is that in our case the default firmware was not written for speed over 115200. To get more speed we would need to write another firmware for it.
- Some Arduinos don't have an USB<->serial converter, like the arduino leonardo. Instead they have a native USB port.
- Most/All Arduinos have an accessible serial port on their pins. if you have an extra USB<->Serial converter, you can plug it to theses pins. BE SURE TO CHECK THE VOLTAGE COMPATIBILITY BEFORE ATTEMPTING THAT.
- Some arduinos are at 3.3v.
- Some are at 5v. Unfortunately most SPI chips are at 3.3v at the time of writing.
To make it work you need:
- A recent flashrom with the serprog protocol compiled in (most packaged versions do)
- serprog-duino which runs on the arduino
- The avr toolchain(avr-gcc, avr-libc,make etc...)
Building the software
First get the firmware source:
$ git clone git://gitorious.org/gnutoo-personal-arduino-projects/serprog-duino.git $ cd serprog-duino
Then build it:
For a board with a 8u2 or a 16u2:
$ make u2 && make flash-u2
For a board with an ftdi:
$ make ftdi && make flash-ftdi
The right flashrom arguments are explained in the help when running make.
$ make Available targets: ftdi, flash-ftdi: For the Arduinos with an FTDI compatible flashrom arguments: flashrom -p serprog:dev=/dev/ttyUSB0:2000000 Other boards using an hardware USB<->Serial converter might work too. u2, flash-u2: For the Arduino with a 8u2 or a 16u2 compatible flashrom arguments: flashrom -p serprog:dev=/dev/ttyACM0:115200
So for a board that has an ftdi that would give:
flashrom -p serprog:dev=/dev/ttyUSB0:2000000
The speed is very dependant on the flash chip used:
- Its capacity impacts the speed a lot, as you would expect.
- The chip model as also a huge impact.
With the duemillanove:
# time flashrom -p serprog:dev=/dev/ttyUSB0:2000000 -r duemillanove.rom flashrom v0.9.7-r1711 on Linux 3.18.3-gnu-1 (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... delay loop is unreliable, trying to continue OK. serprog: Programmer name is "serprog-duino" Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on serprog. Reading flash... done. flashrom -p serprog:dev=/dev/ttyUSB0:2000000 -r duemillanove.rom
4.23s user 0.29s system 8% cpu 56.010 total
With the Arduino uno:
# flashrom -p serprog:dev=/dev/ttyACM0:115200 -r uno.rom flashrom v0.9.7-r1711 on Linux 3.18.3-gnu-1 (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... delay loop is unreliable, trying to continue OK. serprog: Programmer name is "serprog-duino" Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on serprog. Reading flash... done. flashrom -p serprog:dev=/dev/ttyACM0:115200 -r uno.rom
4.77s user 0.65s system 1% cpu 6:02.43 total
- SST25VF016B => huge issues, not recognized by the 3.3v version, had to use the 5v version which is over maximum allowed voltage, also had to lower the serial speed to 115200, ultra slow to write(seem related to the chip itself, since that with the openmoko programmer it's even slower...)...
- W25X80 works well in 3.3v mode(5v works also but it's highly not advised to use 5v)
Advantages and disadvantages
The speed isn't that great(about 3 minutes for reading+writing+verifying a 1M chip)Fixed by by Sebastian Parborg. Voltage issues( SPI levels are at 5v, it's problematic for flashing 3.3v chips...)
- it is made of very commonly available parts(if you can find an arduino uno, you will be able to build it).
Find a way to lower the voltage to 3.3v Fix the arduino UNO speed and reliability issuesSimply lowering the bauds as advised on the LUFA mailing list long time did fixed it.
- Write a faster 8u2 firmware
- Look at other AVR targets
- Look if it's portable to other architectures (like ARM).