Support for Microchip flash memories? (SST26VF064B)

[Zvezdin]

Hello. I have an SST26VF064B flash chip from Microchip and am desperately trying to find a way to control it from an arduino UNO. No success so far, tried with multiple libraries including yours. Can you please add support for my chip in your library or perhaps point me to another library that supports it?

[Marzogh]

Hey mate, I currently do not have any microchip flash chips on me so I won't be able to test any changes I make. However, I will take a look at the datasheet for you and get back to you asap if I can find a way to modify the library and you can test to see if the changes work.

[Zvezdin]

Thanks! I'll be happy to test out anything you tell me!

[Marzogh]

I think I have a temporary workaround in place. The v2.2.1-w.i.p branch should work with the Microchip Flash (in theory). After you replace the SPIFlash library with the copy from the v2.2.1-w.i.p branch, open SPIFlash.cpp file in your favourite text editor and uncomment the line that says#define NOTCHIPSPECIFIC and save and close the file.

Once you do that, almost all the functions of the library should run on the Microchip Flash - with the exception of suspendProg and resumeProg (which I will be adding in a future update) and powerDown and powerUp (for which the Microchip flash has no equivalent functions). Let me know how it goes :)

[Zvezdin]

Okay I got to test it now. Here is the output I'm getting when running your TestFlash and DIagnostics example: http://imgur.com/a/gol8w

It fails to write anything. Each single byte in the chip has value of 255 even after writes/ wipes (except byte 0, page 0; which has value of 0)... Strangely, trying to read a string from TestFlash example reinitializes the program (doesn't happen if reading from page 0, postion 0).

It is possible that on my end something happens because I'm using cheap wiring. Will take a look now but oscilloscope results suggest that data is being send and received from the chip.

EDIT: More testing : http://pastebin.com/8js8AuEg

[Marzogh]

Hmmm. Thanks for that.

This will probably be faster if I test straight up with one of Microchips SST26Vs. Just put an order with RS for some (and a bunch of other flash chips by other manufacturers as well). They should be here in a couple of days and I'll get cracking on this and hopefully have it sorted by this weekend. Adding compatibility with non-Winbond chips is something I've been meaning to do and this is the perfect excuse :D

[Jubatian]

Hi! Could you interface this chip?

We failed to interface them (with an XMegaA3U), however largely equivalent Cypress chips worked. In our case the Microchip flash's MISO stuck low when it was connected to the micro and attempted communication with very narrow spikes where 1 bits were supposed to be transmitted. If the pin was disconnected, by oscilloscope, we could observe the chip communicating. This board was designed for testing various memory chips, everything else worked with it (these were a 64 MBit Cypress flash, a Cypress 1 MBit FRAM, an Everspin 1 MBit MRAM, and a Microchip 1 MBit SPI EEPROM). We tried two of the SST26VF064B chips, both of them failed in this manner (in the end we simply discarded them since the equivalent Cypress chips work just as well).

[Zvezdin]

Hello!

It's been a while haha. After a lot of troubleshooting I failed to interface it. I got myself a Teensy 3.6, with its ram capacity being enough for my needs (the arduino's lack of ram was the reason I tried flash chips). I don't remember the exact results when I did my oscilloscope testing, but the chip was trying to communicate, with the arduino not picking the signal up.

[Marzogh]

Hi guys,

My apologies for dropping off the face of the earth for the last few months. It has been a very busy time at work from January on (and I was away tramping through New Zealand in December). I have been attempting to get the Microchip flash modules to work with any Atmega based board and failing - with the same issues that @Jubatian has described. Oddly enough though, I am able to establish comms with the Microchip flash if I write up an independent SPI.transfer() based sketch. I'm going to take another stab at it over the Easter weekend and will post the results here - cross my heart! Hopefully I can figure out what's going wrong - this has been bugging me for a while now and has been holding up the release of v2.6.0 for a while. :/

Cheers!

[Marzogh]

Also, @Jubatian , if you wouldn't mind, could you test the code from v2.6.0-w.i.p with the plethora of flash memories you seem to have? I'd love to know how compatible it is with non Winbond chips. I'm hoping that the library restructure might help with figuring out what's causing the Microchip flash comms to fail.

Thanks in advance,

Praj

[Jubatian]

Hi! The project was ongoing at my workplace, currently I don't have the board (we completed the related tests for making decisions over the chips). The MRAM and the FRAM chips have identical protocol from the point of data transmission (the same code handled them), the EEPROM had some fundamental differences in writing (but as far as I see, an EEPROM oriented code might be capable to handle the FRAM / MRAM chips). Our decision was to simply discard the Microchip flash consitering it defective in the end (because all the rest operate correctly). The code originally designed for the Microchip flash can handle the identical capacity Cypress / Spansion flash. I asked this in this regard, attempting to do some research on whether the Microchip flash was actually a defective product (in some manner).

On the oscilloscope captures the MISO of the "defective" product is normally high, when it is clocked (or maybe when the chip select is active, I can't remember) it goes low, and stays there if, and only if it is connected to the XMega. If it is unconnected, the scope can capture the correct responses. The exact same hardware was used for other chips (we designed a DIP8 converter PCB for the memory chips). By that we can observe the line being able to go high, we think that it shouldn't be some issue with any pull-down within the XMega, although we also tried various pin configurations (and SPI modes) without any success.

[Marzogh]

Hooray! I've got comms going. Single byte/char read/write, struct read/write and byte/char array read/write are working as well. Just need to fix up the code to sort out read issues for the larger data chunks and we should be good to go. (#66)

The problem is that the BP0, BP1, BP2 & BP3 bits in the status register default to 1111 on power up - effectively write protecting the entire chip. My quick and dirty fix for now is to set them to zero as soon as the flash chip is ID'd as a Microchip as a part of flash.begin(); by including the following in the function _chipID() that gets called in begin()

if (!_getJedecId()) {
    return false;
  }

  if (_chip.manufacturerID == MICROCHIP_MANID) {
    uint8_t _stat1 = _readStat1();
    _stat1 &= 0xC3;
    _beginSPI(WRITESTATEN);
    CHIP_DESELECT
    _beginSPI(WRITESTAT);
    _nextByte(_stat1);
    CHIP_DESELECT
  }

I'll see if there is a more graceful / user friendly way to do this before any release, but, all in all we have success!!! 😁

Note: I've been testing this with the SST25VF064C which is EOL. I'm waiting to get my hands on a SST26VF064B (I put my set of those in a safe place when I moved house and can't find them now. I know they are safe though! 😝 ), so I can test this works with a modern chip - however, the datasheets say similar things about I/O, so I reckon what works with the older chip should work with the newer one. I live in hope 🤞

[Jubatian]

The problem is that SST25VF064C works correctly, we were in a very similar situation: We used that chip until recently, then noticing the EOL, we tried to upgrade and failed. Now we had another project with an MSP430 micro, where out of curiosity we tried the SST26VF064B again. It neither operated in that environment, while all the other chips (those mentioned above) we had worked. The problem is not write protection, rather that it seems impossible to even communicate with this new chip.

[pornpol]

Anyone can use the library with SST26VF064B?

[Marzogh]

Not yet mate. I haven't been able to establish Comms with the chip. :/

[Marzogh]

Hey mate. I've got it working! The code in the 'stable' branch compiles and runs on both SPANSION/CYPRESS & MICROCHIP (Both SST25 & SST26 series). I've specifically tested the SST26VF064B and it works with all supported platforms.

The darned chip has all blocks write protected when it comes out of a power on or reset. I just had to whip up a _disableGlobalBlockProtect() function to run once with the flash.begin() and all's good to go. 😎