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.

C6678 Local reset problem

Hello,

I've a custom board with a C6678 connected to a linux host via PCIe. Cold boot works as specified. Trying a local reset (warm boot without losing the PCIe connection) to restart the program doesn't work.

I've implemented the method following the local reset example in mcsdk_2_01_02_06\tools\boot_loader\examples\pcie\linux_host_loader. The method works without errors. But problems are:

-Local reset is not shown in RESET_STAT
-Program execution stops when DSP set into reset
-Program execution continues when DSP out of reset; but DSP continues working on execution where it was stopped, also if I load a complete different program (Program downloaded is 0x1000 aligned).

I just use a simple program setting one value once and then increment a counter in a while loop. The while loop is always executed after reset nevertheless what was downloaded.

I assume the reset works (but I don't know why it is not recognized by RESET_STAT), but the jump to the DSP_BOOT_ADDR(n) won't. I also tried manually to unlock KICK0 / 1 and set the DSP_BOOT_ADDR(n), but reading these 3 registers always return zero or the ROM boot address 0x20b00001.

How can I further debug what's going wrong here?

Best regards,
Bernd

  • Hello,

    I've added some parts of my code used. Maybe there is an obvious error.

    Best regards,
    Bernd

  • Hello,

    I have checked setting DSP into reset. Somehow the register w/r does not work as expected. I have to check this first and then give feedback.

    Best Regards,
    Bernd

  • Bernd,

    "Somehow the register w/r does not work as expected", please clarify this when you have more info. The sequence of DSP local reset is to put core/periphrals into reset, download application code, write _c_int00 into DSP_BOOT_ADDRESS, pull core/periphrals out of reset.

    If you can't write _c_int00 into DSP_BOOT_ADDRESS, your new application can't be executed.

    Regards, Eric

  • Hello Eric,

    thanks for your reply. Now everything is working. Problem was the priority for access via PCIe, this bit was not set as expected -> then all other actions were not done.

    Best Regards,
    Bernd

  • Hello,

    a general question to the local reset: having the program in the L2SRAM, everything works fine. Placing the program completely in the MSMCSRAM (e.g. to boot more than one core with the same program), the reset doesn't seem to work reproducible.

    Sometimes the new program is not running (variables not set to new value), sometimes the core runs into an undefined regions and then stucks.

    I know that the whole MSMCSRAM is cached, but I don't think that this cause this phenomens.
    Are they're any know problems for this issue?

    Best Regards,
    Bernd

  • We have "hello world" in ti\mcsdk_2_01_02_06\tools\boot_loader\examples\pcie, it boots multiple cores. The code is in DDR3 (not MSMC). First core 0 is boot up, then it sent IPCGR to other cores to boot them up. I didn't meet issues in this case.

    For using MSMC, there are some example codes by Advantech how they did in the Linux PCIE driver, that may help.

    The driver is under http://www.advantech.com/products/PCIe-DSP-Card/sub_HALF-LENGTH_PCIE_CARD1.aspx for DSPC-8681 product. I looked my copy of version 0.7 (the latest is 0.8, not sure if any thing changed for local reset), check \dsp_loader\app\src\dsp_loader.c, function dio_put_dsp_in_reset() and dio_bring_dsp_out_reset().

         /*-------------------------------------------------------------------------
        * The following code is a work around to flush the cache, without this
        * Any dirty cache lines in L1D may cause corruption of the downloaded
        * image
        */
        ret = downloadSimpleLoopCode(dsp_id);

    That is, 8 IDLE instructions in MSMC.

    Regards, Eric

  • Hello Eric,

    thanks for that example. With DDR-Example I also had no problem. But on our custom board, we don't have a DDR so I have to use another memory.

    I'll have a look at the example from Advantech and try it.

    Best Regards,
    Bernd