2024-10-22 01:52 AM
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.
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.
Solved! Go to Solution.
2024-10-22 03:26 AM
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.
2024-10-22 03:26 AM
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.