STM32F769I-DISC1 only 64Mb accessible?

[FGeig.1]

Hi everyone!

I'm new to the forum so please let me know if I should add more information, etc..

I am using the external SDRAM (MT48LC4M32B2B5-6A, 128Mb) on the STM32F769I-DISC1 board. The SDRAM was configured with CubeMX to use all four memory banks. Everything works fine if I access memory regions from 0xC0000000 to 0xC0800000 (corresponding to 64Mb). If I try to access memory locations beyond 0xC0800000 the MCU ends up in the Hardfault handler.

Has someone else experienced this issue?

What is the easiest way to check if the SDRAM was correctly set up to use 4 memory banks?

Thanks for your help!

[Tesla DeLorean]

As I recall they only wired half the data pins, to save pins, while getting a part footprint and price that suited them.​

[FGeig.1]

Thanks for your answer clive1!

That's the first thing I checked and it seems that with other boards that have only half the pins wired up it says "128Mb (64Mb accessible)" in the board description, which is not the case for the STM32F769I-DISC1. Also, when checking the schematic for the discovery board it looks like all 32 data pins are actually wired to the MCU.

I don't know if there could be a difference between STM32F769I-DISC1 and STM32F769I-DISC0 (the latter having all 32 data pins wired while the first one doesn't) but there is only one documentation as far as I can tell.

[Tesla DeLorean]

Working from memory.

​

So if it hard faults need to review programmed geometry. Banks, address lines (row, columns), banks and bus width.​

[FGeig.1]

Sorry for wasting your time, the problem was indeed with the 16 bit values, if I write 32 bit values I can use all 128Mb.

So in order to write 128Mb of 16 bit values I will need to use a bus width of 32 and pack two 16 bit values into one 32 bit variable that can then be written to the SDRAM?

[Gregory3]

Hi!

I'm facing the same problem with the memory access above 0xC080 0000:

https://community.st.com/s/question/0D53W00000NCIBNSA5/stm32f767-and-external-sdram-addressing-issue?t=1604783685617

The difference is, that I'm already using a 32bit variables to write and read from the SDRAM.

uint32_t RxBuffer[SDRAM_TEST_BUFFER_SIZE], TxBuffer[SDRAM_TEST_BUFFER_SIZE];

Do you have any hints what I can still check?

Regards,

Gregor

[FGeig.1]

Hi Gregor!

Your configuration looks correct, does everything work as expected if you fill up the SDRAM up to 0xC080 0000?

Is everything behaving identical if you configure the SDRAM to only use 2 memory banks? Is there a way you can check if the pin for configuring the 4 memory banks is actually set?

Regards

[Gregory3]

Hi FGeig.1 !

Yes, when I write data into the SDRAM, read out and compare, then I get a 1:1 match.

After attempt to write above 0xC080 0000 I get a HW fault.

Now I have tried to reduce the configuration to 2 banks and the result is the same:

 

When do this, then the BA1 pin (PG5) is deconfigured in the pin overview:

 

In the configuration of the fmc.c I can see the bank pins:

 /* GPIO_InitStruct */
 GPIO_InitStruct.Pin = GPIO_PIN_15|GPIO_PIN_8|GPIO_PIN_1|GPIO_PIN_0
 |GPIO_PIN_5|GPIO_PIN_4;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF12_FMC;
 
 HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

However in the STM32F767NIHX_RAM.ld file I can't see any SDRAM section:

/* Entry Point */
ENTRY(Reset_Handler)
 
/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);	/* end of "RAM" Ram type memory */
 
_Min_Heap_Size = 0x200;	/* required amount of heap */
_Min_Stack_Size = 0x400;	/* required amount of stack */
 
/* Memories definition */
MEMORY
{
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 512K
 FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
}

Is this ok? How the controller is allocating the memory and where?

Regards,

Gregor

[FGeig.1]

I think this is fine, all the memory allocation is taken care of by the FMC and it clearly works for 2 out of 4 memory banks.

