• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 100 subscribers
  • Views 979 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C6670 and DDR3 problem: DDR3 does not respond

Alon Slapak
Prodigy 250 points
Other Parts Discussed in Thread: UCD9222

Dear TI experts,

On our board we have 2 C6670, schematics is the same as of the EVM, and layout follows (I believe) TI recommendations.

Both C6670's are identical.

But. After loading the EVM's GEL file evmc6670l.gel, and running the Global_Default_Setup script, one of them passes the  DDR3 test: "C66xx_0: GEL Output: DDR3 memory test... Passed", and the other one doesn't:  "C66xx_0: GEL Output: DDR3 memory test... Failed".

We have double checked the signals and the HW design and found no issues.

Any idea what else to be checked would be highly appreciated.

Thanks, Alon. 

  • 0
    TI__Mastermind 42545 points

    Hi Alon,

    The GEL files provided with the EVM have been tailored specifically for that layout. Have you created a length matching spreadsheet for your PCB? Have you used those values to fill out the PHY calc and reg calc spreadsheets?

    Regards, Bill

  • 0 in reply to Bill Taboada
    Prodigy 250 points

    Thanks Bill,

    No, we haven't. Apparently we made a design to GEL.... We shall now change the registers following Tom Johnson's excel file. 

    Oddly, one of the DSPs passed with the EVM GEL and the second one didn't get to it.

    Now, proceeding from the previous post, we counter the GEL issue by using the platform_init function from the platform.c file. The first DSP passed the platform_memory_test from the platform.c flawlessly, while the second one steadily wrote only the first 64X32 bits correctly, and than wrote only wrong values.

    Could you please focus me on possible issues so that I can change the registers accordingly? - the excel file is obviously the next step, but reading many other posts on this website, it appears that some focus could be helpful.

    Thanks, Alon. 

  • 0 in reply to Alon Slapak
    TI__Mastermind 42545 points

    Hi Alon,

    Until you have calculated all your lengths and completed the PHY calc and REG calc spreadsheets for your specific layout, I can't really give you any good information on your problem. These values are used to allow the SOC and the memory to center the data transfers and maximize the setup and hold times. Variation in the timing due to the SOC are accounted for by the leveling process, however, if you don't provide correct information it may not operated correctly. Based on the fact that one of your boards appears to be working, your lengths may be close to those found on the EVM.  This could cause some boards to level correctly while others fail. 

    Regards, Bill

  • 0 in reply to Bill Taboada
    Prodigy 250 points

    Thanks Bill,

    We are working on that, and will report or verify answer.

    Alon.

  • 0 in reply to Alon Slapak
    Prodigy 250 points

    Bill,

    We have prepared the excel files (7851.DDR3 PHY Calc v10 - CHAB.xlsx5773.DDR3 Register Calc v4.xlsx ). Still, one of the C6670 passes the write/read test, whereas the second one doesn't. It continuously fails after 160 write operations (see below).

    Any idea?

    Thanks, Alon.

    80000000 80000004 80000008 8000000C 80000010 80000014 80000018 8000001C
    80000020 80000024 80000028 8000002C 80000030 80000034 80000038 8000003C
    80000040 80000044 80000048 8000004C 80000050 80000054 80000058 8000005C
    80000060 80000064 80000068 8000006C 80000070 80000074 80000078 8000007C
    80000080 80000084 80000088 8000008C 80000090 80000094 80000098 8000009C
    800000A0 800000A4 800000A8 800000AC 800000B0 800000B4 800000B8 800000BC
    800000C0 800000C4 800000C8 800000CC 800000D0 800000D4 800000D8 800000DC
    800000E0 800000E4 800000E8 800000EC 800000F0 800000F4 800000F8 800000FC
    80000100 80000104 80000108 8000010C 80000110 80000114 80000118 8000011C
    80000120 80000124 80000128 8000012C 80000130 80000134 80000138 8000013C
    80000140 80000144 80000148 8000014C 80000150 80000154 80000158 8000015C
    80000160 80000164 80000168 8000016C 80000170 80000174 80000178 8000017C
    80000180 80000184 80000188 8000018C 80000190 80000194 80000198 8000019C
    800001A0 800001A4 800001A8 800001AC 800001B0 800001B4 800001B8 800001BC
    800001C0 800001C4 800001C8 800001CC 800001D0 800001D4 800001D8 800001DC
    800001E0 800001E4 800001E8 800001EC 800001F0 800001F4 800001F8 800001FC
    80000200 80000204 80000208 8000020C 80000210 80000214 80000218 8000021C
    80000220 80000224 80000228 8000022C 80000230 80000234 80000238 8000023C
    80000240 80000244 80000248 8000024C 80000250 80000254 80000258 8000025C
    80000260 80000264 80000268 8000026C 80000270 80000274 80000278 8000027C
    00000000 FFF50000 00FFFFFF FFFFFFFF 00000000 FFF50000 00FFFFFF FFFFFFFF
    00000000 FFF50000 00FFFFFF FFFFFFFF 00000000 FFF50000 00FFFFFF FFFFFFFF
    00000000 00000000 00000000 00000000 00000000 00000000 00000008 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000008 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000008 00000000 00000000 00000000
    00000000

  • 0 in reply to Alon Slapak
    Prodigy 250 points

    Could anybody else  help us out with the above please?

    Thanks in advance, Alon.

  • 0 in reply to Alon Slapak
    TI__Mastermind 42545 points

    Hi Alon,

    Debugging DDR3 can be tricky since all accesses are done in bursts. If you use code composer, it will be accessing the memory locations as single accesses which will result in multiple bursts. This could mask any pattern the would help to understand the problem. Ideally you want to write a memory test that communicates with the DDR using DMA transfers. This will ensure that the data is burst into and out of the memory and will preserve the values in the adjacent memory locations. 

    You provided memory dumps with specify that a portion of memory is operating correctly and a different portion is not. If you could run the memory test across the entire memory range it might be helpful. I'm trying to determine if the data is being written but to the wrong part of memory. It may also show is an extended pattern that might help determine what's happening.

    Is the area of memory that you can access stable? Do you always get the same values back? We haven't seen a leveling problem like this that only effects a portion of the memory address range.

    Regards, Bill

  • 0 in reply to Bill Taboada
    Prodigy 250 points

    A week after....

    Thanks Bill, still working out this issue. Hope to inform soon.

    Alon.

  • 0 in reply to Alon Slapak
    Prodigy 250 points

    Bill,

    Thank you for the advice. We have managed to configure the DDR3 after fine-tuning the boot sequence times. It works.

    Thanks, Alon.

  • 0 in reply to Alon Slapak
    TI__Mastermind 42545 points

    Hi Alon,

    Glad to hear that things are working. Just for my own information, was the issue associated with the delay cycles within the DDR3 configuration or was it something else?

    Regards, Bill

  • 0 in reply to Bill Taboada
    Prodigy 250 points

    Hi Bill,

    It was in the DSP boot sequence that solved the problem.  We reconfigured the power sequence (ucd9222) and the reset signals accordingly. The delay cycles of the DDR3 configuration seems okay. We just needed to negate the option of the DDR3 miss-configuration, and that what you helped us with.

    Thanks, Alon.