• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 512 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.

TMS320C6455: Check CLKIN2 on device

Paul Bray
Prodigy 210 points
Part Number: TMS320C6455
Other Parts Discussed in Thread: STRIKE

Hi,

I'm trying to create some P.O.S.T. code for an 6455 design, and I'd like to be able to check that the DSP is receiving a sensible 25 MHz clock on CLKIN2.  The application here is fairly minimal, for instance, no DSP/BIOS available. 

I believe that CLKIN2 feeds PLL2 and generates SYSREFCLK, SYSCLK1, and the DDR Clock.  Ideally I'd like to be able to read a counter register that is incremented by something derived from CLKIN2 at two distinct points in my code and check that the register has incremented by the appropriate amount in between, but I can't find anything like that I could use.  A refresh count-down on the DDR controller would do, but I can't find such a register.  

Anyone got any suggestions?

B.R.

Paul

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Mastermind 27355 points
    Hi Paul,

    Have you already referred to section 2.8 of the C6455 DDR2 Memory Controller's User Guide? That may be what you are looking for: www.ti.com/.../spru970g.pdf
  • 0 in reply to Sahin Okur
    Prodigy 210 points

    Thanks Sahin,

    Yes I had read section 2.8, but maybe I missed something.  The refresh interval counter would suit my purposes very nicely, but I can't see how to read it.  Section 4 of SPRU970G shows 8 control registers, SDRFC allows me to set a refresh rate, which is presumably the value that would be loaded into the refresh interval counter, but I can't see a field in the register set that equates to the refresh interval counter.  

    Regards

    Paul

  • 0 in reply to Paul Bray
    TI__Guru* 84110 points
    Paul,

    Perhaps an indirect method would work for you. Since DDRCLKOUT is derived from CLKIN2 (and your DDR configuration settings), you could put the DSP in a read loop of DDR space locations and measure the time to execute that read loop using the TSCL/TSCH counters.

    There are a variety of read loops you could implement. The most intense would be using the EDMA3 to do the read, but the most intense DSP read loop I can think of would be :

    1. Configure L1D and L1P for max cache, and L2 for min cache (not 0, just lowest active cache setting).
    2. Invalidate the cache.
    3. Set the read loop to read the first word of each L2 cache line (or L1D, whichever is longer).
    4. Write to TSCL to start it, then read TSCL/TSCH to get a starting count.
    5. Read the length you find useful for your test.
    6. Read TSCL/TSCH and determine the time to execute the loop.

    If DDRCLKOUT is wrong, the count will be wrong.

    Just a thought.

    Regards,
    RandyP
  • 0 in reply to RandyP
    Prodigy 210 points

    Hi Randy,

    That's an interesting idea.

    I particularly want to check  CLKIN2 since I have a board where the DDR does not seem to retain the data written to it, obviously the fault could lie in the DDR or DSP, but most likely somewhere in the interconnection between the devices.  It did strike me that a problem with CLKIN2 could also cause the problem which is why I wanted to add it to my POST testing.

    I hadn't considered the caches, but I believe that the DDR memory region defaults to not cached via the MAR register settings, but I must admit getting a little lost in the architecture with regards to how DDR accessing ir done, implicit DMA going on?  Deviating from the original question a little here, my test code writes a count to the expected DDR address range and then read back and compares.  On a working board all of the comparisons are good, on the bad board none are.  Not an extensive memory test, but quite telling all the same.

    I hadn't thought to check how long these writes and reads took, but if I do then that should give me a good indication of the DDR Clock rate, and hence the CLKIN2 rate.

    As you suggest I might have to make it intense, so I'll look at your pseudo-code, and implement something.

    Best Regards

    Paul

  • 0 in reply to Paul Bray
    Prodigy 210 points
    Additional

    Since my DDR writes and reads complete, I might presume that there is some clock present. One might expect bigger problems if the DDR controller gets no clock.

    My CLKIN2 signal originates from a programmable clock generator device. I should be able to load a test configuration into that to stop CLKIN2, and see how my existing test code reacts. I may also be able to configure it to a different rate to 25 MHz to see how that effects the DDR Clock rate test.



    Paul