• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 581 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.

How to debug DSP CPU stall?

Lee Holeva
Genius 4615 points

I'm suddenly getting the following error from CCS:

C674X_0: Trouble Halting Target CPU: Error 0x00000020/-1202 Error during: Execution, CPU pipeline is stalled and the CPU is 'not ready'. This means that the CPU has performed an access which has not completed, and the CPU is waiting. The target may need to be reset. The user can choose 'Yes' to force the CPU to be 'ready'. When this is done, the user will have the ability to examine the target memory and registers to determine the cause of the CPU stall. If CPU hang is caused by application and it has been forced to be 'ready', the CPU should not be run without a reset. Yes - force CPU ready (might corrupt the code) Disconnect - disconnect CCS so that it can be reset Retry - attempt the command again

I click on YES and get:

C674X_0: Trouble performing response: Error 0x20001026/-1202 Severe Error during: Memory, Register, Execution, Target, CPU pipeline is stalled and the CPU is 'not ready'. This means that the CPU has performed an access which has not completed, and the CPU is waiting. The target may need to be reset. The user can choose 'Yes' to force the CPU to be 'ready'. When this is done, the user will have the ability to examine the target memory and registers to determine the cause of the CPU stall. If CPU hang is caused by application and it has been forced to be 'ready', the CPU should not be run without a reset. Yes - force CPU ready (might corrupt the code) Disconnect - disconnect CCS so that it can be reset Retry - attempt the command again

C674X_0: Trouble Reading PC Register: Error 0x00001004/-1202 Error during: Register, Target, CPU pipeline is stalled and the CPU is 'not ready'. This means that the CPU has performed an access which has not completed, and the CPU is waiting. The target may need to be reset. The user can choose 'Yes' to force the CPU to be 'ready'. When this is done, the user will have the ability to examine the target memory and registers to determine the cause of the CPU stall. If CPU hang is caused by application and it has been forced to be 'ready', the CPU should not be run without a reset. Yes - force CPU ready (might corrupt the code) Disconnect - disconnect CCS so that it can be reset Retry - attempt the command again

C674X_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue

The error happens when accessing memory in a shared region.  Here is my current Platform.xds file:

metaonly module Platform inherits xdc.platform.IPlatform {

    config ti.platforms.generic.Platform.Instance plat =
        ti.platforms.generic.Platform.create("plat", {
            clockRate:      800.0,
        
   catalogName:    "ti.catalog.c6000",
            deviceName:     "TMS320TI816X",
            externalMemoryMap: [
                ["EXT_RAM",
                    {name: "EXT_RAM",     base: 0x80000000, len: 0x10000000, space: "code/data",access: "RWX"}],
                ["DDR2",
                    {name: "DDR2",        base: 0x98000000, len: 0x02100000, space: "code/data",access: "RWX"}],
                ["SR0",
                    {name: "SR0",         base: 0x9F700000, len: 0x00200000, space: "code/data",access: "RWX"}],
               ["SR1",
                    {name: "SR1",         base: 0x90000000, len: 0x06000000, space: "code/data",access: "RWX"}],
            ],
            l1DMode:"16k",
            l1PMode:"32k",
            l2Mode:"256k",
    });

instance :

    override config string codeMemory  = "DDR2";
    override config string dataMemory  = "DDR2";
    override config string stackMemory = "DDR2";

}

I need at least 5MBytes for images in SR1.  I also have rw mem = 256M for linux in the bootargs.  Any problem with my platform definition?

Update:

I ifdefed-out the block of code previous to where the crash occured and the crash did not happen.  In the block of code ifdefed-out I'm doing DMA transfers to L1D using the EDMA low-level driver.  I suspect the bug has something to do with that.

Lee

 

  • 0
    Genius 4615 points

    I rewrote the code that had uased DMA to not use DMA, that code now appears to be functioning properly, but I am still getting the CPU stall in the following bit of code:

    for (k=2;k<LEVEL2HEIGHT;k++){

        imginPtrH = HNC + (k-2)*LEVEL2WIDTH + leftL + 2;
        imginPtrV = VNC + k*LEVEL2WIDTH + leftL;
        imgoutPtr = LL + k*LEVEL2WIDTH + leftL + 2;
       
        for (j=0;j<rightL-leftL+1;j++){

          minValH = _min2(imginPtrH[j], imginPtrH[j + LEVEL2WIDTH]);
          minValV = _min2(imginPtrV[j], imginPtrV[j + 1]);
          minVal = _min2(minValH, minValV);
          imgoutPtr[j] = (UInt8)(threshold(minVal, cthr) >> 7);
        }

        Cache_wb(imgoutPtr, LEVEL2WIDTH, Cache_Type_ALL, TRUE);
      }

    The memory locations appear ok, nothing looks to be out of bounds, and I can successfully single-step through the code (F5), but as soon as I click on run, with a breakpoint located at the first line of the inner-most loop,  the C674x CPU stalls.  Any ideas?

    I still think that this is a memory map issue.  I rebuilt my code using -O3 and the behavior changed.  From ROV I am now getting an error:

    "Target memory read failed at address 0x9812F444, length: 8

    This read is at an INVALID address according to the application's section map."

    This is incorrect.  I changed the Platform file to:

    metaonly module Platform inherits xdc.platform.IPlatform {

        config ti.platforms.generic.Platform.Instance plat =
            ti.platforms.generic.Platform.create("plat", {
                clockRate:      800.0,
            
       catalogName:    "ti.catalog.c6000",
                deviceName:     "TMS320TI816X",
                externalMemoryMap: [
                    ["EXT_RAM",
                        {name: "EXT_RAM",     base: 0x80000000, len: 0x10000000, space: "code/data",access: "RWX"}],
                    ["DDR2",
                        {name: "DDR2",        base: 0x98000000, len: 0x02100000, space: "code/data",access: "RWX"}],
                    ["SR0",
                        {name: "SR0",         base: 0x9F700000, len: 0x00200000, space: "code/data",access: "RWX"}],
      ["SR1",
                        {name: "SR1",         base: 0x9F900000, len: 0x14400000, space: "code/data",access: "RWX"}],
                ],
                l1DMode:"16k",
                l1PMode:"32k",
                l2Mode:"256k",
        });

    Putting  0x9812F444 well within DSP memory.

    Update:

    Thinking that perhaps this is a stack issue, I increased the size of the stack.  I now have the code running to the point where is replys to the host and at the messageQ_open call the DSP is now going into the weeds.  This bit of code was working fine, so I suspect the fault is actually elsewhere.

    I figured this out.  I had a typo in a variable name that referred to shared memory with the consequence of using local memory instead.

    Lee