STM32F746G-Discovery SDRAM Curious Behavior

[Scott Gravenhorst]

Posted on March 16, 2018 at 19:50

I'm writing a crude memory diagnostic for SDRAM (just to see if I can). The code accesses SDRAM using a pointer.

__IO uint32_t * SDRAM_ptr;

SDRAM_ptr = (__IO uint32_t *)0xC0000000;

Using this pointer in a loop, I can write and read the first 2 megabytes reliably, but more than 2 megabytes causes the program to hang (sits and does nothing after the SDRAM read starts). I assumed that the program would fail beyond 0xC0800000, but its failing when beyond 0xC0200000.

The LCD display is not enabled.

CPU clock is set to 200 MHz.

Initialization was done with HAL and BSP functions.

Another curious behavior is that if I set the diagnostic to test 2 megabytes (0x00200000), I can set SDRAM_ptr to any of 0xC0000000, 0xC0000004 and 0xC0000008 as a starting point and the diagnostic works meaning that at least 8 bytes beyond 0xC0200000 seem to be accessible. If I set to 0xC0000010, it fails. The program writes data values starting at 0x00000000 and incrementing by 4 for each uint32_t location. Yet if I set the length of SDRAM to test to 0x00200004, it fails.

Any clues about what I'm doing wrong?

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean · Accepted solution]

Posted on March 16, 2018 at 20:30

The system will Hard Fault if you go beyond the geometry decoded by the FMC

I tend to have the handler print out diagnostics so I know that it got there.

The uint32_t point will advance 4 bytes at a time, 128-Mbit SDRAM (64 Mbits accessible), so 8MB, 0x200000 loop iterations at 32-bit

[Scott Gravenhorst]

Posted on March 16, 2018 at 20:45

OH!  So the address used is pointing to 32 bit values, not 8 bit bytes.  0xC0000000 is the first 32 bit chunk and 0xC0000001 is the second.

Thank you SO much, it is working now and I understand.

Can't believe I didn't see that.  I know how that is supposed to work...  duh moment.

[Tesla DeLorean]

Posted on March 16, 2018 at 22:20

Should advance 0xC0000000, 0xC0000004 as SDRAM_ptr++

[Scott Gravenhorst]

Posted on March 16, 2018 at 22:51

Yeah, basic C programming (sheesh, been doing C for 40+ years).  I was using the pointer as a constant and adding a variable i to it where i+=4.  Once I changed to i++, it worked fine (obviously).  Still can't believe I missed it.  I was still confused when I made my first reply and wrongly said that 0xC0000000 was first uint32_t and 0xC0000001 was the second.  I was confused (ok, it was 05:00 when I started writing the code, no coffee yet).  So the raw untyped addresses do point to bytes and to access uint32_t the raw address indeed needs to be bumped by 4 (which happens automatically when using the uint32_t pointer I described with a ++ or by adding one to it).  Just totally forgot that pointers are element selectors, not necessarily byte selectors.

[Tesla DeLorean]

Posted on March 16, 2018 at 23:51

Absent the whole source I was trying to hazard a guess a what would explain the conditions described.

And that ST throws away half the memory...

If it got beyond the initial response I would have gone a checked the memory on the F746G-DISCO here. As it as I have one on the bench coding a replacement External Loader for the N25Q128A on the ST-LINK Utilities. ST doesn't provide the source as it uses an SPL version, and of course that's some mythical thing that doesn't exist. So now I've built one using HAL on Keil, in initial testing is seems to be working.

[Scott Gravenhorst]

Posted on March 17, 2018 at 00:28

Indeed the half-of-the-SDRAM thing was confusing.  Today I found in BSP/stm32746g_discovery_sdram.h there is

&sharpdefine SDRAM_MEMORY_WIDTH   FMC_SDRAM_MEM_BUS_WIDTH_16

which makes sense.  There's nothing special I need to do to get full 32bits on every location, I use it like I'd use a pointer into allocated SRAM.  Very happy I don't have to deal width 16 bit holes in the SDRAM.

I've replaced the SDRAM diagnostic with a random data test.  Works as expected, no errors.

[T J]

Posted on March 18, 2018 at 00:16

I would like to understand what you mean when you said;  ' ST throws away half the memory '

On my board I have 2 SDRAM chips of 32M x16bits each,

being a total of 128MBytes using the whole data bus at 32bits wide.

I am expecting to see 32M x32bits...

[Tesla DeLorean]

Posted on March 18, 2018 at 00:25

They use a 32-bit wide SDRAM device, but only have a 16-bit data bus to save pins, half the memory is inaccessible and unused.

See wording on boards home page '128-Mbit SDRAM (64 Mbits accessible)'

http://www.st.com/en/evaluation-tools/32f746gdiscovery.html

 

[T J]

Posted on March 18, 2018 at 00:28

Is that on a specific board ?

________________ Attachments : image001.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxsm&d=%2Fa%2F0X0000000b1q%2FF0VsygHJZDQntbzX5z0QqByO3205vWR42HsyRKKHlBU&asPdf=falseimage002.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxsq&d=%2Fa%2F0X0000000b1p%2FDGKQq8UoOlyrrqs_H6w0EPRBl5A70lJmltuFrW6.T6E&asPdf=false