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.

TMS320C5505: External SDRAM interface to ISSI mSDRAM - EMIF register configuration and testing/validating ...

Part Number: TMS320C5505
Other Parts Discussed in Thread: SPRC133

Hi,

I'm looking at suggestions for best way to test & validate the functions of the recently added external SDRAM on a custom TMS320C5505/15 board. The mSDRAM from ISSI (IS42S16400-7) is a BGA component and access to the pins is practically impossible for classic debugging. I'm in the process of testing and validating the correct function of the external mSDRAM and would like some suggestions on the quickest way to test / validate the mSDRAM function, when using a Oscilloscope is not possible. The EMIF, as best as I know, has been configured correctly, in the GEL file and at the start of a test code, but here I have no direct confirmation until I know it works correctly. Until then what other indirect ways are there to validate correct SDRAM operation on the 100MHz custom board ? Any thoughts / suggestions on this ?

My initial way of proceeding has been to define using the MEMORY directive in the compiler sections :

MEMORY
{
    SDRAM (RWIX)     : origin = 050000h, length = 0800000h
}

then the sections :

SECTIONS
{

    .data            : > SDRAM, fill    = 0x0000
    .sysmem     : > DARAM, fill    = 0xABBA
    .bss             : > SDRAM, fill    = 0xBEEF
    .myheap      : > DARAM, fill    = 0x0000

etc.

}

and loading a compiled test_code.out  file via JTAG, then checking if there seems like valid data starting at 0x050000h address ... in any case some data that I expect to be initialized on loading the .out file in the .data and .bss sections which I instructed to use the SDRAM according to the memory map etc.

I'd like to test the functionality another way if possible but cannot think exactly of another way other than looking at scope/analyzer data that's at this stage not an option ...

Thanks in advance for any suggestion.

