Unexplained halt in CCS with XDS510 USB Plus JTAG and TMS320C6713B DSP

Hello,

I'm working on a project for which we have designed a custom board with a TMS320C6713B DSP. We are having some problems with the DSP chip, for which we have not yet tracked down the cause. Code which should be executing fine on the DSP is "blowing up" (PC is getting derailed). We suspect some issue with SDRAM, though my memory tests through the HPI port (from a host CPU) seem to checkout, except for some strange 32MB mirroring of our 64MB memory. The code in question should only be using the first 32MB though.

The specific question I have is in regards to an unexplained halt of my XDS510 USB Plus JTAG, though any other tips on resolving our hardware issues would be much appreciated.

During initialization of our DSP test program and prior to main() getting called there are several memcpy function calls. One of these function calls halts the debugger at the following instruction (with the * asterisk):

80892E80 8087E059 [ A1] SUB.L1 A1,1,A1
80892E84 021436B7 || STB.D2T2 B4,*B5++[1]
80892E88 020C105B || MV.L2X A3,B4
80892E8C 20000011 || [ B0] B.S1 0x80892E80 (PC+0 = 0x80892e80)
80892E90 2003E1A3 || [ B0] SUB.S2 B0,1,B0
80892E94 81903624 || [ A1] LDB.D1T1 *A4++[1],A3
80892E98 009803A2 MVC.S2 B6,CSR
80892E9C 000C0362 B.S2 B3
*80892EA0 02180058 MV.L1 A6,A4
80892EA4 00004000 NOP 3

This is within the memcpy routine and just prior to returning from the function. What are the reasons why the JTAG interface would halt? I have not seen any information on any sort of exception handling for this CPU. I did read that the MVC instruction can power down the DSP, which requires an interrupt to wake up, but the value in B6 is 0x02030100 which is not enabling power down. I don't see how there could be a problem with MV.L1 since it is just copying between 2 registers. The values of A4 and B5 (memory addresses) are valid memory addresses as well. This particular memcpy is writing to the first 8 bytes in SDRAM, from what I can tell.

Thanks in advance for any information.

Best regards,
Josh Green

_____________________________________ Start a New Thread

hello Josh,

On Wed, Mar 4, 2009 at 7:55 PM, kernelbloat wrote:
> Hello,
>
> I'm working on a project for which we have designed a custom board with a
> TMS320C6713B DSP. We are having some problems with the DSP chip,


or 'chip behavior' due to the software and/or hardware.

> for which
> we have not yet tracked down the cause. Code which should be executing fine
> on the DSP is "blowing up" (PC is getting derailed). We suspect some issue
> with SDRAM, though my memory tests through the HPI port (from a host CPU)
> seem to checkout, except for some strange 32MB mirroring of our 64MB memory.
> The code in question should only be using the first 32MB though.


If you suspect an SDRAM problem [a very reasonable starting place], it
is very painful to troubleshoot the hardware problem by analyzing
'software misbehavior' due to 'bad bits being fetched'.
I recognize that many of us have different debug techniques. I will
share my preferences for the c6713.
1. Start with the DSP only. There is 256K of internal memory - start
with code that only runs from internal memory.
2. Develop a memory test for SDRAM that runs from internal memory. If
you have a hard failure, you should be able to locate the problem with
a few sequential pattern and/or address tests. If the problem is
intermittent, you will probably have to use random addresses.
3. Develop some subset of your final app that will run in internal
memory and exercises one or more peripherals. Make sure that it is
solid.
4. Run a simple hello world type app that contains a loop and prints
the loop count in internal memory and SDRAM.
5. If all is okay with #4, build the app in #3 to run in SDRAM and try it.

>
> The specific question I have is in regards to an unexplained halt of my
> XDS510 USB Plus JTAG, though any other tips on resolving our hardware issues
> would be much appreciated.
>
> During initialization of our DSP test program and prior to main() getting
> called there are several memcpy function calls. One of these function calls
> halts the debugger at the following instruction (with the * asterisk):
>
> 80892E80 8087E059 [ A1] SUB.L1 A1,1,A1
> 80892E84 021436B7 || STB.D2T2 B4,*B5++[1]
> 80892E88 020C105B || MV.L2X A3,B4
> 80892E8C 20000011 || [ B0] B.S1 0x80892E80 (PC+0 = 0x80892e80)
> 80892E90 2003E1A3 || [ B0] SUB.S2 B0,1,B0
> 80892E94 81903624 || [ A1] LDB.D1T1 *A4++[1],A3
> 80892E98 009803A2 MVC.S2 B6,CSR
> 80892E9C 000C0362 B.S2 B3
> *80892EA0 02180058 MV.L1 A6,A4
> 80892EA4 00004000 NOP 3
>

