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

C6713B EMIF Initialization during Host Boot

Christopher Fleck
Prodigy 130 points

TI forum,

We've developed a custom board that uses a C6713B DSP as a slave device to an Atmel ARM MCU. On power up, the MCU programs the DSP with the following process:

  1. Reset the DSP by holding the nRESET line on the DSP active for 100ms. Wait for 10ms after releasing the nRESET line for any bootloader initialization on the DSP.
  2. Initialize the DSP's EMIF registers over HPI
  3. Initialize the DSP's PLL registers over HPI
  4. Wait 500ms to allow the new PLL settings to take effect
  5. Initialize the DSP's EMIF registers again using the new PLL settings, again over HPI
  6. Copy over the DSP program from the MCU Flash to the DSP sector by sector. Read back each sector and verify CRC.
  7. Write to register for the DSP to reboot into the copied program, wait 1s for the DSP to run through initialization in the program.
  8. Read the results of a memory pattern test that the copied program performs on startup to verify that the program has started.

For our previous revision of boards, this algorithm worked essentially every time on all of our boards (~30 boards, power cycled ~daily). There were isolated instances (<1% of power cycles) of CRC failures in step 6 or memory pattern failures from step 8, but their frequency was within our acceptable error margin.

For our newest revision of boards, this algorithm does not work as-is. A delay must be inserted at the end of step 2 of ~20ms and the delay after PLL setup must be increased to 600ms. If these delays are not added, the algorithm fails nearly 100% of the time. The board layout has changed between board revisions, but no support hardware has been changed for the DSP, and no support hardware related to the HPI bus has been changed for the MCU. The minimum delays that allow the programming algorithm to succeed are large enough (order of milliseconds) that I do not suspect something like longer traces causing slower SDRAM throughput to be the root cause.

My question is, what could be the source of the additional delays needed?

Thanks in advance,

-Chris F.

  • 0
    TI__Mastermind 35645 points

    Hi Chris,

    Thanks for your post.

    I think like, because of longer traces in the revised board layout, an additional delay of EMIF clock cycles then usual would be incured when EMIF issues an SDRAM Activation (ACTV) command before a SDRAM read or write access command is issued. Also, SDRAM Reads or writes to random areas instead of currently active row in its bank would obviously reduce the throughput because everytime a new page is accessed, the ACTV command must be issued.

    I hope, the source of the additional delays could be the SDRAM Activation command issued by EMIF when accessing a new page everytime when it reads/writes from random areas of SDRAM bank.

    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 130 points

    Sivaraj,

    The additional programmatic delay required is on the order of milliseconds. When running SDRAM at as close to 100 MHz as possible, I'd expect longer traces to delay operations by a few clock cycles, which should be on the order of nanoseconds to microseconds. I could be convinced otherwise on this point if there was some multiplicative delay effect that I am unaware of, but otherwise I doubt that this is the problem as I pointed out in my original posting.

    In terms of random SDRAM accesses, the additional delays are only necessary when initializing the EMIF and PLL registers over HPI. Normal SDRAM operations need no additional delay. So, I don't think that random accesses have anything to do with this problem, given that two fixed registers are the only addresses in question.

    Thanks for the response,
    -Chris F.

  • 0 in reply to Christopher Fleck
    TI__Guru* 84110 points

    Chris,

    Did you come to a resolution on your problem with the differences in the boards?

    What is the total time from releasing nRESET until you set PLLEN=1? You do not specify this time in your list, but if the time taken to initialize the EMIF registers in Step 2 is too short, then you will fail to meet the PLL Reset delay specified in the datasheet.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 130 points

    Randy,

    We have left it as an open-ended problem on our design, as we recently ordered more PCBs with a different fabrication house (due to hopefully unrelated, consistent board population issues).

    Our wait time is approximately 20ms. From the datasheet, it looks like the longest PLL Reset delay is approximately 200us. So, as far as I can tell, we're waiting for plenty of time.

    Thanks,
    -Chris

  • 0 in reply to Christopher Fleck
    TI__Guru*** 125430 points

    I see a couple issues with what you're doing.

    1. The Data Manual makes the following comment:

    The PLL Controller registers should be modified only by the CPU or via emulation. The HPI should not
    be used to directly access the PLL Controller registers

    2. The PLL initialization should be performed BEFORE the EMIF initiaization.  The EMIF values are based upon timing values that are all dependent on your clock frequency.  Therefore it's critical that the clocks are running at that frequency before you start up the EMIF.

    To overcome item #1 above you'll need to have a 2-phase loader.  The first phase will be simply to load a small and simple program whose sole duty is to program the PLL and the EMIF.  You could have the CPU send an interrupt to the host when it's done such that it can reprogram the device.