Mike

  • I've forwarded your query to c55x software team. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Cvetolin Shulev-XID said:
    I've forwarded your query to c55x software team. Their feedback should be posted here.

    BR
    Tsvetolin Shulev

    Hi Tsvetolin,

    Further to this question I have so far not gotten any feedback, perhaps it has been lost in the woodworks. Could you please look into it and perhaps point me to a more suitable forum if this one isn't the best one to post to ?

    Cheers, Mike

  • Hi Mike,

    Depending on your layout, PCB board tests may still be possible. For example, series resistors and thru-hole VIAs can be probed with a scope (perhaps the escape routing of the DSP uses thru-hole VIAs)
    With these access points, you can check clock speed, signal integrity, setup/hold times, rise/fall times, etc.
    It may be easier to check control signals this way (ie. make sure WE pulses low during write)

    Otherwise, you'll have to write some software tests.
        
    Using CCS, you should avoid executing code or storing results in the memory under test. Assume that the internal SARAM and DARAM to the DSP are tested and use them instead. I would load a program into internal memory that does all memory device init so you can avoid dependence on the GEL file. Executing GEL scripts will be slower than executing a program loaded through CCS.
        
    A quick Internet search revealed some fairly comprehensive material for software-based testing of memory devices...

    http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-memory-testing.html
        Copyright (c) 2000 by Michael Barr
        This article is adapted from material in Chapter 6 of the book Programming Embedded Systems in C and C++ (ISBN 1-56592-354-5). It is printed here with the permission of O'Reilly & Associates, Inc.
       
    And another one more about test execution speed is hosted by University of Cincinnati College of ECE...
        http://www.ece.uc.edu/~wjone/Memory.pdf

    Main take aways: check for PCB faults and installation faults - mainly stuck bits, shorted/open wires.  test data first, then address, then whole system. Use walking 1's pattern for data and block writes with incrementing data for address test. Follow the recommended sequence for good test coverage. Test the control signals last with your own tests (ie. select the wrong chip select to check for stuck low, force WE high during a write and check the write was unsuccessful). If tests are poor, perhaps you could try again with slower data rate then work your way back up to full speed.
     
    You may want to start with the CSL-based EMIF address test:
    Install the CSL from SPRC133 - http://www.ti.com/tool/sprc133
    Then the EMIF address test example will be located under... <INSTALL_DIR>\c55_csl_3.07\ccs_v6.x_examples\emif\CSL_EMIF_SDRAM_AddressTest_example

    Refer also to the C5515/05 EMIF User's Guide: http://www.ti.com/lit/pdf/sprugu6
        
    Hope this helps,
    Mark

  • Mike,

    Additionally, you may want to validate your tests on the C5505 or C5515 EVM, which has some probability of the signals through series resistors.

    http://support.spectrumdigital.com/boards/evm5515/revb/

    Spectrum Digital, who makes these EVMs, also provides source code for their SDRAM memory tests (and the rest of the board components) here: http://support.spectrumdigital.com/boards/evm5515/revb/files/evm5515_EVM_BSL_revb.zip


    Hope this helps,
    Mark

  • Hi Mark,

    Thanks for your reply. I appreciate your valuable suggestions. I've testing other parts of the custom board, but have come back to the external SDRAM and have been looking at the initial and most basic initial tests.

    Essentially, if one thinks the EMIF is set-up correctly, all the busses, command lines and clocks to/from DSP/SDRAM are working correctly then essentially declaring a global variable in the SDRAM section and changing its value should be in my opinion a way to do initial testing for a PASS/NO PASS type of test. As for rise-times, delays and clock stability etc. for robust testing that would come later.

    So essentially what I am after is a quci check if something moves and is observable in this new SDRAM storage space.

    So I declared already the data section in the .cmd files of the code composer project as :

    MEMORY

    {
        ISSI_SDRAM (RWIX)     : origin = 050000h, length = 0800000h
    }

    SECTIIONS

    {

    ..

    ..

        .SDRAM            : > ISSI_SDRAM, fill  = 0xBEEF

    }

    then did a global declaration with with the pragma directive:

    #pragma DATA_SECTION    (sdram_byte, "SDRAM");
    Uint32 sdram_byte=0;

    This should effectively tell the compiler and linker that sdram_byte is a global variable declared in the SDRAM data section, which has a mapping to an external address origin = 050000h.

    Now if something is there starting at 0x050000, and the memory is working correctly I should be able to write and read to/from it ...

    So I did just that and modified the sdram_byte from = 0, to 0xFFFF, to 0xA0A0 and stepped through with the debugger/emulator whilst watching this global variable on CCS.

    The watch window shows me the sdram_byte is modified correctly as I write value to it ... At first sight, and other than me wrongly assuming too many things about the way the compiler/linker/debugger works with external memory, it would appear I am getting positive initial results. That is I can write to a variable allocated in that memory section, and I can read from it ...

    Would you say this would be a quick initial test approach that should work as presumed /

    If this would not have worked as expected than the value in the sdram_byte variable would hold and read garbage regardless of what is written to it ?!?

    (Essentially given I have limited access to the EMIF's buses, since the 10 layer board is routed with the BGA memory with buried vias, I am hoping all works as expected, and unless something goes completely wrong I would restrain adding the logic probes to the memory buses if possible since it would become extremely difficult and time consuming do so ...)

    What would your thoughts be on this initial method ?

    Regards,

    Michael

  • So a brief update, there was an error on my part on the line #pragma DATA_SECTION (sdram_byte, "SDRAM"); where I had actually to include the section with a . before the SDRAM as ".SDRAM" which changed everything ... Now unfortunately I'm getting a "data verification error" when loading the .out file compiled and linked. ... At least this tells me there is a problem somewhere either the EMIF configuration or a hardware one.
    Thanks for the suggestions I think I can look into it further with more options available for testing the SDRAM.

    Regards,
    MM
  • Mark Mckeown said:

    Hi Mike,
    ...

    ...
        
    Using CCS, you should avoid executing code or storing results in the memory under test. Assume that the internal SARAM and DARAM to the DSP are tested and use them instead. I would load a program into internal memory that does all memory device init so you can avoid dependence on the GEL file. Executing GEL scripts will be slower than executing a program loaded through CCS.
    ...

    ...
        
    Hope this helps,
    Mark

    Hi Mark,

    So I did eventually execute the EMIF configuration code inside a SARAM/DARAM and I executed some of the C-memory test routines as suggested in your post.

    I am now getting some positive results, with the data bus test from 0x50000 up to 0x400000. It fails to go any further ... I'll look into it anyway.

    But my question relates to your advice to load the code in SARAM/DARAM and execute the SDRAM test routines within that memory rather.

    This makes sense for initial debugging as you said running the EMIF configuration in GEL scripts is best avoided.

    However eventually when all works, if some of the application code and/or certain buffers need to be stored in SDRAM sections, the compiled and linked .out program will need to be loaded before execution by debugger.

    How do you propose the EMIF be configured for using the external SDRAM other than by GEL script, so that the .out gets loaded correctly into SDRAM sections (otherwise CCS would return a memory access error I suppose) ?

    Regards,

    MM