Has anybody got a device that can program an 8 pin flash chip over SPI?

[Awesomely excellent]

I have been trying to use an mBed NPC1768 to program a loose 4mb flash chip. I am not having any success. I believe my code is ok, but maybe I have made a mistake somewhere. The flash chip is a Macronix MX25L3206E. I successfully read the contents from the flash using the mbed, and also got the whole chip to erase, but I cannot get new data in there.

I would like to try and use another programmer. Anyone got one, or any ideas?

[Ashfaq Juna]

Have a look at the pickit serial analyser.  It may give you the flexibility to send spi stuff as you like  .

On 13 Mar 2013 16:16, "Awesomely excellent" <brum...@googlemail.com> wrote:

I have been trying to use an mBed NPC1768 to program a loose 4mb flash chip. I am not having any success. I believe my code is ok, but maybe I have made a mistake somewhere. The flash chip is a Macronix MX25L3206E. I successfully read the contents from the flash using the mbed, and also got the whole chip to erase, but I cannot get new data in there.

I would like to try and use another programmer. Anyone got one, or any ideas?

--
You received this message because you are subscribed to the Google Groups "Nottingham Hackspace - Nottinghack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nottinghack...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Awesomely excellent]

That looks like a viable altrnative to try, anyone got one? They are £60 or so, which I cannot afford for a one time use.

[Ashfaq Juna]

Send me your address

Borrow mine for a while :-)

[Awesomely excellent]

Wow, thanks Ashfaq, that is really generous! I will send you a mail. I did some more testing last night and learned a little more. I still could not write to the chip, but I learned that it crashes and hangs everytime I try and write to it. I have followed the datasheets diligently. To recover it from a crash, I have to pull the +3.3v and reconnect.

So Im thinking it is one of these:
1) My C++ code for writing (most likely, but its that simple, how could I have gone wrong?)
2) Some incompatibility between the SPI implementation on the mBed and this particular flash chip.
3) The writing circuit on the actual flash chip die is damaged.

Borrowing another programming device should help narrow the current problem down. Cheers!

[Ashfaq Juna]

No problem

:-)

I would suggest adding more decoupling on the chip.

The most common thing to fail on flash devices are the charge pumps responsible for generating the high voltages for write cycles.  If that is the case,  then replacing the part is the real way forward.

Got your emails BTW :-)

[Andy Nevill]

Which package are you using?

Have you ensured that the part isn't protected either by WP being LOW or software protection being enabled.

Can your read data and the registers of the device properly?

I'm not sure I'd describe writing to a Flash device as simple :-)

Andy

[Awesomely excellent]

Hi Andy
Im using the 200 mil SOP.
The only command it seems to be responding to is the chip and mancufacturer id query. It does not seem to be behaving as I would expect. I have to cycle the power to the chip to get it to even respond to the ID query. Ashfaq's PICit arrived this morning, so I am going to do some more stuff this afternoon when I have time, but here is some of my code:

    // mosi, miso, sclk
    SPI spi(p5, p6, p7);

    // setup outputs with identifiers
    DigitalOut cs(p18);
    DigitalOut wp(p19);
    DigitalOut hold(p20);

    cs = 0;
    hold = 1;
    wp = 1;

// open file for reading
    FILE *fp = fopen("/local/AWESOME.BIN", "r");

// set write enable (WREN)
    spi.write(0x06);
   
// writing memory page , PageProgram command then three address bytes
    cs = 0;
    spi.write(0x02);
    spi.write(0x31);
    spi.write(0x00);
    spi.write(0x00);
    for (a=0x000; a<0x100; a++){
        r = fgetc(fp);
        spi.write(r);
    }
 

[Ian Dickinson]

After clocking the 256 bytes of page program data into the chip are you deactivating CS# ?

I realise you've not posted all your code, but this step appears to be missing.

Taking CS# high is what actually initiates the page program cycle.

[Awesomely excellent]

Yes I am taking CS high at the 256th byte boundary.

[Awesomely excellent]

And thanks Ian.

On Friday, 15 March 2013 20:33:51 UTC, Ian Dickinson wrote:

[Ian Dickinson]

OK, looking at this in more detail and revisiting some code I wrote a while ago for a similar device, it looks like it could be that CS# doesn't go high after issuing the WREN command. Try taking it high, before setting it low again for the page program. A small delay may also be needed, so the Flash device sees this high between commands.

