• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 521 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS570LS1114: EMIF SDRAM read/write access mirroring

David Magiera
Prodigy 20 points
Part Number: TMS570LS1114
Other Parts Discussed in Thread: HALCOGEN

Dear TI experts,

I am using generated code from Halcogen 04.07.01 to initialize and access external SDRAM ISSI IS42S16100H-7TLI on a custom board.

The generated initialization sequence emif_SDRAM_StartupInit is called in system.c systemInit function right before the mapClocks call to start up the PLLs.

We operate VCLK3 at 71.5 MHz and filled the SDRAM timing parameters in Halcogen with the values from the ISSI Datasheet. In Pinmuxing the EMIF_nWE flag ist set and in Special Pinmuxing EMIF_CLK output is enabled. 

Writing a value to a data field of the SDRAM yields the same value for all data fields in sdram. E.g. if 0xA1A1 is written to 0x80000000, also 0x80000002, 0x80000004 etc. will hold 0xA1A1. 

Any help would be appreciated! Thanks. 

  • 0
    TI__Guru**** 198986 points

    Hi,

    Can you try PageSize=2 (slement_1024, 10 Column addresses)? 

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Dear Mr Wang,

    I tried Pagesize=2 (slement_1024). The observed mirroring behavior remains. Also the ISSI Datasheet specifies A0 -A7 as column address inputs, which should yield in 8 column adresses and therefor a pagesize of 256 16-bit elements, right?

    Kind regards
    David

  • 0 in reply to David Magiera
    Prodigy 20 points

    Hello,

    setting GREG1[31] to 1 in sys_startup.c did help.

    We verify SDRAM write and read accesses in main.c via a write array allocated in sdram memory space and a read array allocated on the stack. We observe that when we let the code run normally without breakpoints, there are memory gaps inside SDRAM, where values were not written correctly. When we step through each write instruction seperately with the debugger there are no memory gaps and all cells are written correctly.

    __attribute__((section(".farbss"))) volatile uint16_t sdram_far[100] = { 0 };  // test array in sdram

    inside main():

    for(uint16_t i = 0; i < 100; i++)
        {
            sdram_far[i] = i;
        }
        uint16_t sdram_read[100] = { 0 };
        for(uint16_t i = 0; i < 100; i++)
        {
            sdram_read[i] = sdram_far[i];
        }

    Any suggestions?

    Kind regards
    David

  • 0 in reply to David Magiera
    Prodigy 20 points

    Hi,

    the issue with memory gaps doesn't appear when a delay is placed between the sdram write accesses.

    __attribute__((section(".farbss"))) volatile uint16_t sdram_far[100] = { 0 }; // test array in sdram

    inside main():

        for(uint16_t i = 0; i < 100; i++)
    {
        sdram_far[i] = i;
        for(uint8_t delay = 0; delay < 5u; delay++)  // minimum delay for correct writes
        {
        }
    }


    Reading doesn't require the delay. We operate the system clock with 180 Mhz and emif clock with 90 Mhz. Any suggestions what could solve the issue or what causes it?

    Kind regards
    David

  • 0 in reply to David Magiera
    TI__Guru**** 198986 points

    Hi David,

    Looks like some SDRAM timing parameters are not programmed correctly. Does a lower VCLK speed help?

  • 0 in reply to QJ Wang
    Prodigy 20 points

    Hello Mr Wang,

    thanks for your reply. Timing issues are also our suspicion as source of the problem.

    Increasing the VCLK3 divider did actually worsen the issue. Ie. memory gaps became larger. Also we tested with f_cpu = f_emif = 90 Mhz but the issue remains.

    Here are some datasets:

    f_cpu = 180 Mhz, f_emif = 90 Mhz       f_cpu = 180 Mhz, f_emif = 60Mhz      f_cpu = 90 Mhz, f_emif = 90Mhz
                                            

    Errata DEVICE#B064 shouldn`t be relevant here, as we are using device revision C and it was fixed from revision B to C, right?

    Help is very appreciated!

    Kind regards,
    David