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

[peter-h]

Data sheet:
https://datasheet.lcsc.com/szlcsc/Lyontek-Inc-LY68L6400SLIT_C261881.pdf

My 32F417 SPI3 channel is limited to 21MHz due to other things (and even if I totally optimised everything else I would still be limited to 42MHz) so the various obscure limitations of this SRAM (like max ~80MHz for page crossing, the 33MHz limit for "slow mode" reading, etc) should not apply. And it means I can run the simplest (slow) SPI mode.

I've been using the Adesto SPI FLASH chips but always only using the 512 byte sector size, never doing longer writes and never doing long reads even though the data sheet suggests you could read the entire chip in one go at 21MHz. On this SRAM chip, I am confused about what the 1k page size actually means. They document a 23 bit byte count and 2^23=8 megabytes, so this is the whole device, apparently randomly accessible.

For reading, it looks like you just clock in the command and the 24 bit address (bit23=0) and it returns data from that address onwards, all the way to the end of the device, with transparent crossing of any stuff like the boundary between the two physical silicon chips:



And same for writing. Set the starting address and just keep clocking them in...



My only limitation on the sequence length is that the 32F417 DMA transfer counter is only 16 bits i.e. 64k bytes. Well, with even length blocks one could use 16 bit SPI mode and get 128k bytes in one go.

Any input appreciated as always.

[woofy]

I've not used them but I have some on the way since they were mentioned in another thread - just to play with. 
As far as I understand it, these chips are really dynamic RAMs (pseudo static ram) and the 1k page originates from the column address.
Crossing this 10 bit boundary takes a little longer, so reduced clock speed. I don't think your 21MHz clock should be impacted by this.

[hans]

I've looked at using similar devices (these pseudo-RAM chips or HyperRAM using OCTOSPI on the newer STM32s). One thing to watch out for is the micro-refresh of the DRAM. For this chip, there is an upper bound of the Chip-Select time you can perform. It's documented on page 20 of datasheet, t_CEM=8μs. For HyperRAM, the micro-refresh time is commonly 4μs. If you access the RAM for longer, the device blocks it's internal refresh operations, and therefore you may start to see DRAM fade, which is bad.

HyperRAM has a strobe signal that can introduce additional delay cycles. This RAM does not, so it also specifies a minimum of t_CPH=50ns between transfers.

For both t_CEM and t_CPH I don't see a particular exception made for command 'h03, even though the datasheet brochure-page (page 3) seems to tease otherwise ("continuous").

[DavidAlfa]

It looks like the controller supports either linear or 32Byte wrap, and the 1K boundary is just a limitation that user must implement in the code?
In linear mode, if you know you're not running >84MHz, nothing to worry about. But if you do, then you must stop the transfer when reaching the end of the page and start a new one to keep reading?
Otherwise, I don't see any hardware 1K wrap anywhere, there's just the 32B wrap, set but Boundary wrap toggle cmd (0xC0).

To me, it's like this:
Slow RD(0x03).  Max 33MHz, no dummy byte. 32Byte wrap or linear.
Fast RD(0x03).   Max 144MHz, needs dummy byte. 32Byte wrap or linear. User shouldn't cross page boundary when exceeding 84MHz.
WR (0x02). Same as Fast RD, but no dumy byte.

