Can I read a variable from SDRAM almost as fast as from internal RAM?

[misterstarshine]

Posted on March 29, 2017 at 20:27

Hi.

I'm using the STM32F746G-Discovery board which has an external 8MByte SDRAM. I've made tests to read the SDRAM by testing to access it by declaring:

   float *testvar = (float*)0xC0000000;

   *testvar = 3.4f;

   displayfloat(*testvar);

In my experiments it appears as if the reading that variable is about half the speed as if it was declared in the internal RAM. Is it possible to tweak the clock to the SDRAM to get performance comparable to the internal RAM?

Also is there an attribute command to tell the compiler to place a specific variable or vector in the SDRAM without having to specify the address manually?

[Tesla DeLorean]

Posted on March 29, 2017 at 20:58

>>

Is it possible to tweak the clock to the SDRAM to get performance comparable to the internal RAM?

No, but the cache might mask that.

>>

Also is there an attribute command to tell the compiler to place a specific variable or vector in the SDRAM without having to specify the address manually?

Named regions in the linker script/scatter file.

[Tesla DeLorean]

Posted on March 29, 2017 at 21:03

uint32_t  BigAssArray[100000]  __attribute__ ((section('.sdram'))); // With a suitably large load region described to the linker

[misterstarshine]

Posted on March 30, 2017 at 18:35

Thanks Clive.

I'm now able to declare arrays in the SDRAM region however the reliability is rather poor. I'm having issues with read and write errors when the array is declared in the SDRAM instead of the on-chip internal RAM. Could this be poor clock settings for the SDRAM or read/write collisions with the touchscreen that also uses the same SDRAM for the graphics buffer?

[Tesla DeLorean]

Posted on March 30, 2017 at 19:29

Collisions should not cause failures on the CPU side, access is serialized, and the bandwidth available to a single user is reduced, to accommodate both. It's like rush hour traffic, you get to your destination slower, it doesn't break the road.