Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
up vote 3 down vote favorite

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?

share|improve this question
1  
Asynchronous, page or burst mode? – stevenvh Jul 10 '12 at 9:13
Asynchronous (BCR and RCR are at their default setttings). – Randomblue Jul 10 '12 at 9:14
u didn't answer my initialization answer in my suggestions – Tony Stewart Jul 20 '12 at 22:58
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). – Mark Lakata Nov 1 '12 at 0:46
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. – Randomblue Nov 1 '12 at 9:25

3 Answers

up vote 3 down vote accepted
+25

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.

share|improve this answer
up vote 1 down vote

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.

share|improve this answer
Thanks. I'll go through the timing diagram again! – Randomblue Jul 10 '12 at 21:47
up vote 1 down vote

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?

share|improve this answer
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. – Randomblue Jul 24 '12 at 16:26
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. – hli Jul 25 '12 at 13:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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