There's something more important you should investigate, which I 've just noticed and might cause quite decent headaches:
Device self-refresh is halted while CE is low (Check Command Termination section), tCEM (CE# low pulse width) is 8us max, so it seems you can't make any operation longer than that?
If true, with SPI@21MHz, one byte takes 381ns, so you can only transfer 21bytes in a single operation?

[peter-h]

You mean that sometimes, when your SPI access hits the internal refresh, the device generates what is basically a wait state, but since there is no way to implement this via SPI, they just re-spec the max SPI clock to cover that?

I ordered some from https://lcsc.com/ and they arrived some weeks later. Will test them soon.

I am feeding the SPI with DMA; no way to get solid 21mbps with polling, as described here
https://www.eevblog.com/forum/microcontrollers/32f417-spi-running-at-one-third-the-speed-it-should/

Gosh, Hans and DavidAlfa, well spotted the Tcem of 8us max. That obviously prevents any long block ops; at 21MHz that comes to just 21 bytes max transfer length. (posts crossed)



But, if you use it as follows:
- transfers 1-21 bytes -> no special precautions
- transfers 22-1023 bytes -> not allowed
- transfers 1024+ bytes -> allowed because the whole chip will get refreshed (by the transfer)
would that work?

Note above numbers will be a lot worse if not using DMA to feed the SPI.

How does the ESP32 implement this limitation? CE must be high every 8us to enable refresh to occur, but the spec is just 50ns.

[DavidAlfa]

Hans won by 8 seconds about tCEM

Nope, 168 bits
1/21MHz = 47.62ns/bit, *8=380.95ns/byte
8us/0.38095=21bytes...

Yes, you can saturate the SPI bus with polling by using RX-only mode (I think I already mentioned this on your other post).
The SPI peripheral will go crazy, when the Rx flag is set, the next transfer will have already started before you even read it, so you must be FAST, any interrupt will cause buffer overflow.
Also, after the required bytes are received, the spi has already send at least another extra byte clock, although the data is discarted. You must know that because it might cause some issues on your application.
This mode seems buggy and messy, I had all kind of issues when trying it.
Using a polled DMA for 21 bytes... might make sense after all, because in normal RxTx polled mode you might get about 6 bytes in those 8 us.
The DMA initialization overhead might add some time, but removing the byte delay will allow larger transfers, perhabs 18-20 bytes.
You definitely need higher SPI speed! Why the 21Mbit limit?
You can adjust the SPI clock any time, adapting it to each peripheral, ex:

Code: [Select]

void setSPI_Prescaler(uint8_t pre){
  __HAL_SPI_DISABLE(&hspi1);
  hspi1.Init.BaudRatePrescaler = pre;
  hspi1.Instance->CR1 = (hspi1.Instance->CR1 & ~(SPI_CR1_BR_Msk)) | pre;
}    // No need to enable SPI again, starting a HAL SPI transaction will do.

void foo(void){
  setSPI_Prescaler(SPI_BAUDRATEPRESCALER_2);
  send_data(fast_device);

  setSPI_Prescaler(SPI_BAUDRATEPRESCALER_256);
  send_data(slow_device);
}


[peter-h]

Yeah - I've fixed up my post

Does it make sense?

This would be tricky to test because it has been found experimentally that DRAM retains its value for a very long time (many seconds, or minutes).

To implement the 22-1023 band one would need to check for that length, and break up the transfer. One can't just pause the DMA transfer though because the required CS=1 period requires that the address is re-issued. In fact one would want to yield to RTOS in long transfers anyway.

Why the 21Mbit limit? You can adjust the SPI clock any time, adapting it to each peripheral, ex:

I already do that, but on the 32F417 one APB bus can be 84MHz and the other 42MHz, and I am using SPI3 for various peripherals, which runs off the 42MHz one, hence the 21MHz max clock. Had I rearranged things to use SPI1 (max 42MHz clock) then I would have lost one of the four UARTs I am using

Code: [Select]

static void kde_neo_m9n_write_read_byte(uint8_t out_value, uint8_t * ret_value)
{

SPI3_Lock();   // mutex

// If current SPI3 init is not this device, initialise it
if ( g_spi3_current_config != KDE_SPI_MODE_NEO_M9N )
{
KDE_spi3_set_mode(KDE_SPI_MODE_NEO_M9N);
g_spi3_current_config = KDE_SPI_MODE_NEO_M9N;
}

// These are static so DMA can be used
static uint8_t outv = 0;
static uint8_t inv = 0;

outv = out_value;

kde_neo_m9n_cs(0);
hang_around_us(NEO_M9N_GEN_WAIT);  // gap after CS=0

SPI3_DMA_TransmitReceive(&outv, &inv, 1, false, false, RTOS_YIELD);

hang_around_us(NEO_M9N_GEN_WAIT);  // gap before CS=1
kde_neo_m9n_cs(1);

SPI3_Unlock();

*ret_value = inv;

}


[DavidAlfa]

That sucks. Losing the fast pin for a slow peripheral like the UART. There's no way to send UART to a different pin?
Causing such limitation, it would be better to use something extenal with a FIFO to run the UART. Even a cheap PIC or basic STM32.
Send the data blazing fast using 84MHz SPI, then let the external device send the data to the UARTs.

[peter-h]

It is possible the 32F417 pin allocation was not done the best way but it was done 2-3 years ago when I knew nothing about the chip. It is fixed now on the PCB, and of the multiple chips I am running off SPI3, only 2 would theoretically benefit from 42MHz SPI clock: this RAM, and some TFT controller chips*, and neither of these are being currently used. The 5-6 other devices are limited to 500kHz-10MHz SPI clocks, as indeed are most SPI chips.

The Adesto SPI FLASH has SPI2 dedicated to it and that runs at 21MHz too (42MHz APB bus clock) because the UART(s) running off that APB bus would lose one of the lower baud rates which I would like to keep Actually the FLASH is very fast at 21MHz; much faster than the application requires, and writing is totally dominated by a 16ms/sector programming time.

I looked around for SPI RAMs without this limitation and found the IS66WVS2M8ALL-104NLI-TR which on a quick look is exactly the same, even down to the command codes, and with an "even better" limitation of 4us on the max CS=0 time There should be some purely static SPI RAM chips but they are all very small.

Anyway, does anyone agree with my proposal:

- transfers 1-21 bytes -> no special precautions
- transfers 22-1023 bytes -> not allowed
- transfers 1024+ bytes -> allowed because the whole chip will get refreshed (by the transfer)

If true, I would say that definitely sucks! And how does the ESP32 implement it?

( * https://www.eevblog.com/forum/projects/small-tft-display-5x5cm-for-moving-graphics-over-spi/ )

[DavidAlfa]

- transfers 1024+ bytes -> allowed because the whole chip will get refreshed (by the transfer)

I don't see anything anywhere specifying that crossing a boundary refreshes the page.
Reading 1K at 21MHz would take 48us, if you're lucky and your current page does refresh, you've potentially screwed 5 pages.
Also assuming the memory needs to refresh the current page you're addressing, which I don't think so, it probably runs an internal counter.

Anyways, is it me or modern datasheets are lacking a lot of details compared to older ones? They just tell "do this", but don't go deep into the details.

[peter-h]

I don't see anything anywhere specifying that crossing a boundary refreshes the page.

It was more like that with any DRAM I have used before (and I have used a lot of them, in a previous life) if you somehow accessed every address in the "row" then the device was refreshed for the whole period (typically 2ms back then, IIRC). And a sequential read of x locations, where x >= the row size, would guarantee that. Even the Master Bodger (Clive Sinclair) was achieving this by relying on the CRT controller reading the display data out of the dual-ported DRAM

And reading 1K at 21MHz would take 48us, if you're lucky and your current page does refresh, you've potentially screwed 5 pages.

Yes; a very good point, although "Sir Clive" would have discovered that there is actually a 100x margin on that, at room temp

is it me or modern datasheets are lacking a lot of details compared to older ones?

I agree; it is crap. But this device is clearly a functional copy of others like the ISSI ones, and the data sheets for those might be better. Actually the ISSI data sheet is also crap, being totally silent on this. But it may be a rebadged LY68L6400-family chip. Nothing on google on this topic either.

I think this chip is basically useless, for most applications, unless you accept a very slow 1 byte at a time access, or access it via some sort of hardware memory manager which does it all for you. So I looked at the RAM which Espressif sell, which is obviously a rebadged version of the ones above and with the same < 8us CE=0 requirement
https://cdn-shop.adafruit.com/product-files/4677/4677_esp-psram64_esp-psram64h_datasheet_en.pdf
but they have an interesting statement:



and probably the ESP32 does exactly that; it issues a fresh SPI command for every byte written or read, not attempting to do block transfers.

The Chinese tend to copy everything that can be copied, so it's a matter of locating the original SPI PSRAM which they have copied

[DavidAlfa]

Yes, the LY part also states that detail about CE and refreshing.

[peter-h]

Does it say that reading the 1024 consecutive bytes will refresh the device, and how long for?

In the old days one sometimes arranged an ISR to run every 2ms (or 4ms) and in that you triggered a quick read, DMA if poss, of a row of RAM addresses. Then you didn't need any refresh. That would be another approach, which would then sidestep the need to comply with the 8us max CE=0 time.

One could spread it out, and reading 1024 addresses every 4ms (4ms assumes a reasonably modern DRAM) means an SPI read every 4us. Hmmm that is quite an overhead for an ISR

[DavidAlfa]

Does it say that reading the 1024 consecutive bytes will refresh the device, and how long for?

No! You posted that picture of the datasheet about CE inhibing the dram refresh while selected, I said the Lyon datasheet also details that:

Device self-refresh is halted while CE is low (Check Command Termination section), tCEM (CE# low pulse width) is 8us max, so it seems you can't make any operation longer than that?

I know standard dram would refresh the row being read but I have no idea here.  Edit: Consumer SDRAM isn't very different, needs a refresh every 15us!
In fact I tweaked this value in my computer long time ago, almost doubling it (Edit: Checked, it's actually 3.5x times lol), never had any issue but it gained some decent bandwidth.

[hans]

The quad SPI on some of the other STM32F4s (the F446) also lacks a maximum CS period register. The OCTOSPI peripheral does have a setting for that, so you could efficiently use that peripheral with this chip. But since you already got the boards etc. that change is moot.

With 21 MHz clock and 8us of time , you can just reliably transfer 20 bytes. That's 1 command, 3 address and 16 data bytes. Effective speed 16Mbit/s. Painful? Yes. But reading EEPROM was similar back in the day. But those EEPROMs were only 64Kbit, and would transfer data with tens or hundreds of kHz..

You could perhaps contrive something together with a timer to drive CS pin high/low (incl. 50ns high), fire an IRQ with correct delay, and initiate the first 32-bits of a read/write transaction along with a DMA transfer so that the hardware can do the rest (until you receive the next interrupt). But you would also need to move in/out data for the DMA ping-pong buffers.. so that's still quite a lot of CPU work to do every 8us.
Unfortunately that SPI peripheral doesn't have a FIFO, so you may also need to wait on the first 16 bits to transfer through. Maybe you can get away with 2 sequential loads into DR (as the first 16-bits should instantly move into the shift register, leaving a space free for TXE='H'?), but I suppose that's undocumented behaviour.

Concerning the refreshing.. the memory bandwidth by doing a continuous transfer is not there I suspect. E.g. if you have a 8MB SDRAM chip with a 32ms refresh interval, then that means a refresh frequency of 31.25Hz. That's a continuous bandwidth of 250MB/s if want to do that by manually sequentially reading all data out in 1 continuous burst. You could just about do that with a 16-bit 133MHz SDRAM chip (or 66MHz DDR). But this 1-bit 21MHz chip? No way I'm afraid.
If you're doing random access transfers to each page, you might as well let the chip do it

I suspect that ESP implementation is also doing 1 or 4 byte transfers (very inefficiently), or what also wouldn't surprise me.. a complete disregard of reading datasheets. We all know how products are QA tested. It looks like that datasheet is a direct copy-paste. Probably some Shenzen OEM is baking those SPI RAM chips, and Espressif just drops them onto their designs.

How much memory do you need? Because Microchip also has SRAM SPI chips that are 1Mbit in size and go up to 20MHz. And ISSI have some that even go up to 45MHz.

[peter-h]

I did a google and indeed 64ms is the standard these days!

With 1024 rows, that is a read every 64us. Much better! One could do that with an ISR, and since one is allowed ~18 bytes, one could trigger a 18-byte DMA read of the SPI every 1152us (18x64).

But is the refresh page size 1024? We don't actually know that.

Looking at current DRAMs they seem to have 8192 rows. And calculating from the 8us max interval, and assuming the device refreshes just one row in between the 8us access slots, that indeed also translates to 8192 refreshes across 64ms.

So it seems unlikely that just reading 1024 consecutive addresses will perform a refresh. And the 1024 byte page size is something else.

And the 18-byte SPI read (21 bytes including 3 byte header) would need to be triggered every ~150us. Still very feasible in terms of CPU load, because the DMA operation would be non-blocking.

Some flags would be needed to enable real accesses to run concurrently with the refresh accesses.

And we don't actually know that this means of refresh is even possible...

Hans - good points.

The other approach is to document the API to this device as not being usable for more than 16 byte blocks. After all, the 32F4 cannot use it transparently, in the way the ESP32 does. This method is possible but very hard work:
https://www.eevblog.com/forum/microcontrollers/st-32f417-any-way-to-make-an-spi-sram-to-look-like-normal-ram/
but if somebody did put in the time to do it, it would meet the 8us requirement since no CPU instruction would transfer more than 18 bytes (probably none more than 4 bytes).

I don't currently need more RAM than the 128k+64k the 32F417 has. But if we had a lot more, then other approaches to some things might be possible. So I am looking at the 8 megabyte device. Also it is available whereas the ISSI and Microchip stuff mostly isn't.

[peter-h]

Digging around on how the ESP32 uses this SPI RAM, here
https://icircuit.net/esp-idf-using-external-ram-present-esp32-wrover-module/2395
one can see



So I was probably right in that the ESP32 sidesteps the max CS=0 = 8us issue by not doing block transfers. Even the auto context save on the stack is not allowed to go in there. So basically just normal CPU instructions.

This page
https://esp32.com/viewtopic.php?t=7158
reports a speed of 7 megabytes/sec for large data transfers where the ESP32's cache has to be flushed. But then the ESP32 runs this SPI very fast - probably around 100MHz. I reckon he was transferring 16 bit values.

[DavidAlfa]

Given the price of a esp32 s3 chip, it's not crazy to think  on using it as a spi memory, 512KB SRAM is a lot.
The stm32 sends r/w cmd, address and size, the esp configures the spi slave DMA and you're ready to go, no complex limitations...

[peter-h]

That is a cunning idea but it does concentrate the risk in the component supply.

[peter-h]

The timing situation is actually slightly worse than the above discussion because the 8us / 21MHz calculation assumes that CS is set optimally, which is hard to do. One has to do the DMA code "inline" and drop CS just before (or actually just after, if you have interrupts disabled) setting DMA to start. The end of the transfer is detectable by DMA setting the 'finished' bit (usually there is more than one of these) but that doesn't mean the SPI has finished shifting out.

On top of that, there is a dummy byte to be sent out when reading. Most SPI devices seem to have this; the Adesto SPI FLASH chips do also. Sending out this dummy byte returns a dummy byte of "something" and only subsequent reads deliver data.

OTOH I strongly suspect the 8us is BS in most applications, especially if running under an RTOS. The RAM data sheet does not give any info on how fast the refresh is actually performed (i.e. if you were to exceed the 8us, how long before the device catches up) but it would make sense for it to do it pretty fast. The evidence for this is that the CS=1 time is only 50ns min, so it is obviously a pretty quick operation.

I will put one on test when the PCB arrives and will test the margins, and report. It will be quite amusing if it cannot be actually broken, because of RTOS switching-out the task periodically

[DavidAlfa]

It's a shame that it doesn't support transfer pause or current address read, that way you wouldn't need to issue the address+dummy bytes, just pause CS for 50ns and continue.

[peter-h]

The best way is clearly to lay out the whole lot in a buffer

[ command byte ][ 3 address bytes ][ data to write ]

or

[ command byte ][ 3 address bytes ][ dummy byte ][ space for data to read ]

and use DMA to zap the whole lot in one go.

This is the code I use to detect end of transfer

Code: [Select]


        while(true)
{

// Either method below worked fine

uint16_t temp1;
//uint32_t temp2;

temp1 = DMA1_Stream3->NDTR;
if ( temp1 == 0 ) break; // transfer count = 0

//temp2 = DMA1->LISR;
//if ( (temp2 & (1<<27)) !=0 ) break; // TCIF3

}

It won't be difficult to test whether exceeding the 8us is fine if you then wait "some time". From the hardware design POV it does not make sense that going to say 10us blocks the refresh completely.

[woofy]

This is wild speculation, but:
Assuming 1024 refresh cycles are required to refresh the complete chip (based on the page size) and that it can refresh the chip in 51.2uS (1024*50nS).
Also assuming 8uS/50nS is for continuous operation, the max time allowed for a full refresh is 1024*8.05uS = 8.2mS.
So provided CE is high for 51.2uS every 8.2mS, you might be able to burst as much as required.

 

[peter-h]

I agree with your drift, although how much evidence is that this chip has 1024 rows?

It might have 1024 columns, which is not applicable to the refresh argument because, traditionally, refresh is done via RAS.

It would then have 8192 rows, which AFAICT is a lot more common for modern DRAMs, and this also conveniently aligns with the 64ms refresh time for modern DRAMS. 8ms would be going back to the 1980s, almost...

The other Q is whether refresh always takes place by reading or writing the device. On DRAMs this was always the case. Then a transfer of 8192 bytes would do the job. In some applications this is how the device will be used.

[woofy]

I agree with your drift, although how much evidence is that this chip has 1024 rows?

I based that on the need to slow to 84MHz when crossing a page boundary as I assume the extra time is needed for a column strobe.