Do you happen to have a second board you can use for testing?

Is there a way to check the connection between SDRAM and MCU on the physical board?

I'm sorry I can't give you any better hints...

[Gregory3]

So I did some tests with the PG5 pin (BA1).

If I declare it as a GPIO and set to High/Low, then it responds correctly, i.e. will set to 3.3V or 0V. this means that there is no short circuit on the board.

If the connection between the CPU and SDRAM on that line is ok, I can't tell, because both of the devices are in BGA package and I don't have and access to the pins/vias on the board (buried vias).

I will ask for another HW to try this out (to exclude a PCB issue), but I still think that this has something to do with a wrong initialization...

"I'm sorry I can't give you any better hints..."

Thank you anyway for your help. I really appreciate it =)

Regards,

Gregor

[FGeig.1]

Yeah, wrong initialization seems more probable than the specific trace for enabling 4 memory banks being bad...

Maybe you can compare your code to the STM32 example code for an external SDRAM and see if you find any differences.

[Gregory3]

I was trying these methods to fix it:

https://www.keil.com/support/docs/3777.htm

Methods 1 and 2 are not working.

Do you know how to enable this option from the 3. method?

[FGeig.1]

There should be a field to set compiler options when you are using an IDE but I have mostly used Makefiles to build stuff.

[Gregory3]

Ok, so I was able to add thie option to the compiler in the STM32 IDE.

It's described in here:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjKsYzfxPbsAhXJAGMBHb7pAokQFjAAegQIARAC&url=https%3A%2F%2Fwww.st.com%2Fen%2Fdevelopment-tools%2Fstm32cubeide.html&usg=AOvVaw17XOKEGK4FjDzWT8PhSQf4

The actual command is the: " -mno-unaligned-access"

But, this also didn't worked...

Now I will dig deeper into the example codes for some clues while in the mean time the second HW is on the way to me (just to make sure, that this is not a pure accident and the BA1 line is not correctly soldered).

Regards,

Gregor

[Gregory3]

So I received another HW to check it and the issue remains the same...

My last chance is to seek for the initialization issue and compare it to the example codes.

Regards,

Gregor

[Gregory3]

Problem solved!

Like always it was a stupid error. In the BSP library I have used (modified BSP "stm32746g_discovery_sdram.h") is a definition of the memory size and bus width.

This needs to be adapted to the right size (0xC100 0000) and to the right bus width I'm using (32 Bit):

/* Includes ------------------------------------------------------------------*/
#include "stm32f7xx_hal.h"
 
/**
 * @brief SDRAM status structure definition
 */
#define SDRAM_OK ((uint8_t)0x00)
#define SDRAM_ERROR ((uint8_t)0x01)
 
 
#define SDRAM_DEVICE_ADDR ((uint32_t)0xC0000000)
#define SDRAM_DEVICE_SIZE ((uint32_t)0x1000000) /* SDRAM device size in MBytes */
 
/* #define SDRAM_MEMORY_WIDTH FMC_SDRAM_MEM_BUS_WIDTH_8 */
//#define SDRAM_MEMORY_WIDTH FMC_SDRAM_MEM_BUS_WIDTH_16
#define SDRAM_MEMORY_WIDTH FMC_SDRAM_MEM_BUS_WIDTH_32
 
#define SDCLOCK_PERIOD FMC_SDRAM_CLOCK_PERIOD_2
/* #define SDCLOCK_PERIOD FMC_SDRAM_CLOCK_PERIOD_3 */
 
#define REFRESH_COUNT ((uint32_t)0x0603) /* SDRAM refresh counter (100Mhz SD clock) */
 
#define SDRAM_TIMEOUT ((uint32_t)0xFFFF)

After that all works like it supose to do :)

Thank you anyway for all the help!

Regards,

Gregor

[FGeig.1]

Nicely done!

Mistakes are never stupid if you learn from them :D

Good luck with your other projects!

Regards