256-Kbit (32 K × 8) Serial (SPI) F-RAM - Ferroelecric RAM - SPI challenges

( See updated version of module)

Was looking for some serially connected RAM that has to briefly hold on to some processing data (not like EEPROM / SDCard) and has to be very fast. Came across this thing and it has great specs (datasheet attached). Ordered - 2 pieces - and got package yesterday. 'Tin-glued' it to Espruino board, added some more machined socket pins for connecting. With hardware 'complete', I started coding...

Reading the device ID got pretty quickly going... even though not standard. Everything after that became just rubbish... and still is. Nevertheless, I publish it here...

// FRAMSPI_inline.js (c) muet.com

// F RAM SPI Module

var framspiModule = { connect: function(spi,cs,hd,wp) {
  pinMode(cs,"output"); cs.set();
  if (hd) { pinMode(hd,"output"); hd.set(); }
  if (wp) { pinMode(wp,"output"); wp.set(); }

  var fram = 
{ id: function() {
    var d = spi.send(
      [0x9F,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01]
     ,cs); // chip select, write 0x9F, send 10*0x00 not working
    return d;
  }
, stat: function() { 
    var d = spi.send(
      [0x05,0x00]
     ,cs);
    return d;
  }
, wen: function() {
    spi.write(
      [0x06,0x00]
     ,cs);
  }
, wdi: function() {
    spi.write(
      [0x04,0x00]
     ,cs);  
  }
, read: function(a,n){
    cs.reset();
    spi.write([0x03,0x00,0x00]);
    var d = new Uint8Array(n);
    while (n>0) { n--; d[n] = spi.send(0x00); } 
    cs.set();
    return d;
  }
, write: function(a,d){
    cs.reset();
    spi.write([0x02,a>>8,a]);
    spi.write(d);
    spi.write([0xFF]);
    cs.set();
  }
};
  return fram;
}
};

SPI2.setup({sck:B13, miso:B14, mosi:B15, baud: 1000000});

var fram = framspiModule.connect(SPI2,B12);

console.log(fram.id());

/*
fram.write(  0,"FRAM@000");
fram.write(  8,"FRAM@008");
fram.write( 16,"FRAM@016");
fram.write(128,"FRAM@128");
fram.write(256,"FRAM@256");
fram.write(512,"FRAM@512");

console.log("@000:",fram.read(  0,  8));
console.log("@008:",fram.read(  8,  8));
console.log("@016:",fram.read( 16,  8));
console.log("@128:",fram.read(128,  8));
console.log("@256:",fram.read(256,  8));
console.log("@512:",fram.read(512,  8));
*/

The challenge is in SPI. Having done some work with the ILI9341 SPI LCD controller, I though: piece of cake... wrong. The FRAM's SPI is behaving weird: bytes get stuck in the output buffer and are read the next time. Also randomly dummy bytes are inserted for no obvious reason. Elaborating and trying to track some of the signals lead to the death of one chip... an so I had hope that the second would fair better. So far I can say: work different... actually more annoying: the broken chip could handle ID-read followed by a status-read. The new chip inserts dummy bytes so that the first status read has just those, as you can see in the output below (chip ID shows on upload, fram.stat() is called with a command n console):

 1v70 Copyright 2014 G.Williams
>echo(0);
[ 255, 127, 127, 127, 127, 127, 127, 194, 34, 0 ]
=undefined
>fram.stat();
=[ 255, 255 ]
>fram.stat()
=[ 255, 0 ]
> 

Tried to add other dummy byte, but this makes it even worse. Somehow, the chip does not follow its own spec which says that when chip select (CS) goes high, the SPI transaction is considered complete, even though send may not have completed yet.

It seems, that only continuously sending / receiving works to some degree: everything packed in a Uint8Array - including the command and parameters - and SPI.send() it a once. Using a mix and mach of SPI.write() and SPI.send() fails.

Looking for answers I came across hints that the SPI behavior is a bit unique... something about having to keep the clock going...

I have not given up yet, but if things do not smoothen out soon, I will look for a different solution.... :(

5 Attachments

• FRAMSPI_inline.js
• FM25V02_001-84494_0C_V.pdf
• 
• 
•