Lyontek LY68L6400 8 megabyte SPI "SRAM" - am I reading the data sheet right?

[peter-h]

I did some final tests on this chip, to explore the hypothesis that if after a long packet you don't access it for a bit, it will have enough time to refresh the entire chip.

The results are very interesting, and will solve the issue in the right applications.

With a 1024 byte packet (400us CS=0) one needs 50us of CS=1 to avoid errors at +105C (not tested higher)
With a 8192 byte packet (3200us CS=0) one needs 100us of CS=1 to avoid errors at +80C (not tested higher).
With a 16384 byte packet (6400us CS=0) one needs 300us of CS=1 to avoid errors at +80C (not tested higher).

Contrast this with the CS=0 spec of 8us max

Fairly obviously the internal refresh is fairly quick.

At packet sizes like 1024 bytes it is rock solid at > 100C.

So one needs just a fairly short CS=1 time to make a complete nonsense of the 8us spec.

This suggests that my earlier view may be right: the 8us is based on CS=1 being the shortest possible time per spec: just 50ns. With just 50ns, the internal refresh controller manages to do just one row refresh cycle per transaction, and this is the huge overriding factor in the 8us spec. As someone pointed out earlier, 8us * 8192 = 65ms which is close to a DRAM whole-device (8192 rows) refresh period. So this all hangs together now. The 8us is probably based on this simple calculation, together with the assumption that the host will be thrashing the chip solidly, with no time gaps.

In addition, the 8us spec will be based temperature-wise on the max SPI clock of 100MHz+ (I am running at 21MHz and with negligible chip self-heating) and max ambient of +85C.

Why do they cripple the spec so badly? They could say that the 8us becomes say 200us if CS=1 for 50us. But they don't; the data sheet is junk.