[STM32H730ZBT] FMC external SDRAM loses every second byte

[sebxx4]

Continuation of this thread.

Hello, 

I've wired SDRAM (AS4C4M16SA-5TCN)  with STM32H730ZBT. Connection works, I can read/write data, but every other byte. 

Let's start with array declaration:

uint8_t *externalRAM = (uint8_t*)0xC0000000;
/* USER CODE END PV */

Then I'm trying to write some bytes to this array, ie:

externalRAM[0] = 0xAA;
externalRAM[1] = 0xAA;
externalRAM[2] = 0xAA;
externalRAM[3] = 0xAA;

  And to read it:

uint8_t test[4];
test[0] = externalRAM[0];
test[1] = externalRAM[1];
test[2] = externalRAM[2];
test[3] = externalRAM[3];

And this is the result:

Sometimes test[1] has 0xAA too, but mostly it's 0. I've tried to lower FMC frequency or change memory timings. What does this look like?

[mƎALLEm]

Hello,

I'm not expert of SDRAM interface but probably it's a timing configuration issue of the SDRAM memory.

I may suggest to read this article on How to set up the FMC peripheral to interface with the SDRAM IS42S16800F-6BLI from ISSI it could be helpfull.

[sebxx4]

Well, I calculated these parameters using this article. 

[sebxx4]

Maybe you Sir, @Tesla DeLorean could help?

EDIT:

When I do something like this:

*(__IO uint8_t*) 0xC0000000 = 0x01;
*(__IO uint8_t*) 0xC0000001 = 0x02;
*(__IO uint8_t*) 0xC0000002 = 0x03;
*(__IO uint8_t*) 0xC0000003 = 0x04;

uint8_t test[4];
test[0] = *(__IO uint8_t*) 0xC0000000;
test[1] = *(__IO uint8_t*) 0xC0000001;
test[2] = *(__IO uint8_t*) 0xC0000002;
test[3] = *(__IO uint8_t*) 0xC0000003;

It works fine:

It looks like some configuration problem. I have "16-bit byte enabled" option enabled, btw.

[mƎALLEm]

Did you connect FMC_NBLx lines to SDRAM LDQM and UDQM pins?

If not I suspect you have the same issue described in this user’s thread.

So try to configure the SDRAM memory region as Device or Strongly-Ordered

[sebxx4]

Yes, I have both NBL lines connected.

[sebxx4]

Well, I don't know exactly what I did, but now it works.
I've resoldered NBL pins at uC side and memory side. I changed array declaration too:

volatile uint16_t* sdram = (volatile uint16_t *)SDRAM_BASE_ADDR;

And now it works fine, I can read/write 16-bit variables simply by: 

sdram[x] = x & 0xFFFF;

[mƎALLEm]

Hello,

What do you mean by "I've resoldered NBL pins at uC side and memory side."? incorrect GPIO config for NBL? or what?

[sebxx4]

No, just make sure pins are soldered good ;) Maybe there was to little soldering tin.

Btw, I've just tested time needed to wrote whole memory and it's about 1800ms (per 4194304 writes), its about 433us per one write. Is it normal? I mean, I expected this memory to be faster. I want to use it to store audio data, so I have only ~22us per one sample to process it :\

[sebxx4]

I could do this, but it's important to me to store whole 16 bits at once (it's faster than sending 2x 8 bits).
Why do you want me to check it?

Btw, how to configure SDRAM memory space as device or strongly-ordered? I don't see such option in MPU config.

And how about my question about read/write time? I've checked memory clock and it's about 91.7MHz, as expected.

[mƎALLEm]

---

@sebxx4 wrote:

I could do this, but it's important to me to store whole 16 bits at once (it's faster than sending 2x 8 bits).
Why do you want me to check it?

We want to understand the root cause of the problem.

---

@sebxx4 wrote:

Btw, how to configure SDRAM memory space as device or strongly-ordered? I don't see such option in MPU config.

---

You need to set it as not cacheable/not bufferable/ Sharable with TEX level set to 0:

 

---

@sebxx4 wrote:

And how about my question about read/write time? I've checked memory clock and it's about 91.7MHz, as expected.

---

I can't answer that question. I'm not SDRAM interface expert.

[sebxx4]

Well, I would prefer to avoid desoldering the circuit again, but I uploaded the previous code and the problem does not occur, so it looks like the cause was a missing connection of one of the NBL signals.

If you can't help me with SDRAM performance, maybe do you know who can I ask?

[mƎALLEm]

---

@sebxx4 wrote:

but I uploaded the previous code and the problem does not occur, so it looks like the cause was a missing connection of one of the NBL signals.

---

In that case, that's the issue what I was talking about from the beginning.

So need to close this thread by accepting this post:

 

And open a new one for the SDRAM timing. We need to separate issues in this community.

PS: unfortunately I don't have a contact to help you with the SDRAM timings.

[sebxx4]

Well, I think I managed the performance by enabling Dcache.