Replacing SST25VF080B by SST26VF064B

Spaeth · Joined: 05 Jun 2020 Posts: 27

Hello, in a project I'm using a SST25VF080B successfully. I'm using the sst25vf.c driver supplied by the compiler.
Now I need more memory space and I replaced the SST25VF080B by an SST26VF064B using the same driver, but without success.
What do I have to change? I would like to use the SST26 in normal SPI mode.

Best regards
Thomas

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Post a small test program where you attempt to read the ID (for example)
and it fails. Tells the details of the failure.

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

OK.
Now presumably you have changed FLASH_SIZE in the driver to 16777216?.
Remember if you have done this, and saved the new driver in your local
directory, you need to change the #include to use """, not <> or it'll
load the unmodified copy.
The protection defines will be wrong. The actual values are the same, but the
smallest protect covers the top 1/16th of the memory, not 64K.
The commands all look as if they should work correctly. The addressing
supports the full range.
As PCM programmer says, some more details please.

Spaeth · Joined: 05 Jun 2020 Posts: 27

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

You need to create a char array large enough to hold the ID.

char ID[4]; //should only need 3 bytes

Then just use ID in the command.

You'd need to print it as hex digits, since the first byte should be 0xBF

fprintf (PORT, "Manufacturer's ID: %x,%x,%x...", ID[0], ID[1], ID[2]);

Spaeth · Joined: 05 Jun 2020 Posts: 27

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

They actually define FLASH_ID as a type in the driver, so you can use

FLASH_ID ID;

and then read with

ext_flash_read_id(ID);

then the bytes are called ID.manufacturer, ID.type and ID.capacity.

However it should have worked with the ID as given before.

00, honestly suggests a wiring problem. Either the read or write data line
shorted by a whisker. Or could be the CE line.

Spaeth · Joined: 05 Jun 2020 Posts: 27

Spaeth · Joined: 05 Jun 2020 Posts: 27

Hello,

the function ext_flash_read_id(ID) can not work with the SST25VF080B for the following reasons:

- in the original sst25vf.c driver file the RDID-command is 0x9F, but the datasheet says 0x90 or 0xAB
- in the original sst25vf.c driver file the flash ID consists of 3 elements: manufacturer, type, capacity, but according to the datasheet the ID consists of manufacturer and device only
- according to the datasheet the command RDID consists of the command 0x90 or 0xAB itself and 3 address bytes (0x00000 or 0x00001) and then the device sends two bytes of ID, the manufacturer ID and the device ID

I will try to copy and change the ext_flash_read_byte or the ext_flash_read_word command to get the ID.

Any ideas or hints are welcome!

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

You need

ext_flash_read_id(&ID);

The 0x9F, returns the Jedec ID. Is meant to be supported by the new chip.

Spaeth · Joined: 05 Jun 2020 Posts: 27

Back to the main topic replacing ST25VF080B by SST26VF064B.
The original sst25vf.c driver will not work with the SST26VF0xxB because the SST26VF0xxB is another family with a few changes in the instructions.

I will try to modify a sst26vf0xxb c-driver supplied by Microchip.

Or does anybody have a running sst26vf0xxb.c driver?

Regarding the READ-ID topic: sorry, I was mixing up JEDEC READ-ID and READ-ID. Using SST25VF080B it's running correctly now. I will try soon using SST26VF064B

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

No, the basic instructions are identical between the chips 0x3 = READ,
0xB = high speed read, 6 = WREN, 2 = Write (the 25 only supports
single byte here, while the 26 supports a page write).
The addressing is the same. the 25, requires a 3 byte address, but only
uses the bottom 21bits of this.
All of the instructions are compatible.

You seem to be saying that you can read and write to it. If so, what more
do you want?.

Spaeth · Joined: 05 Jun 2020 Posts: 27

Hello Ttelmah,

sorry for the confusion.

The project using SST25VF080B is running properly. No problems.

Now I replaced the SST25VF080B by an SST26VF064B. Running READ-ID I got the right values (0xBF, 0x26, 0x43). But I cannot write and read to the chip, maybe I can read (result is 0xFF), so perhaps it fails writing to the device.
Here the relevant code:

Ttelmah · Joined: 11 Mar 2010 Posts: 19510

OK. That is really good.
The fact that you did get the ID bytes says the communication is OK.
It sounds like the status command is different. Will go and have a look.

Updated.

The 26, always uses this mode. Just remove this line.

If you are using anything larger than the byte write, then in the code
wherever it uses SST25VF_WORD_PROG replace with
SST25VF_BYTE_PROG.

The 26 runs all writes in 'page mode' which means it accepts multiple
bytes like the WORD_PROG instruction does.

Spaeth · Joined: 05 Jun 2020 Posts: 27

Hello Ttelmah,

I think I found the reason why I cannot write to the SST26VF064B.
The memory is write protected after power up by default, I have to unlock the protection.
At the SST25VF080B it's done by the command ext_flash_protect(FLASH_PROTECT_NONE), but for the SST26VF064B this command does not exist, a similar command would be sending 0x98 (Global Block-Protection Unlock (ULBPR)). I will try to modify the sst25vf.c driver.

Or any idea?