[Awesomely excellent]

I am doing that Ian. Here is my exact code. I have already gone through many rounds of pedanticising it to try and get the device to do what I want. I am now at the point where I suspect the package is dead. This code returns 256 bytes of 0xFF's over serial, but it should return 256 bytes of text that has been written from the Z.BIN file:

 

// write to flash from local file

#include "mbed.h"

// Create the local filesystem under the name "local"
LocalFileSystem local("local");

// mosi, miso, sclk
SPI spi(p5, p6, p7);

// setup outputs with identifiers
DigitalOut cs(p18);
DigitalOut wp(p19);
DigitalOut hold(p20);

Serial pc(USBTX, USBRX);




int main() {
    int a = 0;
    int r = 0;
//    int b = 0x000;
//    int c = 0x000;

// Serial speed   
    pc.baud(230400);

// 8-bit data mode 3 at 1MHz
    spi.format(8,3);
    spi.frequency(1000000);

// Chip select, Hold off, Write Protect off

    cs = 0;
    hold = 1;
    wp = 1;

    wait(0.01);

// open file for reading

    FILE *fp = fopen("/local/Z.BIN", "r");
    wait(0.1);
   
//    for (c=0x000; c<0x040; b++){
//        for (b=0x000; b<0x100; b++){

            cs = 1;
            wait(0.01);

// set write disable (WRDI)
            cs = 0;
            spi.write(0x04);
            cs = 1;
            wait(0.01);

   
// set write enable (WREN)

            cs = 0;
            spi.write(0x06);
            cs = 1;
            wait(0.01);

// writing memory page
            cs = 0;
            spi.write(0x02);
            spi.write(0x00);

            spi.write(0x00);
            spi.write(0x00);
            for (a=0x000; a<0x100; a++){
                r = fgetc(fp);
                spi.write(r);

//                pc.printf("%c", r, " ");
            }
            cs = 1;
            wait(0.01);
//        }
//        pc.printf("c", " ");
//    }


    fclose(fp);
   
// Open file on the local file system for writing
    FILE *fpw = fopen("/local/X.BIN", "w");

// reading memory
    cs = 0;
    spi.write(0x03);
    spi.write(0x00);
    spi.write(0x00);
    spi.write(0x00);
    for (a=0x000000; a<0x000100; a++){
        r = spi.write(0x00);
        fprintf(fpw, "%c", r);
        pc.printf("%c", r);
    }

    cs = 1;

    fclose(fpw);
}

I am now going to learn how to use the PICkit that Ashfaq has sent me and try programming it with that. If that does not work then I will be buying a new flash chip.

Cheers :)

[moop]

I noticed you're opening the file for reading in text mode. This is OS/standard library dependent, and I don't have an mbed to check, but on some platforms this will treat a zero byte in the file as an end of file marker. After hitting this fgetc will start to return EOF (usually -1) which will be represented in an unsigned char as 0xff.

It's worth a shot at opening the file in binary mode ("rb") with the following:

FILE *fp = fopen("/local/Z.BIN", "rb");

--

Cheers,

Steve

[Ian Dickinson]

Your code now look like it's doing everything with the chip I would expect. The only other thing I can suggest is checking to see if the Write In Progress (WIP) flag is being set then cleared after the page program. However, as you say it may now be best to test the chip with a programmer, especially if you have doubts about it's state of health.

[Andy Nevill]

I have some 16Mb SPI flash devices in an SO8 (SOIC 150mil) package which from the brief look I took are the same pin pitch but the package is 150mil rather than the 200mil you have at the moment. If you can cope with half the density reduction and the package width difference I can let you have a couple.

Andy

[Awesomely excellent]

That is very generous Andy. It is a bios chip for a laptop motherboard, so even if yours could be made to fit, the command implementation will probably be different, preventing the the motherboard chipset communicating with the bios. Cheers.

[Andy Nevill]

Actually the command sets of most modern flash devices including SPI are pretty much identical. The only difference I can see between the devices I have and the one you're trying to program are the read and write security register commands. This may or may not be a problem but the different Manufacturer ID, Device ID and size might :-)

It's probably better to get the one you have working or find an exact replacement as you've indicated.

Cheers,

Andy