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.

CCS/TMS570LS3137: SDRAM issue

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hello,

I'm new in embedded systems programing. I have a TMS570LS3137 HDK and i was trying to access the SDRAM. I write a simple program to check if I can use the SDRAM.

volatile uint16_t *p = (volatile uint16_t *) 0x80000000;

for(int i=0; i<32; i++)

{

*p=(uint16_t) 0x0030 + i ;

p++;

sciSend_32bitdata(scilinREG, *p);

sciSend_32bitdata(scilinREG, p);

}

In CCS, i use terminal and the result is;

Value: 00000030 Address: 80000000

Value: 00000030 Address: 80000002

Value: 00000032 Address: 80000004

Value: 00000032 Address: 80000006

Value: 00000034 Address: 80000008

Value: 00000034 Address: 80000010

....

It saves same value 2 times. What can i do to solve this issue? I'm sure I did all of the configurations well, I enabled drivers and in PINMUX tab enabled EMIF, Gate off EMIF clock and in EMIF tab I wrote all timings same with ISSI SDRAM datasheet, tried all clock frequences, can you please hep me solve this? What would be wrong?

  • Hello User,

    You have setup your memory pointer as a 16 bit word and are incrementing the pointer which will increment by 1 16 bit work address location. i.e., by 2 address locations. However, you have intialized your loop counter 'i' as an int which will natively be 32 bits since the device is a 32bit architecture. You are also calling the sciSend_32bitdata(scilinREG, *p) which will send 32 bits at a time. Try initializing your pointer as a uint pointer (32 bit pointer) and insure your type use in your code is consistent.

    Also you mention EMIF initialization. You code is only accessing standard SRAM which starts at a base address of 0x80000000. There is nothing related to EMIF in the code you posted so it would have no impact on what you are doing.
  • Hello Chuck,

    Thank you for quick reply. As I said I'm new at embedded systems, I made everything related with this post;

    e2e.ti.com/.../260952

    Can you please check that post. I made everything similar, got same problem, and made same things to solve it. That user have solved his problem with changing frequency and timings. I checked my frequency, SDRAM's datasheet and every TMS570 post about SDRAM usage. I know that ISSI 42S16400F SDRAM has 16 bit bus, when I setup the pointer as 32 bit pointer, all values that I see in terminal become zeroes. Also I checked addresses in memory view and I saw every addresses have same value.
  • Hello User,

    In the thread to which you provided a link, Anthony had posted an example project, were you able to get his example working and then you could adapt from there.
  • Hello Chuck,

    Anthony posted just EMIF configurations, not a complete project. I think I should find an example to check if the problem is my device or something another.
  • Hello User,

    I had a closer look at your example and I believe the issue is with the first sciSend_32bitdata as it is recieving the *p as the address of the 32 bit data to send. i.e., the sciSend_32bitdata function is trying to access the EMIF as a 32bit wide memory location when it is only 16 bits. Can you change the send function so that it is accessing the write data type? Or, the other option is to create a temporary location in regular device SRAM where you can copy the content of EMIF SRAM into prior to calling sciSend_32bitdata.
  • Hello user,

    Using this code:

    unsigned short *Addr = (unsigned short *) Start_Address; //0x8000_0000
    for (data=0; data<32; data+2){
    *Addr++ = ( data & 0xFFFF0000)>>16; //big endianess
    *Addr++ = ( data+1 & 0x0000FFFF);
    }

    After writing the data, open the memory browser in CCS, and check the data in the SDRAM.

    Regards,
    QJ
  • Hello Chuck,

    Hello QJ Wang,

    Firstly thank you for your attention, after I did everything to solve it I have decided to update my HALCoGen program because I think the version 3 has some bugs about EMIF driver. So I Installed the version 4 and ran my program, it worked. But I am curious about something.

    1. If I write a program and my RAM gets full, does it automatically use the SDRAM? If it doesn't what do I need to do?

    Thanks and Best Regards,

    Aslan.
  • Hello Chuck,

    Hello QJ Wang,

    I'm writing about my question that I asked, I found that how can make my device use the SDRAM automatically when the ram is full. In sys_link.cmd I defined my SDRAM just like the actual RAM and now I can use it how I want.
  • Hello Aslan,

    I am glad you were able to correct the issue with an update to the Halcogen tool and yes, adding the extended memory range from the external EMIF will allow the RAM to be used/allocated at compile time.
  • Hello Chuck,

    Thank you, I have a question too. I do all of the configurations and run the program when RAM is full, it automaticaly uses SDRAM, that is what I want to do but now I'm facing a different issue. I define long size arrays to test the memory if it work properly. When I do that I ran the program and check memory browser, I see something similar to that;

    Code

    volatile uint32_t testArray[100] = {0};
    volatile uint32_t testArray2[1000] = {0};

    for(int i=0;i<1000;i++)
    {
    testArray[i] = i;
    testArray2[i] = i;
    }
    -------------------------------------------------------


    testArray[0]=0
    testArray[1]=1
    testArray[2]=2

    testArray2[0]=100
    testArray2[0]=101
    testArray2[0]=102
    ---------------------------------------------------------

    TestArray2 must have same values with testArray but it doesn't. I think the program can't make a good memory allocation or there is a problem with addressing. What would be wrong?

    Thanks and Best Regards,
    Aslan
  • Hello Aslan,

    Is this an issue with the 16bit access limitation for the SRAM on the EMIF connector? i.e., accesses for your external RAM are limited to 16bits otherwise there will be wrong behaviors. When you allocate RAM, be sure to explicitly use only 16 bit values for the SRAM on the EMIF. This may be a problem with allowing the compiler to decide this for you because it cannot have the proper knowledge of which RAMs are limited to 16 bits and only use 16bit accesses for it.
  • Hello Chuck,

    I know external RAM has 16 bit access limitation so I tried the program with an uint16 too but it didn't solve my problem.

    Thanks and Best Regards,
    Aslan.
  • Hello Chuck,

    I solved my problem with changing a line in emif.c,
    I'm writing it here so if someone has same problem, he/she can fix it. Don't forget to use only 16 bit values!

    In emif.c there is a function initializes EMIF at startup and there is this code at the last line of that function,

    *((unsigned char *)(&emifREG->SDCR)+0x0U) = 0x80;

    If someone faces same problem, he/she must change it with the following one;

    *((unsigned char *)(&emifREG->SDCR)+0x3U) = 0x80;

    Thanks and Best Regards,

    Aslan
  • Aslan,

    Have you noticed that testArray has only 100 elements and your loop is indexing past that boundary? Valid index for testArray is 0 to 99.

    Since the compiler allocated testArray2 after the first array, your loop overwrote testArray2 elements when you past index 99. Hence testArray2[0] has value 100.

    Joe

  • Hello,

    I don't think so, I was having same problem with only 1 array too. For example

    Volatile uint16 testArray[500000];

    For(i=0;i<500000;i++)
    {
    testArray[i] = i;

    }

    I debug it and check memory browser step by step, everything increases normally. When i = 256 testArray[256] must be equal to 256 but somehow testArray[0] is being equal to 256 too. testArray[1]=257...
    ...

    Anyway, I have solved it as i mentioned before.

    Thanks and Best Regards,

    Aslan
  • Aslan,

    As Jo mentioned, this would be a bug if it truly represented what you have coded and are executing on the device.

    user4958934 said:

    volatile uint32_t testArray[100] = {0};
    volatile uint32_t testArray2[1000] = {0};

    for(int i=0;i<1000;i++)
    {
    testArray[i] = i;
    testArray2[i] = i;
    }

    As can be seen in your code snippet you are clearly stepping beyond the allocated memory for testArray[100] as you are copying in 1000 elements in your for loop.

  • Chuck,

    The problem was about emif.c file. If you remember, I told that I updated HALCoGen to 4.0. Now I'm downloading the version 4.06.01 and the emif.c file in this version is working without that bug.

    Thanks and Regards,

    Aslan.
  • Hello,

    I edited the code with the following one;

    #define testSize 0x00380000

    uint16 testArray[testSize];
    int i;

    for(i=0;i<testSize;i++)
    {
    testArray[i] = i;
    }

    I'm checking memory browser and I see testArray elements are increasing 0 to 0xFFFF but the addressing is so confusing. For example testArray starts at address 0x80000000 and it's size is 0x00380000 and it contains 16 bit data per element (2 bytes) so it needs to finish at 0x80700000 (0x00380000 * 2) but when i check memory browser I see this;


    0x80000000 0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A
    .................... ................................................................................................
    .................... FFF9 FFFA FFFB FFFC FFFD FFFE FFFF 0000 0001 0002 0003
    .................... ................................................................................................
    .................... ................................................................................................
    .................... E67C 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000
    .................... ................................................................................................
    .................... ................................................................................................
    .................... 0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A
    .................... ................................................................................................
    .................... FFF9 FFFA FFFB FFFC FFFD FFFE FFFF 0000 0001 0002 0003
    .................... FFF5 FFF6 FFF7 FFF8 FFF9 FFFA FFFB FFFC FFFD FFFE FFFF
    0x80700000 0000 0001 0002 0003 0004 0005 0006 0007 0008 0009 000A
    ................... 000B 000C 000D 000E 000F 0010 0011 0012 0013 0014 0015


    Sometimes the data corrupts between start and finish addresses and sometimes values are become zeroes and then become normal again. I watch it step by step when i=9 it breaks for loop. I think it writes data to memory randomly, so I tried the code with a pointer instead of array like this;

    #define testSize 0x00380000

    volatile uint16 *p = (volatile uint16 *) 0x80000000;
    int i;

    for(i=0;i<testSize;i++)
    {
    *p= i;
    p++;
    }

    I have same problem with this too. I'm really confused, I don't know what is the problem. Is there any one who can help me solve this? I'm waiting your advices. What could be wrong?

    Thanks and best regards,

    Aslan.
  • Hello,

    Is there anyone who can help me solve this? I can send the project if there is someone who can solve the problem.

    Thanks and best regards,

    Aslan.
  • Hello Aslan,

    I can see from the abreviated data you posted, that the corruption is occurring at the end of the count up. Can you provide more details on it such as the element number and address to which the value is being stored? Is it at a page boundary or address boundary of some type?
  • Hello,

    The data starts at address 0x80000000, when I write something at address 0x80000000, everyting is being copied to address 0x80200000 (2MB's away from start address), 0x80400000(4 MB's away from start address) and also 0x80600000 (6 MB's away from start address). I think the program or mcu does some kind of mirroring between banks. I know the SDRAM has 4 banks and it is 8 MB so it must be 2 MB per bank. Is there a setting that I can turn off the mirroring or is it a bug?

    Thanks and Regards,
  • Hello Aslan,

    Since your original problem was solved and since you already have another thread working to resolve this mirroring issue, let's close this thread and use the new thread at e2e.ti.com/.../2164823 to get an answer for the new problem.