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.

AM3352: Issue with DDR3

Part Number: AM3352
Other Parts Discussed in Thread: AM3358

Hi,

I have designed a board with Beaglebone Black as a close reference.

CPU: AM3352BZCZA80
RAM: ISSI IS43TR16256AL-125KBL (DDR3L, datasheet)
PMIC: TPS65217D
JTAG: XDS200
Code Composer Studio v8.2

The issue is that I can not talk to the RAM and thus cannot run DDR3_slave_ratio_search_auto.out to find optimal parameters.

I have tested three boards so far, and on two of them I can't talk to RAM at all as it seems, I can not get a value to stick in the RAM when updating an address in the memory browser.

On one board there is random toggling of random addresses between 0x00000000 and 0x00FF00FF.

Here is a GIF showing the memory browser at 0x80000000 and forward with the toggling issue:

I've tried with both 303 MHz and 400 MHz speeds to the RAM.

Attached is my updated GEL with values for 400 MHz clock. Also attached is an Excel-file with the lengths in mil of all DDR3 signals.

I have read the wiki a lot and even tried using the GEL from BBB (with my timing values) but with no luck. Running the GEL on an actual BBB works, of course.

VDDS_DDR is steady at 1.354V and DDR_VREF is at 0.678V.

I would appreciate if I could get some help or ideas. It would be nice to get a second opition on my timing values, so I now they are ok.

Thanks in advance!

