SPI Flasher

I submitted this project to the Hackaday Prize 2016 because I welcome incentives to turn it into a full spin-off of the #YASEP Yet Another Small Embedded Processor project. Now I see it is tangled in a web of co-dependencies with other subprojects and co-projects such as #Raspbian Squeezed.

What works ?

At home, it works great on a Raspberry Pi model B, using an obsolete version of the YASEP web interface, based on the the old #YGWM Whygee's JavaScript Window Manager system. The flashing algorithm is great (better than my commercial chinese flasher) and the source code is available from the main yasep.org project base (see links on the project page)

What is missing ?

You know the saying, if it ain't broken, don't fix it ? Well it works for me so why work further ?

The problems however are piling up and might break the whole thing one day or another.

• The Raspberry Pi hardware is not the stable, trusted platform it seemed to be. New PCB versions and new CPUs have been introduced at (relatively) breakneck speed and I assume it will continue (until the Pi foundation throws the towel).
  I have not yet updated my custom SPI routines to adjust the IO address of the SPI hardware. Why did they change it in the PI2 ?
  Anyway, it's one of the first things to do, but it requires non-insignificant attention and testing. I have already too many projects and I ain't even working on the side or being paid so...
  UPDATE20161106: I'm adding new sub-projects #C GPIO library for Raspberry Pi, #HYX file format and soon the SPI library.
• The OS is not stable either. Raspbian has evolved a lot and even changed face. It has bloated and this has raised many concerns, not just from me. A reliable, small-footprint Linux is needed and maintaining the #SPI Flasher involves restarting a full system install every 6 months or so, which takes a day or three to get right. Scripting does not help when the OS modifies this and that in my back :-(
  Without this, the only way to run a SPI flasher is to install a vanilla image, log in with SSH and run the commands on the command line. Which is slower than the intended method through the web browser. Oh wait, that's another story.
• The #YGWM Whygee's JavaScript Window Manager must be rewritten from scratch. That's a few months of work, that I don't have :-(

So for a winning entry in the HaD contest, I can't submit the project as it was intended, I must reduce the ambitions. But I've already gone pretty far since the beginning of this project :-)

Hopefully, one day, I'll be able to provide a pre-configured image to flash on your SD card with instant boot to the desired functionality. But this looks more and more like shooting many moving targets at the same time. I can adapt things here and there, YGWM is a project that I fully control and will develop, but I am growing tired of having to play catch with the Pi Foundation's whims.

Of course the solution would be to have a working #YASEP Yet Another Small Embedded Processor but I must bootstrap the whole platform somehow, somewhere.

The .hyx files can get large. Pretty large. A 16MB flash chip requires 32 or 48MB of storage. I should add support for Zlib, which provides transparent support of gzip-compressed data...

Until I do it, thanks to posixity, it's possible to write this, when the original file is compressed :

gunzip file.bin.gz
bin2hyx file.bin | update_SPI_flash -

Sorry for the lack of updates, I'm pretty busy everywhere but I don't forget this project ! Thank you everybody for (still) following it :-) Your interest motivates me !

For another application, I just got a TL866 USB universal programmer and it's working rather well. Most of the time. I'm testing some W25Q128 chips I just bought for a project and several would fail when writing the chip with all 0s. Repeatedly on the same chips, but not others of the same lot. Weird. Is this batch of chip mixed with bad apples ?

Fortunately I have the Pi SPI Flasher and I found that the chips have been properly written. So what happened ? It might be the TL866 as well because my algorithm finds no error. Maybe the TL866 tries to be too agressive ? Why are there reading errors on some chips and not others ?

I've also run another simple test:

$ time ./update_SPI_Flash zero16M.hyx verbose DIV 24
...
Writing 256 bytes to address FFFD00
Writing 256 bytes to address FFFE00
Writing 256 bytes to address FFFF00
* Pass 2
 Checking the sector
 Checking for page to write...
  Sector : OK with 2 passes.

16777216 bytes written.

fermeture SPI
Setting pins 8 9 10 11 22 as input
Flash programming OK
real    2m41.221s
user    1m49.320s
sys     0m16.060s

(note: it was run over ssh which uses some CPU...)

Whereas the TL866 took 7 minutes 23 seconds to do the same task.

I guess I will not use the USB programmer for this kind of SPI chips (particularly when I have tens of chips to test). I also see that my programming algorithm is better/smarter than the TL's :-) It's both faster and more accurate.

More reasons to continue this project ;-)

This SPI flasher is part of a much larger project. As the whole system grows, so does each part and a spin-off becomes necessary for reliability and stability.

I want to make a high quality system with a great tutorial that most DIYers can follow. All help and feedback is welcome ! Who would like to test the tutorial ? Who wants to add parts to the list of supported chips ? What other features are needed ?

The documentation has grown fast so far but it's going to stall for a very common reason: it will deal now with software. Software development is slow. Hardware design is comparatively simple, easy and fast. Software is the quicksand of computing. Please excuse me for the delays ;-)

I have developed quite a bit of software and I have a working and cool Flashing system at home but the spin-off requires a complete review of all the code, a deep rafactoring to make it totally stand-alone and suitable for your use. Your help is again more than welcome. My plan includes a total rewrite from the ground up:

