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

Braking of the chip was when I touched unintendedly VBat/5V with HOLD and WP - hold for interruption of a communication and write protection. Some stuff still worked: SPI still responded, but the ID was messed... obviously some 'inner' / memory oriented part got 'flushed'. Luckily nothing else 'departed'.

The incident happened when I measured input and behavior on the lines for wiring verification.

Since I successfully execute read ID, status, AND write status commands, I can assume that wiring is ok. It has to do with the code - write or send related buffering and the clock.

Below is the list of commands. the bolded ones work.

Commands (opcode binary - hex - symbol - Description)

1. 0000 0110b - 06h - WREN - Set write enable latch
   
2. 0000 0100b - 04h - WRDI - Reset write enable latch
   
3. 0000 0101b - 05h - RDSR - Read Status Register
   
4. 0000 0001b - 01h - WRSR - Write Status Register
   
5. 0000 0011b - 03h - READ - Read memory data
   
6. 0000 1011b - 0Bh - FSTRD - Fast read memory data
   
7. 0000 0010b - 02h - WRITE - Write memory data
   
8. 1011 1001b - 09h - SLEEP - Enter sleep mode
   
9. 1001 1111b - 9Fh - RDID - Read device ID
   
   

WREN and WRDI change the register which I can verify with RDSR.

This status register is though in the control section of the chip and not the memory section. Where the ID is located, I do not know... it could be a PROM part of the chip. So I wonder if I ever experience access to the memory part.

A more elaborate command sequence with output below:

 1v70 Copyright 2014 G.Williams
>echo(0);
[ 255, 127, 127, 127, 127, 127, 127, 194, 34, 0 ]
=undefined (code loaded, above fram.stat() is part of the loading)
>fram.stat();
=[ 255, 255 ]
>fram.stat();
=[ 255, 0 ]
>fram.wen();
=undefined
>fram.stat();
=[ 255, 255 ]
>fram.stat();
=[ 255, 2 ]
>fram.stat();
=[ 255, 2 ]
>fram.wdi();
=undefined
>fram.stat();
=[ 255, 255 ]
>fram.stat();
=[ 255, 0 ]
>fram.stat();
=[ 255, 0 ]
>fram.id();
=[ 255, 0, 255, 127, 127, 127, 127, 127, 127, 194 ]
>fram.stat();
=[ 34, 0 ]
>fram.id();
=[ 255, 0, 255, 127, 127, 127, 127, 127, 127, 194 ]
>fram.stat();
=[ 34, 0 ]
>fram.stat();
=[ 255, 0 ]
>fram.stat();
=[ 255, 0 ]
>fram.id();
=[ 255, 0, 255, 127, 127, 127, 127, 127, 127, 194 ]
>fram.stat();
=[ 34, 0 ]
> 

It looks like as if bytes are still hanging somewhere in the SPI output buffer and are then delivered prepend to the next output. Have to figure out how to suck up and throw away thse trailing things... it looks like it happens only when the command changes: a repeated status read - stat() has not trailing/leading fillers. Using another command than stat() after *stat()8, such as id(), I get the filler again. I can consume them with a stat() call that expects two bytes from the chip (interestingly ignoring the command). After consuming them - obviously no matter with what command, just byte count correct - I'm back in sync again.

While trying to describe my observation, I guess I noticed this pattern: on changing command sequence, some fill bytes show up. This would also explain some other observations I made and tell me that I had access to the memory: when reading from the memory, I got 0's and 255's back... the 255's were fillers, where as the 0's were actually memory data (chip comes w/ 0's initialized).

I give it another try with module code changed to take this command repeat/change pattern into account.

...it's obviously not that simple... sucking up left over bytes has also an impact on what's delivered next...

It must have something t do with when spi clock stops and when chip select goes high. The whole thing needs more discovery on the SPI part.