STM32F429 & SDRAM

[Matt G_2]

Posted on May 14, 2018 at 17:45

Hi,

I have been working with a Waveshare Core 429I board, essentially an STM32F429IGT6 & IS42S16400J and Keil.

I am trying to store a large array in the SDRAM using the int32_t Array[xxxxx] __attribute__((at(0xD000000))); command, and have FMC and SDRAM functions initiated first.

I can declare a very large array okay and write to individual elements fine, but when I try to fill it using a for loop the program hard faults and 'Cannot access Memory' is displayed. I don't think the for loop requires the array to be in the heap?

I have done lots of reading, I believe there is no reason to need a scatter file, increase the heap size or call the ram functions in the Systeminit routine when using SDRAM in main?  I am a complete novice with Keil and my C experience is fairly limited. 

Thanks

[Matt G]

Posted on June 01, 2018 at 20:45

Hi Clive,

I've got my hands on a 32f429I-Discovery board but still having problems.

I've attached the entire project, you will see what I'm trying to achieve is quite simple so something is probably incorrectly configured.

I have not used a scatter file but entered the external RAM address and size into target options.

Thanks again

________________ Attachments : DISCO.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxXn&d=%2Fa%2F0X0000000azf%2FAXsjRHHgirof6qt77eVCO3.dnw2sNzkamP1Zc9u3ttA&asPdf=false

[Tesla DeLorean]

Posted on June 02, 2018 at 15:12

STM32F429I-DISCO

Core=180000000, 180 MHz

CPUID 410FC241 DEVID 419 REVID 1003 Cortex M4 r0p1 STM32F429 or F439 C0000000 00000000 00000000 10110021 11000011 00000000 FPU-S Single-precision only APB1=45000000 APB2=90000000 RAM OK 80000 50000 1000 ________________ Attachments : DISCO-002.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxXZ&d=%2Fa%2F0X0000000azd%2FaZF3._rWULhTbBU86zvLyXQwytrkAS_j27rHoCefojQ&asPdf=false

[Matt G]

Posted on June 04, 2018 at 15:01

Hi Clive,

Thank you so much for the resolution.

So it would seem the default Keil compiler is not working with the __attribute__at command for static allocation, with dynamic allocation the correct D0000000 addresss shows in the debugger.

The address location in the debugger is the same with or without the __attribute__at, I have checked the documentation and it should work fine with a non GNU compiler. 

Is there a way to resolve this without dynamic allocation using the __attribute__at command, as I intend on having multiple 2D arrays within SDRAM?

Static allocation would be much simpler.

Many thanks

[Tesla DeLorean]

Posted on June 04, 2018 at 16:08

I don't like AT for many reasons. Why does this stuff need to be at absolute addresses? Can't you use the scatter file to direct the linker to place specific variables in SDRAM? can't you define a structure where you place all your SDRAM buffers, mange the placement/ordering in there, and set the pointer to the base of the SDRAM?

[Tesla DeLorean]

Posted on June 04, 2018 at 16:17

Try not defining the Array inside the scope of a function, ie do it globally, the code exploded because it made a large stack allocation.

[Vitaliy Chernobay]

Posted on June 05, 2018 at 00:37

Dear

Turvey.Clive.002

, please give examples of scatterfile for external memory

[Tesla DeLorean]

Posted on June 05, 2018 at 01:54

Try some of these

https://community.st.com/0D50X00009XkgpJSAR

 

https://community.st.com/0D70X000006SIA5SAO

 

I'll fish some more, and try and fix the DEAD LINKs

[Tesla DeLorean]

Posted on June 05, 2018 at 02:53

Here stuffing memory into the Keil allocator

 

[Matt G]

Posted on June 07, 2018 at 18:57

Clive, thank you so much, this is exactly what I needed to resolve.

Everything is working fine, I had no idea a large external array declaration would overflow the stack. 

[Tesla DeLorean]

Posted on June 07, 2018 at 19:19

>> I had no idea a large external array declaration would overflow the stack. 

From static analysis I didn't either, but the debugger kept exploding. Having an auto variable with an AT directive apparently is an issue, not a form I've every tried, but I'll remember it now.

&sharpTheElephantInTheRoom