Sure, but the context of this thread isn't so much how far one can stretch a DRAM.
It is the meaning of the data sheet; specifically what that 8us max CS=0 time relates to.
I am now testing with 64 byte packets which totally bust the 8us, but they do have generous gaps between them. This code runs in a loop
#define pkt 64
uint32_t buf[pkt/4];
uint32_t buf3[pkt/4];
debug_thread_printf("starting 2MB write");
// fill buffer with funny 32-bit numbers
for (uint32_t i=0;i<(pkt/4);i++)
{
buf3[i]=i*12345;
}
// write it into 2MB of RAM
for (uint32_t addr=0; addr<(1024*1024*2); addr+=pkt )
{
SPI_RAM_write(addr,(uint8_t*)buf3,pkt);
}
debug_thread_printf("finished 2MB write");
//spi_ram_cs(0);
//osDelay (1000); // this can be up to 2-3 secs before it breaks
//spi_ram_cs(1);
debug_thread_printf("starting 2MB read");
// read it back
for (uint32_t addr=0; addr<(1024*1024*2); addr+=pkt )
{
SPI_RAM_read(addr,(uint8_t*)bufc,pkt);
bool diff=false;
for (uint32_t j=0;j<(pkt/4);j++)
{
if (bufc[j]!=buf3[j]) diff=true;
}
if (diff)
{
debug_thread_printf("failed at addr=%lu",addr);
}
}
debug_thread_printf("finished 2MB read");
At 21MHz SPI clock and 16 byte packets it is reading or writing the 2MB in about 2 seconds, due to lack of optimisation. With larger packets it does the full 2MB/sec.
Runs fine too with 16384 byte packets. Any more, my target runs out of RAM. So clearly one or both of these is happening
- there is enough CS=1 time to enable refresh even though the 8us max CS=0 spec is massively busted
- consecutive accesses of 1024 or 8192 (nobody seems to be sure) locations performs the refresh (like would happen on any DRAM)
Interestingly, with a 5 second CS=0 wait between the fill and the readback, it fails every time and fails at a consistent address: 1073152 decimal, which is 1024x1048.
Finally, it is not clear what the use of the software reset command is, but it doesn't seem to do any harm.
This different PSRAM variant, reports an on die temperature sense, that can signal when it can be relaxed on refresh. (seems just a single bit )
https://www.mouser.com/ProductDetail/AP-Memory/APS12808L-3OBM-BA?qs=IS%252B4QmGtzzrXcGkbuYahqw%3D%3D
It also mentions reduced refresh coverage, but they seem to trade that for lower power, rather than extended refresh gateways.
Interesting chip, especially for 3 quid... It still has that weird min CS=0 spec, this time 4us, and they don't explain why. That makes it useless for any long burst operations, of course.
I then moved on to temperature tests and got some interesting results.
With 512 byte packets (CS=0 for 200us) it started to produce errors at +90C.
With 16 byte packets (CS=0 for 11us) I got no errors ever, and I tested it right up to +100C.
The above was without the very long CS=0 period between filling it and reading it out. During this period, the device should not be refreshing at all, and temperature dependent failures are expected:
With 512 byte packets and a 1000ms block on refresh, it started to produce errors at +50C.
With 512 byte packets and a 100ms block on refresh, it started to product errors at +70C.
The above is a totally unrealistic test because nobody will be deliberately blocking refresh by holding CS=0.
CS=1 for about 8us in all cases. That is probably important because clearly the chip starts the internal refresh as soon as it sees CS=1, and with the min CS=1 spec of just 50ns it must be pretty quick about it. It is reasonable to assume that the 50ns gives it time for just one refresh and as above debate shows, that adds up to some kind of normal DRAM refresh rate.
The fact that there is a measurable temperature dependency of the errors between CS=0 for 11us and 200us suggests that while the chip manages to squeeze in
the initiation of a refresh in the 50ns CS=1 gap, it doesn't do the refresh cycles all that fast afterwards. I reckon it does them at a rate of about (order of magnitude) 1 every 1us.
Next I tested the hypothesis that reading more than 8192 (or 1024) consecutive locations does a full refresh. A test with a packet size of 8192 (CS=0 for 3ms) produces errors at around +70C. This is slightly worse than the 512-byte packet situation where it starts to fail at +90C. This is with a CS=1 time of around 8us as previously. Increasing the 8us to 100us does not change the +70C temperature, which is also interesting because it suggests that the chip is not grabbing that extra opportunity to squeeze in enough refresh cycles.
Or maybe the temperature issue is not refresh related after all?No matter how you shake it, the 8us number seems extremely conservative. Or maybe they are working on a really high chip temperature, produced by the maximum clock rates of 144MHz at a Tamb of +85C. In my product, running the RAM test all the time, the delta-T of the chip, relative to the PCB, is under 1K (1C).
Home
Help
Search
Login
Register
