• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 642 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.

AM5728: Issues with DDR timing

Lindsey Fike
Intellectual 2260 points

Part Number: AM5728

20160614 - 8GB_DDR3L_AS4C512M16D3L_AS4C1G8MD3L revised v 2.0 June 2016.pdfEMIF_RegisterConfig (002).xlsx

Hello, 

Posting for customer. 

So far I’ve been working with the EMIF Tools excel spreadsheet that TI provides in order to calculate the register parameters for our custom board. I first tried using these parameters in the custom code we had written to set up the EMIF. When this didn’t work I modified the SBL bootloader provided in the AM572x RTOS sdk with our custom values and loaded this to our board with the same result.

The data that I’m seeing coming back from our DDR doesn’t seem to follow any discernable pattern. It’s not a case of the top 16 bits are wrong but the bottom 16 are correct. Every time a read is performed on the DDR a different value is read. We haven’t had a chance to hook the board up to a scope to check all the control lines. This will be my next course of action. For your information I have attached our EMIF_RegisterConfig spreadsheet with the values of our custom board and I have attached the datasheet for the DDR used on our board.

Thanks!

  • 0
    TI__Guru 56877 points

    Hello,

    -1-

    If you are running  at 533 MHz, you do not need to set CL / CWL to 11 / 8 respectively, as those values should be used for faster speeds. I would suggest setting CAS Latency to 7 and CWL to 6.

    -2-

    Can you try setting the trace length settings in the xls to 0?  If the trace lengths were entered correctly, than this may notchange anything. However, we have seen this help in some cases.  

    Regards,

    Kyle

  • 0 in reply to kcastille
    Prodigy 30 points

    Hello Kyle,

    I tried setting CAS latency to 7 and CWL to 6 and setting the trace lengths in the xls to 0. No noticeable change occurred in the data. I also tried slowing the clock speed from 532 MHz down to 420 MHz to see if that might've been an issue. So far none of these changes have really made any kind of difference in the data.

    - Michael

  • 0 in reply to Michael Gabourie
    TI__Guru 56877 points

    Michael,

    How many boards have you tested?  Maybe it's a manufacturing issue?  

    Regards,

    Kyle

  • 0 in reply to kcastille
    Prodigy 30 points

    Hi Kyle,

    We've tested 2 boards so far. I went back to using a modified version of the PDK bootloader and was able to get the DDR mostly working with your suggestions. Setting the trace lengths to 0 made a big improvement and setting CAS to 8 and CWL to 6 has reading and writing working correctly now.

    However, we seem to be having an addressing issue as data is duplicated at address offsets of 64. Unfortunately our company security won't let me upload screenshots so I will attempt to describe it as clearly as possible. When writing a value of 0x11111111 to address 0x8000 0000, I will see this value at address 0x8000 0000 and 0x8000 0040. Additionally, If I write a value to 0x8000 0044 I will see this value at address 0x8000 0004. We have double checked and verified the page size, row bits, and bank bits and all of our values are consistent with the DDR we are using. I also tried experimenting with different values of IBANK_POS and EBANK_POS in the EMIF_SDRAM_CONFIG and EMIF_SDRAM_CONFIG2 registers. Unfortunately, nothing changed through these experiments.

    Thanks,

    Michael

  • 0 in reply to Michael Gabourie
    Prodigy 30 points

    Hi Kyle,

    Quick update. Testing with the other board has this same effect but every offset of 128. I think that this might be a manufacturing defect as the termination resistors were soldered by hand on these boards. We're going to investigate our boards more closely and I will get back to you.

    Thanks,

    Michael