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=falsef429i_sdram.h.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxbz&d=%2Fa%2F0X0000000b0C%2FUd3l5mKTbap0n7IzzwlQsHo3lPZknugLIFKuc.H3uyE&asPdf=falsef429i_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

[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:10

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

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