I have a PSRAM driven by an STM32F2 in the default asynchronous mode. The PSRAM works fine except for the very first read or write operation.

After the first read or write operation (which produces bugus results), all the read/write operations behave as expected. The address of the first read or write operation does not change things.

I have tried inserting a one second delay between the SRAM initialisation and the first read or write operation, but that did not help.

What could I be causing this problem?

  • 1
    \$\begingroup\$ Asynchronous, page or burst mode? \$\endgroup\$
    – stevenvh
    Commented Jul 10, 2012 at 9:13
  • \$\begingroup\$ Asynchronous (BCR and RCR are at their default setttings). \$\endgroup\$
    – Randomblue
    Commented Jul 10, 2012 at 9:14
  • \$\begingroup\$ u didn't answer my initialization answer in my suggestions \$\endgroup\$ Commented Jul 20, 2012 at 22:58
  • \$\begingroup\$ Have you solved your problem? I noticed (from another post) that you are using the same Micron PSRAM I am using, and I have a similar but opposite problem. Memory accesses work fine in my test routines, but occassionally (but 100% repeatably) I read bogus data from the PSRAM. For example, a particular load works fine the first 2 times, but fails the 3 rd time (at the same address, with the same data). \$\endgroup\$ Commented Nov 1, 2012 at 0:46
  • \$\begingroup\$ No, I never figured that one out, but there was an easy workaround for me. Memories are delicate creatures, and operating them in a slightly wrong fashion can lead to subtle bugs. I would triple check the timing diagrams, and try various settings. \$\endgroup\$
    – Randomblue
    Commented Nov 1, 2012 at 9:25

3 Answers 3


When working with external chips I've seen this issue before because the default I/O state of the microcontroller. For example, microcontroller X boots up with all I/O in a High-Z Input state. Then my code goes through, sequentially, with the initialization routine and does something like disable the pull-up, then change the I/O pin to an output, then set the default (nominal) state of the pin (this isn't the recommended algorithm, but follow me here). What that does to any parts connected to the chip is possibly clock 1 data bit (or more) into the chip because of the high->low->high procession of the I/O pin. This can range from being completely innocuous all the way up to corrupting your first transaction (as the chip is left with 1/8th of an instruction). Usually the chip cleans itself up after your 1st read/write because the internal state machine can clear things up once you pull your CE# pin high and you can go on reading/writing with ease. I would scope those pins and see what your chips is actually seeing on boot. I suspect that you'll find that it's working "perfectly" based on the inputs it's getting. If you find this is the problem, you can force boot-states on critical pins by using pull-up/down resistors accordingly to make sure this doesn't happen. Well written firmware (in the initialization routine for your peripheral) should get the IC into a known and robust state.


This is a medium-to-long shot, but I had a similar problem...12 years ago. But it was an ST processor, so, why not?

I had mis-programmed the timing registers (misunderstood the data sheet), and as a result, I had one of the write pulse times set longer than the entire time for write cycle--something like that; I don't remember the exact registers. Rather than pushing the write times out to the longest setting, instead it dropped the part where the line returned high! In effect, on the scope, the line in question was sitting low, and it would go high during some other part of the write cycle, and when it returned low, the write would happen. As I recall, it wasn't even that obvious when watching on the 'scope. But I do remember that behavior where most of the writes would work, but it would drop the first one. And as you say, slowing things down didn't help.


The power-up initialization specs are TPU >= 150uS, after Vcc >=1.7V

  1. VCC and VCCQ must be applied simultaneously.
  2. During the initialization period, CE# should remain HIGH.
  3. When initialization is complete, the device is ready for normal operation.

Did you confirm these?

  • \$\begingroup\$ The power supplies are applied simultaneously. However, right when I configure the CE# pin as a memory pin, the ARM pulses it low. Maybe that's the problem. \$\endgroup\$
    – Randomblue
    Commented Jul 24, 2012 at 16:26
  • \$\begingroup\$ Since the CE# pin should stay high for 150µs after the power has been applied, maybe it helps to delay the initialization of the pins? That way, if the pulse on CE# happens, it might not disturb the PSRAM. \$\endgroup\$
    – hli
    Commented Jul 25, 2012 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.