Skip to main content
Explorer
October 22, 2024
Solved

STM32H747 SDRAM with FMC - Offset in Address

  • October 22, 2024
  • 1 reply
  • 950 views

I have designed a custom board using STM32H747 with external SDRAM (IS42S32800J) via FMC, copying a lot of the design from the STM32H747I-DISCO eval board. I am currently bringing up the board and testing each component before I implement a TouchGFX UI via MIPI.

I am initialising the SDRAM as bank 2 as follows

 

void FMC_Init(){
	FMC_SDRAM_CommandTypeDef Command;
	HAL_StatusTypeDef status;

	Command.CommandMode				= FMC_SDRAM_CMD_CLK_ENABLE;
	Command.CommandTarget			= FMC_SDRAM_CMD_TARGET_BANK2;
	Command.AutoRefreshNumber		=1;
	Command.ModeRegisterDefinition 	=0;
	status = HAL_SDRAM_SendCommand(&hsdram1, &Command, 0xfff);
	HAL_Delay(1);

	Command.CommandMode				=FMC_SDRAM_CMD_PALL;
	status = HAL_SDRAM_SendCommand(&hsdram1, &Command, 0xfff);

	Command.CommandMode				=FMC_SDRAM_CMD_AUTOREFRESH_MODE;
	Command.AutoRefreshNumber		=2;
	status = HAL_SDRAM_SendCommand(&hsdram1, &Command, 0xfff);

	Command.CommandMode				=FMC_SDRAM_CMD_LOAD_MODE;
	Command.ModeRegisterDefinition = (uint32_t)0 | 0<<3| 2<<4|0<<7|1<<9;
	status = HAL_SDRAM_SendCommand(&hsdram1, &Command, 0xfff);

	HAL_SDRAM_ProgramRefreshRate(&hsdram1, 1542);
}

 

And writing to it using the following test code

 

#define SDRAM_ADDRESS_START 0xD0000000
#define SDRAM_SIZE 0x1000000

for(counter = 0x00; counter < SDRAM_SIZE; counter++){
 uint32_t addr = (SDRAM_ADDRESS_START+counter);
 *(__IO uint8_t*) addr = (uint8_t)(testByte+counter);
}

 

 Once that loop has run, there is a weird offset in the memory monitor.

IrisDM_0-1729586873962.png

The first byte of the memory (0xD0000000) doesn't get written to until my counter reaches 4, which should be an address of 0xD0000004. Furthermore, when 0xD0000004 and 0xD0000005 do get written to, 0xD0000008 and 0xD0000009 also get written to (notice the offset of 4 between them - these are the true addresses that I'm attempting to write to) and are skipped when the counter is at 0xC and 0xD.

So far I cannot see this happening anywhere else in the loop, but the offset of 4 is maintained throughout. I am currently exporting the full memory to file so I can investigate further, but I'm wondering if there's an obvious issue I'm missing.

    This topic has been closed for replies.
    Best answer by Iris-DM

    Solved it!

    I had the CAS latency set to 3 memory clock cycles instead of 2.

    For reference, I am driving the FMC from a 100MHz clock (200MHz peripheral clock with 2 HCLK cycles for common clock).

    Hope this helps someone else in the future.

    1 reply

    Iris-DMAuthorAnswer
    Explorer
    October 22, 2024

    Solved it!

    I had the CAS latency set to 3 memory clock cycles instead of 2.

    For reference, I am driving the FMC from a 100MHz clock (200MHz peripheral clock with 2 HCLK cycles for common clock).

    Hope this helps someone else in the future.