• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 721 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.

66AK2G12: DDR3 issues

PF4Public PF4Public
Prodigy 10 points

Part Number: 66AK2G12
Other Parts Discussed in Thread: TPS51200

Hi all
I'm trying to bring up a custom board with 66AK2G12, TPS51200 and DDR3L memory, but it behaves seemingly random and I need your help with it.

The first issue is that I cannot make it boot to USB-DFU mode. Whatever BOOTCFG I tried, I see no activity on USB0_DM/DP pins. And of-course no new USB devices are detected in USB port by PC. Are there any specifics to make CPU enter USB-DFU apart from BOOTCFG? At the same time UART bootloader works flawless.

The next issue is that I observe high power consumption and TPS51200, DDR3L chips getting hot to touch. I assume that would be due to bootloader de-asserting DDR3_RESETn and issuing NOPs, which raise DDR3_WEn and others to DVDD_DDR, whereas TPS51200 pulls them all to DVDD_DDR/2 through termination resistors. Is it how it is supposed to be?

But anyway with TPS51200 and fly-by termination I cannot run U-Boot. It simply hangs. I've modified sources and could trace it up to get_ram_size function. I have modified it to write patterns into memory and read them back to verify it functions. Turns out it hangs at RAM access attempts. I tried various settings (including the ones calculated by "K2 DDR3 Register Calc v1p60.xlsx"), but the only viable config was ddr3phy_800_512mb/ddr3_800_512mb. This allowed several read/write steps to execute, reading garbage and then eventually halting.

For comparison I desoldered from the second identical PCB TPS51200, replacing it with a passive divider with capacitors on a DDR3_VREFSSTL net, desoldered termination passives. With these changes using ddr3phy_800_512mb/ddr3_800_512mb U-Boot could read/write memory correctly and indefinitely. I did quite a number of tests and sometimes I see DDR3 functioning correctly for indefinite amount of time for the whole duration of the run. Resetting / power cycling the board results in changes in behavior: sometimes it is still fine, sometimes it sees intermittent read/write errors. This behavior holds for the entire duration of the run. Could this be somehow related to read/write-levelling not succeeding sometimes? What configuration options could I try to modify to try to make it levelling more consistently?

Now if RAM functions properly, I allow U-Boot to proceed further and most of the time it stops after the end of copy_loop at relocate.S. At rare trials it could go past that and run U-Boot from RAM, but most of the time it stops just here. After the CPU is hung I observe lower power consumption, so I believe that at that point DDR3-unit of CPU ceases to function and/or RAM stops refreshing, but I may be wrong. What could hang the CPU during operations on DDR3? I mean even if read/write operations function properly something still hangs the CPU while U-Boot is trying to fix addresses at the relocated code, but not when copying the code itself into RAM.

Another issue is that I couldn't make CPU DDR3 controller use all 32 bits. With ddr3phy_800_512mb/ddr3_800_512mb it accesses only 16 bits of attached memory. I used "K2 DDR3 Register Calc v1p60.xlsx" to calculate proper values to no avail. I have DDR3-1600-capable SK Hynix RAM modules, but calculating them to operate at DDR3-800 does not help either. Any calculated configuration results in immediate halting upon first RAM access. I then tried modifying ddr3phy_800_512mb/ddr3_800_512mb to be 32-bit instead, but this also didn't work. I put 1 to .datx8_2_val and .datx8_3_val and changed NM from 2 to 1 in .sdcfg.

My fly-back chain first visits bits 16-31 and only then bits 0-15; do I have to account for it somehow, could it be affecting this somehow? 

Length-matching is done on the PCB for DDR3 signals.

Being able to use only UART bootloader, I have to upload U-Boot via UART, which takes almost 2,5 minutes. Could this delay somehow affect the DDR3 initialization, that is attempted later by U-Boot?

Please answer the questions raised above. I would be very grateful if you could advise me on how to proceed further to solving these issues.

Thanks in advance.

  • 0
    TI__Guru* 94871 points

    There's a lot to digest here.  I think i would first check all your power rails without trying to boot anything.  Check for proper sequencing and voltage levels on all rails on the board.    The memory should not be hot to the touch.  Specifically for the DDR, the DDR_RESET signal should be low when not booting anything.   Check there are no power to ground shorts, especially around the DDR,  Also check multiple boards to see if there is any commonality.  If several boards are behaving differently, you might have an assembly issue.  Once you check for proper power throughout the board, proceed to check clocks and resets, and ensure these are transitioning properly and at the right voltage amplitudes.  If you have JTAG, it would be best to connect that to see if you perform basic initialization.

    There are some design tips in the hardware design guidelines:  https://www.ti.com/lit/pdf/sprui93 and the schematic checklist app note https://www.ti.com/lit/pdf/sprac54

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 10 points
    JJD said:
    Specifically for the DDR, the DDR_RESET signal should be low when not booting anything.

    DDR3_RESETn is held high by 66AK2G12 200 ms after it is gone out of reset state to UART bootloader.

    I did check power supplies already.

  • 0 in reply to PF4Public PF4Public
    TI__Guru* 94871 points

    I asked to check the power and the signals without bootloading anything.  Either don't supply a bootloader or change to a different boot state.

    James

  • 0 in reply to JJD
    Prodigy 10 points

    Thank you for your suggestion, I'll try that and let you know how it goes.

  • 0 in reply to JJD
    Prodigy 10 points

    I have put both PCBs to "Sleep boot" and observe that approximately 20 ms (200 ms was a typo, it is 20 ms) after PORn goes high, 66AK2G12 raises DDR3_RESETn. With it DDR3_CKE0  is asserted high and possibly others. DDR3_WEn held high since DVDD_DDR available. The PCB with TPS51200 consumes significant amount of current in this state and, like I've already mentioned, heats TPS51200 and DDR3 chips. The other one, that is lacking TPS51200 and terminations, shows considerably lower power consumption and nothing overheats.

    Also I have checked all the power supplies and they are fine.

    I've tried powering DVDD_DDR from laboratory supply, but the behavior was exactly the same. I've tried the same with other voltages, but that also made no difference.

    Unfortunately this didn't resolve this situation and all the questions are still unanswered.

  • 0 in reply to PF4Public PF4Public
    TI__Guru* 94871 points

    It doesn't seem like the board is in sleep boot mode if the DDR3_RESET signal is going high.  Sleep boot should not be executing any code, thus the DDR should never be initialized.  Please double check this.  This may be the reason for the high current.  Can you send schematic of DDR interface with processor and TPS51200

    Regards,

    james 

  • 0 in reply to JJD
    Prodigy 10 points

    Hi, James

    Last week I decided to send my boards for an X-ray inspection. I will certainly check the Sleep boot again as I receive them back. BTW, could it be the manifestation of a DDR3 initialization issue that is mentioned here?

    The schematics of the DDR3 interface are as follows:

    CPU part

    DDR3 IC part

    Single DDR3 IC

    DDR3 termination

    VTTA block from the previous sheet

  • 0 in reply to PF4Public PF4Public
    TI__Guru* 94871 points

    Yes, you should not rely on the ROM DDR initialization.  The entire controller and PHY should be reset, and the DDR should go through a software initialization.  At this point, the DDR should be ready for normal operation.  Are you able to use JTAG and GELs to initialize the DDR?  This would eliminate any confusion with trying to boot software.  I would suggest this to make sure you do not have any hardware issues.

    Regards,

    James