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.

C6745 SDRAM Configuration Question



Hi,

I have been using C6747 starter kit, CCS Platinum v3.3, BIOS 5.33.05, PSP 1.30.1 and my audio application appeared working fine.  My new board with C6745 just came in and we are checking the hardware.  I have a question about the device SDRAM configuration.  I ran C:\Program Files\Texas Instruments\pspdrivers_01_30_01\packages\ti\pspiom\examples\evm6747\gpio sample code with the C6747 starter kit which has dual 32MB (64MB) 32-bit data bus SDRAM with base address 0xc0000000 and size of 0x3fc0000 in the tcf file.  It works fine.

My new board with C6745 has IS42S16400D 1 Meg Bits x 16 Bits x 4 Banks (64-MBIT).  I modified the gel file to use this SDRAM with 16-bit data bus 256 word-pages.

    EMIFB_SDCFG = 0         // SDRAM Bank Config Register
        |( 1 << 15)         // Unlock timing registers
        |( 1 << 14)
        |( 2 << 9 )         // CAS latency is 2
        |( 2 << 4 )         // 4 bank SDRAM devices
        |( 0 );             // 256-word pages requiring 9 column address bits

    EMIFB_SDREF = 0         // SDRAM Refresh Control Register
        |( 0 << 31)         // Low power mode disabled
        |( 0 << 30)         // MCLK stoping disabled
        |( 0 << 23)         // Selects self refresh instead of power down
        |( 1040 <<0);       // Refresh rate = 7812.5ns / 7.5ns

    EMIFB_SDTIM1 = 0        // SDRAM Timing Register 1
        |( 25 << 25)        // (67.5ns / 7.55ns) - 1 = TRFC  @ 133MHz
        |( 2 << 22 )        // (20ns / 7.5ns) - 1 =TRP
        |( 2 << 19 )        // (20ns / 7.5ns) - 1 = TRCD
        |( 1 << 16 )        // (14ns / 7.5ns) - 1 = TWR
        |( 5 << 11 )        // (45ns / 7.5ns) - 1 = TRAS
        |( 8 <<  6 )        // (67.5ns / 7.5ns) - 1 = TRC
        |( 2 <<  3 );       // *(((4 * 14ns) + (2 * 7.5ns)) / (4 * 7.5ns)) -1. = TRRD
                            // but it says to use this formula if 8 banks but only 4 are used here.
                            // and SDCFG1 register only suports upto 4 banks.

    EMIFB_SDTIM2 = 0        // SDRAM Timing Register 2
        |( 14<< 27)         // not sure how they got this number. the datasheet says value should be
                            // "Maximum number of refresh_rate intervals from Activate to Precharge command"
                            // but has no equation. TRASMAX is 120k.
        |( 9 << 16)         // ( 70 / 7.5) - 1
        |( 5 << 0 );        // ( 45 / 7.5 ) - 1

    EMIFB_SDCFG = 0         // SDRAM Bank Config Register
     |( 1 << 16)
        |( 0 << 15)         // Unlock timing registers
        |( 1 << 14)
        |( 2 << 9 )         // CAS latency is 2
        |( 2 << 4 )         // 4 bank SDRAM devices
        |( 0 );             // 256-word pages requiring 9 column address bits

I could not find the memory map configuration infomation for the tcf file from TI web site.  What should be the base address for this 8MBytes SDRAM?  I thought it shoul have the same 0xc0000000.  I changed the gpio sample code tcf SDRAM size to 4MB and TSK_sleep() never return back to gpioExampleTask.

If the SDRAM configuration is okay, what could be the issue with TSK_sleep().  I would like to findout how many timer (HWI 15?) interrupts had been occured.  Is there a way for me to find out?

Thanks,

Dennis

  • I found the EMIFB SDRAM memory configuration from the datasheet.  0xC0000000 is correct.  Please let e know how to monitor the timer interrupt.

    Thanks,

    Dennis

  • Yes, the 0xc0000000 starting address is true for any size SDRAM. The size can change to 0x007c0000 to use close to 8MB, mimicking the size in the original example.

    Since the tcf file for the original example had an SDRAM size of 0x03fc0000, there is an extra 0x00040000 that must be used somewhere else. Can you find another memory defined in the tcf that is at address 0xc3fc0000 with length 0x00040000? If so, then this also needs to be moved to the lower starting address of 0xc07c0000 still with size 0x00040000. This could be the problem, if BIOS is expecting to use that other memory for something.

    Another possibility is that the available heap size in the smaller SDRAM needs to be kept at the size that was used in the original example. Please check if that parameter has changed or not.

  • Hi Randy,

    The SDRAM configuration is ok.  Any idea what could cause BIOS timer function does not work?  I looked at CKSTAT and SYSSTAT registers.  All the clocks are enable.  How do I monitor the HW timer interrupts?

    Thanks,

    Dennis

  • Dennis Nguyen said:
    The SDRAM configuration is ok.

    Please be specific showing the old and new values for all of the memory components defined in your BIOS GUI, not just the tcf file(s). Since you have made a major change in your hardware configuration and in your tcf configuration, these things need to be documented completely here for our debug.

    Dennis Nguyen said:
    How do I monitor the HW timer interrupts?

    Look in the CLK Manager details in the BIOS GUI and find out which timer is being used and which HWI is expected. Then look in the HWI table in the BIOS GUI, confirm that the right HWI is reserved for the BIOS timer and find out what the function name is that gets called. Then you can set a breakpoint on that ISR function label to see if the interrupt is ever being reached.

    Also, what BIOS functionality is working correctly? Are static tasks running?

    If you load the exact same small-build program onto your EVM, does it run correctly?

  • Hi Randy,

    I was able to narrow down my issue on the new board.  I used my board SDRAM configuration and started with the simple GPIO example code from PSP.  With a single task, I was able to use TSK_sleep().  I then went back to my multi-task application and took out all but the highest task.  I was able to have TSK_sleep() worked as expected.  I added my other tasks in one at a time and the problem is in our audio task.  Our C1 board has newer codec and we do not know where exactly it blow up yet.  For now we will leave the audio task out and troubleshoot it next.

    Thanks for the helps,

    Dennis