• get a Pi2 board (I'm using B and B+ now but many use the newest shinier ones) but I'm so broke right now... => done thanks @bsteph27 !
• create a suitable Raspbian derivative => ongoing as #Raspbian Squeezed (please be patient)
• Modify the GPIO and SPI code to support BCM2836 (not hard)
• Write a CPU-agnostic SPI version with bit-banging (for other platforms, even a PC-LPT one ?)
• Include support for #DIPSY (easy)
• Make the source code easy to download, compile and use...
• I can host small packages but how to distribute a large Pi OS image without breaking my server ? ==> see #Raspbian Squeezed and its scripts

As you see, writing this page is only a tiny part of all the required development. How could you help me ?

The Winbond 25Q128 is a really cool part : high capacity (16 MBytes), very fast, good support for many standard instructions, supports wide bus modes... But it can be expensive depending on the application.

I found the little sister 25Q32 : I use 6 of them on each board of a project. I expect it to be almost exactly the same as the 25Q128 but with only 4MBytes (so the board has 24MB, still nice). I got them off eBay and received them. Now comes the time to try them !

As I am writing a detailed tutorial, I want to use this project log to show how to add a part to the SPI flasher so others can add their own (and as much as possible provide feedback so I can make this system better, for me and everybody else).

First, let's get the datasheet !

Google gives the right PDF on the first result when I type "datasheet 25q32bvsig". The file is on the Winbond website and I miror it on my own site http://ygdes.com/pdf/Flash/, for archival and easy retrieval.

Let's analyse the data :

• The device operates on a single 2.7V to 3.6V power supply : 3.3V compatible voltage : check
• Standard pinout : check
  
• 256-byte per programmable page : Page Program instruction (02h) accepts up to 256 bytes : check
• Clock frequency for Read Data instruction (03h) 50 MHz max : check
• Uniform Sector/Block Erase (4/32/64K-bytes) : Page Erase instruction SE (0xD8) erases one 64KB block : check
• nothing sounds unusual...

More analysis is necessary to complete the description and table in SPI_Flash_chips.h but it seems to follow the 25Q128's definitions so this is just a matter of checking that every instruction matches.

The 25Q32 follows all the conventions so it's safe and easy to use with the flasher. I can update SPI_Flash_chips.h :-)

Let's now solder !

I also bought some tiny DIP8-SOIC8 adapter boards on eBay so I can test them in the common DIP8 socket. I have a SOIC ZIF somewhere but it's not very practical. The PCBs need pins too: these come from special DIP8 sockets that I hacked a bit and provides a sturdy base, but you'll use your own parts.

This time I put the capacitor directly close to the chip's power supply pins.

Now I can test it !

I power the Raspberry Pi on, looking at the HDMI screen that displays the boot logs.

My IP address is 192.168.41.100

pi login: _

[yg@localhost ~]$ ssh pi@192.168.41.100
pi@192.168.41.100's password: pi
Linux pi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l
/dev/root on / type ext4 (ro,noatime,errors=remount-ro,data=ordered)
remount RW
pi@pi ~ $ _

The software tools are installed in the Apache data directory. I go there to execute one of the test programs:

pi@pi /var/www/C $ sudo ./test_SPI_Flash 

SPI Flash Signature :
 EF 40 16 00 00 00 00 00
 15 15 15 15 15 15 15 15
Status Register = 00
 * Ready
 * Write disabled
 * Array is unprotected
{
  start=0,
  data=[
83,0,41,29,133,3,64,18,0,12,127,0,125,0,123,128,
18,0,8,126,0,127,4,125,255,18,0,10,144,255,0,224,
...
1,184,0,0,0,0,0,2,1,191,67,111,112,121,114,105,
103,104,116,32,49,57,57,57,45,50,48,49,48,44,32,97 ]
}

Setting pins 8 9 10 11 22 as input

I can now copy the extracted signature (very similar to the 25Q128) and paste into the chips library :

pi@pi /var/www/C/src $ nano SPI_Flash_chips.h

                      0xD8   0x03            Bulk
                     Sector   Page  Freq     Erase    Test            Signature
               Mbits  Erase  write  (MHz) (s)  (DS)   R/W     RDID            RES
25LC1024        1     32KB    256     10   0?  (2-4)   OK    (0)+            (29)+
M25P40          4     64KB    256     75   5 (4.5-10)  OK   20 20 13 (00)+   (12h)+
A25L40P         4     64KB+   256     85   2  (6,12)   OK   (7F 37 20 13)+   (12h)+
SST25VF016B    16     64KB      x     50               KO   (BF 25 41)+      (BF 41)+
SST25VF032B    32     64KB      1     80               1o   (BF 25 4A)+      (BF 4A)+
AT26DF321      32     64KB    256     66  39           OK   1F 47 (00)+      (00)+  (sold protected)
W25Q32B        32     64KB    256    104   5 (7-15)    OK   EF 40 16 (00)+   (15)+
W25Q128F      128     64KB    256    104  40 (40-200)  OK   EF 40 18 (00)+   (17)+

pi@pi /var/www/C $ time sudo ./wipe_SPI_Flash
Status Register = 00
 * Ready
 * Write disabled
 * Array is unprotected
4s  /
Setting pins 8 9 10 11 22 as input

real    0m5.070s
user    0m0.030s
sys     0m0.020s
pi@pi /var/www/C $ _

A deeper reading of the datasheet lets me complete the instruction table, which is not as extensive as the 25Q128 but comparable to the other 32Mb parts.

Finally, I access the #YGWM interface to edit codes and when I click on the "Flash .HYX" button, the chip is correctly overwritten and updated by update_SPI_Flash.cgi. Success !