• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 657 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.

DDR Latency Issue with JTAG access?

steve foster79764
Prodigy 230 points
Other Parts Discussed in Thread: AM1808

Has anyone seen data written into the DDR memory through the JTAG port being read back off by one address location with the beginning location in the burst being trashed? It’s as if the latencies between the DDR and AM1808 are off by one. We are loading code into the DDR through the JTAG when this happens.

It happens once in a while at power-up. Once the system is good it will stay good until a power cycle. The power sequencing is fine, per TI’s spec.

One time the board was left unpowered overnight and at the first power up the board had the problem. I’m pretty sure that overnight any locked up charges in the processor or DDR would have leaked away so it is not the type of hardware problem where a memory device like a register got locked into a bad setting at power off. 

The DDR2 memory is running at about 150 MHz. It is 16 bits wide. The design has one DDR2 chip. The minimum speed of the DDR is 125 MHz. Maximum is 400 MHz. Multiple latencies are allowed, we’re in the middle and running so slow that all latencies are allowed. The processor is the AM1808 running at about 450 MHz.

Thanks

Steve

 

  • 0
    TI__Guru*** 125430 points

    Have you precisely followed the documented initialization sequence in the TRM Section 14.2.13.1 "Initializing Following Device Power Up or Reset", i.e. including the VTP IO calibration steps?  I would suggest stepping through that code in a debugger to verify that there weren't any software errors related to the steps where you set/clear bits, e.g. in case you set the wrong bit or writing to the wrong register due to simple coding error.

  • 0
    TI__Mastermind 35645 points

    Steve,

    Thanks for your post.

    VTP IO calibration should be performed before emulation tools attempt to access the register of the DDR2/mDDR memory controller, otherwise, a bus lock-up condition will occur.

    You have to check Emulation considerations of DDR2 memory controller, because if JTAG emulator halts on the chip, but still DDR2 controller is functional to allow emulation access to external memory. Please refer note on Section 14.2.17 in the AM1808 TRM as given below:

    http://www.ti.com/lit/spruh82

    Thanks & regards,

    Sivaraj K

    ----------------------------------------------------------------------------------------------------------
    Please click the Verify Answer button on this post if it answers your question.
    ----------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 230 points

    Thanks for your feedback, the software guy assures me that he is following your advice. Keep the ideas coming! We're thinking it is in the memory controller section since the clocks look good on an O'scope.

  • 0 in reply to steve foster79764
    Prodigy 230 points

    Stay tuned, we may have fixed it, I'm going to wait a day or two and see if it returns before posting.

  • 0 in reply to steve foster79764
    TI__Guru*** 125430 points

    Steve -- what's the latest?  Is it resolved?  What did you change?

  • 0 in reply to Brad Griffis
    Prodigy 230 points

    We have not seen the problem for a couple of days after changing our initialization software. Here's the fix.

    On the power sleep controller (PSC) initialization step we spotted an error with our assembly language where a compare was made with an address instead of data and a BNE op code was not functioning as we wrongfully thought. After corrected them we cycled power ten times without a problem. Early on we fixed another problem where the delay was not long enough after initializing the PLL (another BNE problem) but this just made the original problem much worse. All is working well now.

    Thanks to all