DDR3 length.XLSAM3358_StarterKit_2018-10-16_400MHz.gel

  • Jonas, you most likely have an issue in either the RatioSeed spreadsheet or the timing spreadsheet from the wiki. Can you attach both?

    Regards,
    James
  • I've made some more tests today to try and figure things out.

    If I enable ODT and PHY Macro in ALLOP_DDR3_READ_LATENCY define of the GEL file (setting it to 0x100207) I get random data on all three boards. Even if only enableing the ODT it will show random values.

    #define ALLOPP_DDR3_READ_LATENCY    0x207
    0x00000000
    0x00A800A8
    0x00A800B8
    0x00B800A8
    0x00B800B8
    
    #define ALLOPP_DDR3_READ_LATENCY    0x100207
    0x00000000
    0x000000A8
    0x000000B8
    0x000000BC
    0x000000FF
    0x00FF00FF
    0x00B800Bd
    0x00BC00BD

    We use a single memory point-to-point topology as on the BBB.

  • Hi Jonas, can you try with INVERT_CLKOUT=1 in the RatioSeed spreadsheet, and plug in resulting values into GEL. When you do this, ensure you +1 the read latency value

    Also, are you terminating addr/ctrl on the board (ie, do you have VTT)? I assume you don't since you say you referenced BBB.

    Regards,
    James

  • Hi,

    thanks for your suggestions. But they made no difference.

    Got this from RatioSeed sheet:

    So I updated to this is the GEL file:

    #define  CMD_PHY_CTRL_SLAVE_RATIO       0x100
    #define  CMD_PHY_INVERT_CLKOUT          0x1
    #define  DATA_PHY_RD_DQS_SLAVE_RATIO    0x40
    #define  DATA_PHY_FIFO_WE_SLAVE_RATIO   0xFD //RD DQS GATE
    #define  DATA_PHY_WR_DQS_SLAVE_RATIO    0x80
    #define  DATA_PHY_WR_DATA_SLAVE_RATIO   0x80  //WRITE DATA
    #define  DDR_IOCTRL_VALUE               (0x18B)
    
    #define ALLOPP_DDR3_READ_LATENCY    0x08        //RD_Latency = (CL + 2) - 1  (+1 for inverted CLKOUT) 

    Out ov curiosity, why to I have to add +1 to read latency if I invert the clock?

    No, no VTT is used. he DDR3 is conencted as in the BBB and Figure 7-48 in the AM335X family datasheet.

    Regards,
    Jonas

  • Hi Jonas, ok, keep everything as you show above, but change DATA_PHY_WR_DATA_SLAVE_RATIO=0xC0

    INVERT_CLOCK=1 shifts the clock by half cycle, so the read latency needs to be adjusted accordingly.

    Regards,
    James
  • Still no luck :/

    I tested with DATA_PHY_WR_DATA_SLAVE_RATIO=0xC0 with both with INVERT_CLKOUT set to 1 and 0 but no difference. Still can't get anything to stick in the RAM.

    Any more tricks up your sleave? If you do, could you suggest more then one at the time. WIth the time difference (I'm in Sweden) I think that could speed up this process a bit. Thanks.

  • Hi Jonas, sorry for the lack of suggestions here. Right now I'm a little stumped at the moment. Here are some more suggestions:

    -After going back thru the material you sent, i did notice you have ROWSIZE set for 16 bits. I think you are using the 256Mx16 memory device, which according to the datasheet has 15 row address bits. Go ahead and fix this, although based on the errors you show, i don't think this will fix the problem.
    -For now, disable dynamic ODT in the SDRAM_CONFIG register (DYN_ODT=0)
    -Are you able to probe signals on your board, especially CK and DQS? I know sometimes access is limited on a point to point design, but you may be able to access a via or something to probe these signals during a memory window refresh
    -Are there any significant layout differences between BBB and your board?
    -you previous said you checked VDDS_DDR and VREF. Are you checking with a scope during memory accesses, to see if any possible droops or noise during these transactions
    -check voltages on VDDS_PLL_DDR and VDDS_PLL_CORE_LCD

    REgards,
    James
  • Hi James,

    Thanks for suggestion. I think I'm getting closer to the problem now.

    Changing ROWSIZE didn't help, but it should off courde be cocrect once it all works.

    DYN_ODT is 0

    I double checked the schematic agains BBB and I found that my pullup on RST line was 10k, BBB has 1,5k, changed that but no difference in behvaiour. Also, the DDR_VREF voltage divider on my board is built up using 1k resistors, and on BBB it is 10k resistors. Changing these to 10k made no difference. Otherwise the schematic is the same, regarding CPU, DDR3 and PMIC. I just double checked resistors and decoupling and they are correctly mounted. Regarding the layout, I did not use the BBB to 100% here, because of a little bit different stackup and space constraints.

    VDDS_DDR, DDR_VREF, VDDS_PLL_DDR and VDDS_PLL_CORE_LCD all look steady (moving up and down +- 5mV), even during read and write.

    Lastley, I have now measured CK and DQS and found something quite interesting that will help narrowing in on the issue (I hope). the CK looks very good, dompared to a BBB I have they look identical. DQS on the other hand. Writing doesn't quite have the same swing to it on my board as on the BBB. The measurements could be improved perhaps, I don't have an active probe available until monday. I've used 500 MHz passive probes with 11 pF capacitance.

    My board, write, DQS1 (yellow P, green N).

    BBB, write, DQS1:

    But my biggest worries is that I don't get a clock, at all, while doing a read... On BBB a read looks like this:

    I did make a measurement on my board with DYN_ODT=1 and saw this oddly looking waveform (note the time/div setting):

    Another thing I notied while measuring was that when I probe both DSQ1P and DQS1N, the memory windows in CCS started updating with random values (as random as in my first GIF), and when I removed the probes it goes back to being all zeros again.

    I hope this is helpful and I really appreciate you helping me.

    Regards,
    Jonas

  • Hi Jonas, ok these scope shots help. On the write, it looks like you might need to adjust the drive strength or termination to get better signal swing, as you can see that the last DQS pulse doesn't even swing through VREF.
    But obviously you big issue is the read. The controller should be driving the clock, and the memory should be driving the data signals on a read, so it is almost as if the DDR is not getting initialized properly.

    One experiment is the remove the pullup on RESET (that is only needed for low power refresh operations), and then before kicking off the DDR initizliation in the GEL, check the voltage levels as you have done (VDDS_DDR, VREF, etc), and RESET and CKE should be low. Then kick off initialization and ensure CKE and RESET go high, and voltages are steady.

    I will try to come up with more ideas...

    Regards,
    James
  • Hi,

    I've got it working now! I had a collegue review the schematic once again, and he found that RAS and CAS had been switched...

    I patched one PCBA and got it working. I'm having some timing isues during write now, but that could be due to my patch, and/or timing parametering.

    Over 10 people have reviewed this and all of them missed this. No mather how many times it is reviewd there is always something that slips through.

    Thanks for the help James!

    Regards,
    Jonas