This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDSIDK437X: Single 16-bit DDR3

Part Number: TMDSIDK437X

Hi all,

I have a question regarding the removal of one of the two 256Mx16 DDR3 memories contained on the IDKAM473x. Before physically removing the memory, I would like to verify that my app runs correctly without it.

Following the spreadsheet tool provided by TI, I changed the SDRAM_CONFIG and EMIF_SDRAM_CONFIG_EXT in the corresponding gel file to 16-bit mode. I also changed the size of the external memory in the platform configuration to half the size. According to the config.bld file in ti/build/am43xx folder, the address of the second DDR should be at 0xA0000000. Now, as expected, it is impossible to access the aforementioned memory location of the second DDR.
However, if I change back the size of the external memory, I can access the memory without any problems. In both cases, my app runs correctly.
Nevertheless, I am suspicious about whether I am performing this test correctly, especially that to my best knowledge the spreadsheet for the AM43xx does not allow to enter information about how many DDR modules are containted on the board.
Can somebody tell me if the above steps are sufficient to simulate the case where I have only one DDR? If not, maybe you can give me hints on how to do so.
Maybe the information that the diagnosis script am43xx-ddr-analysis.dss doesn't give me any errors can help.
I am thankful for any advice.

Liliane

  • Liliane, to change the configuration, you should only have to change the Data Bus Width in the EMIF tool spreadsheet (in section 1A), and use the resulting register changes in the board.c file.  This will reduce the available capacity by half from 1GB to 512MB (as expected), from 0x80000000-0xA0000000.  Changing the config.bld will also make sure the code knows how much memory is available. 

    When you change back the size to the original 1GB in the code, what you are probably seeing is the aliasing in the memory.  For example, if you write 0xA0001000 (which shouldn't be available in a 512MB memory),  you will also be changing address 0x80001000.  This should easily be seen by doing a few memory dumps in u-boot.  Your application most likely does not traverse the boundary, and thus would not be exposed to the aliasing problem.

    I think ultimately you are doing the experiment correctly.    

    Regards,

    James  

  • Thank you for your prompt response, this was very helpful.

    Best,
    Liliane