I noted a post on another forum that suggests a possible driver defect in SEMC_ConfigureSDRAM(...);
The post suggests that line 387 of fsl_semc.c contains a defect. Specifically the post suggests that the refresh timer should be enabled here by ORing in SEMC_SDRAMCR3_REN_MASK -- I noticed that this is done on line 417 in SDK version 2.3.1. Is this a potential issue that I will want to fix locally, or is the Embedded Wizards forum post stale?
Thanks in Advance,
Everything should be fine as long as you enable refresh before you begin to use the SDRAM. If you import the SEMC example from SDK v2.3.1 you can see:
base->SDRAMCR3 |= SEMC_SDRAMCR3_REN_MASK;
at the end of SEMC_ConfigureSDRAM (line 417 of fsl_semc.c).
Please note that the same example has a bug in SEMC_GetDefaultConfig. In the function the following happens:
void SEMC_GetDefaultConfig(semc_config_t *config)
config->queueWeight.queueaWeight = &queueaWeight;
config->queueWeight.queuebWeight = &queuebWeight;
As you can see, queueaWeight and queuebWeight are non-static local variables, so their space on the stack is returned as soon as this function exits, which means their values are no longer valid by the time config is actually used.
Does the answer form Noah Wang help you solve your questions?
the document described how to configure SDRAM clock via registers, it should be helpful for you!
Have a nice day!