Q1. Does CCS indicate that the device is halted??
Q2. Save the contents of memory to a file [the above range is good].
Examine the file. Does the file contents match the displayed values??
Q3. If you move the locations of the above code, do you get identical results??

mikedunn

> This is within the memcpy routine and just prior to returning from the
> function. What are the reasons why the JTAG interface would halt? I have not
> seen any information on any sort of exception handling for this CPU. I did
> read that the MVC instruction can power down the DSP, which requires an
> interrupt to wake up, but the value in B6 is 0x02030100 which is not
> enabling power down. I don't see how there could be a problem with MV.L1
> since it is just copying between 2 registers. The values of A4 and B5
> (memory addresses) are valid memory addresses as well. This particular
> memcpy is writing to the first 8 bytes in SDRAM, from what I can tell.
>
> Thanks in advance for any information.
>
> Best regards,
> Josh Green

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

_____________________________________ Start a New Thread

Check the following stuff for trying to run DSP independently
1> The Main processors Is not putting DSP in reset.
2> The Daisy chain length that you have defined in mutl processor environment for JTAG is okay?
3> A gel file to iniatlize memory and telling CCS what memory map is of the DSP is well written and defined.

--- On Wed, 3/4/09, kernelbloat wrote:

From: kernelbloat
Subject: [c6x] Unexplained halt in CCS with XDS510 USB Plus JTAG and TMS320C6713B DSP
To: c...
Date: Wednesday, March 4, 2009, 8:55 PM

Hello,

I'm working on a project for which we have designed a custom board with a TMS320C6713B DSP. We are having some problems with the DSP chip, for which we have not yet tracked down the cause. Code which should be executing fine on the DSP is "blowing up" (PC is getting derailed). We suspect some issue with SDRAM, though my memory tests through the HPI port (from a host CPU) seem to checkout, except for some strange 32MB mirroring of our 64MB memory. The code in question should only be using the first 32MB though.

The specific question I have is in regards to an unexplained halt of my XDS510 USB Plus JTAG, though any other tips on resolving our hardware issues would be much appreciated.

During initialization of our DSP test program and prior to main() getting called there are several memcpy function calls. One of these function calls halts the debugger at the following instruction (with the * asterisk):

80892E80 8087E059 [ A1] SUB.L1 A1,1,A1
80892E84 021436B7 || STB.D2T2 B4,*B5++[1]
80892E88 020C105B || MV.L2X A3,B4
80892E8C 20000011 || [ B0] B.S1 0x80892E80 (PC+0 = 0x80892e80)
80892E90 2003E1A3 || [ B0] SUB.S2 B0,1,B0
80892E94 81903624 || [ A1] LDB.D1T1 *A4++[1],A3
80892E98 009803A2 MVC.S2 B6,CSR
80892E9C 000C0362 B.S2 B3
*80892EA0 02180058 MV.L1 A6,A4
80892EA4 00004000 NOP 3

This is within the memcpy routine and just prior to returning from the function. What are the reasons why the JTAG interface would halt? I have not seen any information on any sort of exception handling for this CPU. I did read that the MVC instruction can power down the DSP, which requires an interrupt to wake up, but the value in B6 is 0x02030100 which is not enabling power down. I don't see how there could be a problem with MV.L1 since it is just copying between 2 registers. The values of A4 and B5 (memory addresses) are valid memory addresses as well. This particular memcpy is writing to the first 8 bytes in SDRAM, from what I can tell.

Thanks in advance for any information.

Best regards,
Josh Green Start a New Thread

The problem turned out to be incorrect setting of SDCTL register in the SDRAM peripheral.

Dan

P.S. You never know who is lurking here do you? Start a New Thread

Thanks, Dan. It is always good to get some feedback to close the loop.

mikedunn

On Thu, Mar 12, 2009 at 9:57 PM, Dan Dickey wrote:
> The problem turned out to be incorrect setting of SDCTL register in the
> SDRAM peripheral.
>
> Dan
>
> P.S. You never know who is lurking here do you?

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

_____________________________________ Start a New Thread