Skip to main content
franck23
franck23
Associate III
May 31, 2019
Question

Do I need to modify the linker for simple SDRAM read/write operation?

  • May 31, 2019
  • 4 replies
  • 857 views

Hi,

I am using the STM32F746G-Disco board with SW4STM32 IDE and I have the SDRAM working on it.

Now I am trying to port this project to the STM32CUBE IDE using the integrated STM32Cube.

However, when I try to read the SDRAM, I end up in the hard fault handler:

Hard fault: Bus, memory management or usage fault

Bus fault: Precise data access violation

Bus fault address: 0xc0000000

Writing to the same address doesn't trigger the hard fault.

uint32_t *pSdramAddress;
uint32_t u32;
pSdramAddress = (uint32_t*)0xC0000000;
*pSdramAddress = 12;
*pSdramAddress = 13;
u32 = 0;
u32 = *pSdramAddress;

I first thought it would be a linker problem, but looking at the SW4STM32 IDE LinkerScript.ld, I don't see any mention of the SDRAM address or size.

Would the SDRAM address be declared somewhere else?

I did double check the FMC configuration, comparing it with the one on this page: https://community.st.com/s/article/FAQ-STM32F746G-Discovery-Create-a-basic-Graphical-Application-using-CubeMX

So I don't think the problem would be there.

Thanks for any help.

This topic has been closed for replies.

4 replies

Tesla DeLorean
Tesla DeLorean
Guru
May 31, 2019

Hard Fault suggests you're not configuring the hardware properly, or prior to use.​

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
franck23
franck23Author
Associate III
May 31, 2019

OK, so you don't think it is a linker problem (I did not modify the linker, just not sure if I should!).

On the configuration side, I don't see what is missing :(.

I have MX_GPIO_Init() and MX_FMC_Init() called before.

I compared what is done in the FMC init to my old project and they are identical.

The GPIO_Init enables all the CPU port clock.

I don't see any other FMC function to call before using the SDRAM.

I also call HAL_SDRAM_GetState and get a ready state.

If I comment the portion of code that trigger the hard fault, I get my blinky working. So I guess clock settings are fine.

Tesla DeLorean
Tesla DeLorean
Guru
May 31, 2019

The linker script plays no specific role in the device hard faulting. It tells the linker where it can put things.

Your startup.s might if you start copying or writing to the SDRAM memory space prior to the pins, peripheral and chip being initialized properly.

If you're using HAL/MX the initialization is happening far too late. The ARM/CMSIS methodology is to get this done in SystemInit() without a huge mess of dependencies.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
franck23
franck23Author
Associate III
June 1, 2019

Thanks for pointing me to the right direction.

As Clive suggested, the problem had nothing to do with the linker but was a matter of when the SDRAM chip initialization commands are sent.

I had the SDRAM initialization commands inside the HAL_SDRAM_MspInit.

However, the HAL_SDRAM_MspInit is called before FMC_SDRAM_Init.

CubeMX doesn't implement a user code area after the FMC_SDRAM_Init or at the end of the HAL_SDRAM_Init (which would make even more sense).

As a result, the SDRAM initialization commands and the setting of the refresh rate must be called in the main.c after MX_FMC_Init():

main.c:
...
 
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_FMC_Init();	// Init FMC and SDRAM GPIO
 /* USER CODE BEGIN 2 */
 SDRAM_Init();		// Send SDRAM init commands and set refresh rate
 /* USER CODE END 2 */
 
...

Terms & ConditionsAccessibility statement