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

[Tesla DeLorean]

Posted on May 14, 2018 at 18:52

You'd have to look at the index you are using for the Array, each element is 4 bytes.

A 64Mb memory describes 8M bytes and 2M 32-bit words.

A Hard Fault and issue on the debug side indicates the memory space described by the FMC configuration (rows, columns, banks, width) has been exceed by application side accesses.

[T J]

Posted on May 15, 2018 at 04:27

as Clive suggested, your index must be stepping out of range, or the config of the SDRAM is not correct.

either way,

if you would like some help,

please show us the errant code

pointing to the failing instruction.

[Matt G]

Posted on May 17, 2018 at 17:41

Thanks for the replies.

It seems that the array is located within internal ram despite the __attribute__ command.

An array of 2 elements was placed in 0x20000500 just above the internal address

0x20000000 according to the debugger.

I am not sure I definitely have my RAM configured correctly so have attached my code.The f429 files are from an example with the same RAM IC, I think I only need to use the SDRAM_Set_Operation(); and have commented out the rest?

I also do a read write check which passes okay when the for loop isn'tconfigured to fill the array later on,

i.eArray[i] = i; is changed toArray[single_element] = i;

Thanks

________________

Attachments :

main.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxc4&d=%2Fa%2F0X0000000b0B%2F2pCD20PVrkxBQ.Y1G.Qe1RbrIJNytg5xn2rQOg8moUI&asPdf=false

f429i_sdram.h.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxbz&d=%2Fa%2F0X0000000b0C%2FUd3l5mKTbap0n7IzzwlQsHo3lPZknugLIFKuc.H3uyE&asPdf=false

f429i_sdram.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxc9&d=%2Fa%2F0X0000000b0D%2FxXgX6Jf8om1TpZa_QYiTkla9di5atRqr..CvADY2Nmc&asPdf=false

[Tesla DeLorean]

Posted on May 17, 2018 at 18:10

volatile int32_t Array[80001] __attribute__((at(0xD000000))); // <<< MISSING A ZERO HERE

[Matt G]

Posted on May 17, 2018 at 18:26

Ah yes I've been changing the code around a lot, that extra 0 used to be there - thanks. 

I added it back in but nothing changed. 

[Tesla DeLorean]

Posted on May 17, 2018 at 18:43

Not sure clocking at 16 MHz is appropriate. Isn't the SDRAM code/timing expecting to run the board at 180 MHz and the SDRAM memory at 90 MHz

Not much I can do with this, not a board I'm using here.

[Matt G]

Posted on May 22, 2018 at 21:00

Thanks for the reply Clive. I'm still struggling painfully with this. 

I created a new CubeMX project with 180MHz clock but this time I can't stop the program hardfaulting in the HAL_init function when the SDRAM address and size are entered into the Options-->Target menu of Keil. 

Specifically the program fails here:

Function: HAL_InitTick(TICK_INT_PRIORITY);

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)

{

/*Configure the SysTick to have interrupt in 1ms time basis*/

HAL_SYSTICK_Config(SystemCoreClock/1000U);

/*Configure the SysTick IRQ priority */

HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority, 0U);

/* Return function status */

return HAL_OK;

}

__STATIC_INLINE uint32_t SysTick_Config(uint32_t ticks)

{

if ((ticks - 1UL) > SysTick_LOAD_RELOAD_Msk)

{

return (1UL); /* Reload value impossible */

}

...

I made a few other tweaks besides the core clock so possibly the RAM will work correctly when this is solved.

Thanks

[Matt G]

Posted on May 24, 2018 at 21:23

Still stuck on this. 

:(

[Tesla DeLorean]

Posted on May 24, 2018 at 21:40

I don't have this board, and I don't have a remotely compilable project.

ZIP up a complete project, and attach that, not individual files.

Find some workable code from WaveShare.

Have WaveShare send me some boards.

[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?

[Vitaliy Chernobay]

Posted on June 05, 2018 at 00:37

Dear

Turvey.Clive.002

, please give examples of scatterfile for external memory