Error connecting to the target:

Hi,

I am working with CCS 3.1

Firstly a used the XDS510, via JTAG, to connect a 6713DSK with successful.

Now I am trying uses it to connect a new board with a 6713B DSP, and I have been a fatal error:

Error connecting to the target: Error 0x80000200/-1070 Fatal Error during: OCS,

Does somebody know what I have to do in order to solve this fatal error?

Thanks.

Ricardo Carvalho.

LQE - FURB

Blumenau

Brazil Start a New Thread

Hi Jeff,

On Mon, 2007-11-05 at 20:47 -0600, Jeff Brower wrote:
> Ricardo, Simon-
>
> > On 11/5/07, Ricardo Jose de Oliveira Carvalho
> wrote:
> > > Hi Make and Simon,
> >
> > > 1) I think that problem with the connection DSP and Host, via JTAG
> using TI xds510,
> >
> > Are you really using a TI XDS510 ISA card in your PC??? If not,
> > please be careful about how you refer to products. There are dozens
> > of different XDS510 class emulators in the world.
> >
> > > is on hardware, because, as sprs294b, the TMS320C6713B requires
> that both RESET and TRST resets be asserted upon power up. While RESET
> initializes the DSP core, TRST initializes the DSP emulation logic.
> >
> > It has been my experience that pulsing nTRST during powerup is a
> > convenience thing. You can manually force nTRST by executing
> xdsprobe
> > with the '-r' option [this will pulse nTRST and reset the JTAG state
> > machine].
>
> Ricardo, Simon -- do you have a 4.75k (or approx) pull-down on /TRST?
> My experience
> has been that /TRST needs to be pulled down at *power up, regardless
> of the state of
> /RESET* in order to obtain reliable JTAG operation. If DSP circuitry,
> however
> briefly, thinks that JTAG is active, things can happen that no amount
> of /RESET
> toggling can overcome.
I have not physically modified the baseboard or emulator. In a
conversation with Mike a while back I was going to throw together a
connector to look at the jtag signals, but back then it began to look
like my issue was driver related.

I can now connect to the baseboard in CCS, and sometimes I can load
executables succesfully and get to at least 1 bkpoint, but I am often
getting errors like this during debugging:

Trouble Halting Target CPU: Error 0x80000020/-1070 Fatal Error during:
Execution, An unknown error prevented the emulator from accessing the
processor in a timely fashion. It is recommended to RESET EMULATOR.
This will disconnect each target from the emulator. The targets
should then be power cycled or hard reset followed by an emureset and
reconnect to each target.
3 other operation(s) were automatically canceled as a result
Trouble Removing Breakpoint with the Action "Continue or Finish
Stepping" at 0xa1f05488: Error 0x0000000A/-1153 Error during: Memory,
Break Point, The memory at 0xA1F05488 continually indicated it was
'not ready' All memory operations currently in progress were aborted in
order to regain control of the processor. This is considered a
catastrophic event, but the debugger should still be able to access
memory and CPU registers. System state has been altered. It is
strongly advised that the processor should be reset before resuming
execution,

I disconnect, reset the emulator, re-connect in CCS and try to reload
the program

Error connecting to the target: Error 0x00000202/-1153 Error during:
Memory, OCS, The memory at 0x01BC002C continually indicated it was
'not ready' All memory operations currently in progress were aborted in
order to regain control of the processor. This is considered a
catastrophic event, but the debugger should still be able to access
memory and CPU registers.

Do you have an idea where these are coming from? Me, Emulator hardware,
DSP hardware, drivers, CCS bug or just me again.

Cheers,
Simon

>
> Ricardo, you might be seeing the need to repeatedly power on/off due
> to lack of
> pre-determined /TRST behavior at the instant of power-on.
>
> One of the worst bugs I've ever seen was a client who insisted on
> conserving
> pull-down Rs, and shared one between /TRST and a GPIO pin that was not
> used used
> (never defined as an output). Not a big deal right? Wrong. At power-on
> the DSP's
> GPIO states were undefined, and sometimes that GPIO pin would drive
> enough to
> override the pull-down. Then JTAG was briefly active... then the chip
> refused to
> behave no matter how many times /RESET was toggled. That's how I
> learned about /TRST
> the hard way.
>
> This was with a C5421 DSP back around 2000 or so, so maybe things are
> different now
> as Mike suggests, but u might wanna check...
>
> -Jeff
>
> > mikedunn
> > >
> > > 2) In my design I have tow boards: One with only the DSP and
> peripherals and other with DSP + ALTERA FPGA.
> > >
> > > 3) In a single DSP I have to try several time turn on/off the
> power to have success in connection. Boot wend connected the xprobe
> didn't run, Its indicate a error (lossless power) I will confirm the
> error number. It must be observed that this same errors appear when
> connected with DSK. I do not investigate it.
> > >
> > > In the other board I have been implementing a reset logic using an
> ALTERA FPGA, in a similar way the DSK. Not conclude it yet.
> > >
> > >
> > >
> > >
> > > Follow the answer of your questions:
> > >
> > > Have you been following the Gao thread by Simon??
> > >
> > >
> > > No, I just follow the discussion.
> > >
> > >
> > >
> > > If you have time, I would appreciate it if you could answer a few
> questions.
> > > 1. What is the exact model of your Gao emulator??
> > >
> > >
> > >
> > > I just have the GaoEmulation user manual version 3.24 (2005.12)
> for the XDS510 USB2.0 JTAG Emulator. Its came with "anghaixds510"
> drive.
> > >
> > >
> > > 2. Can you run 'xdsprobe -f gao.cfg -p 0x240 -i' successfully??
> > >
> > >
> > >
> > > No, in a similar way with DSK, Its didn't run xprobe, an error is
> indicated. I will confirm the error message in a next email
> > >
> > > 3. With CCS configured for your target, could you post the
> contents of
> > > 'C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat'
> > > [it is a text file].
> > >
> > >
> > >
> > > There are four files: ccBrd0, 1 2 and 3:
> > >
> > >
> > >
> > > ccBrd0:
> > >
> > >
> > >
> > > # config version=3.5
> > >
> > > @ CPU_1 family=tms320c671x
> > >
> > > $ sepk
> > >
> > > pod_drvr=anghaiver3.dll
> > >
> > > $ /
> > >
> > > # /
> > >
> > >
> > >
> > > ccBrd1
> > >
> > >
> > >
> > > # config version=3.5
> > >
> > > @ CPU_1 family=tms320c621x
> > >
> > > $ sepk
> > >
> > > pod_drvr=xds510.dll
> > >
> > > $ /
> > >
> > > # /
> > >
> > > ccBrd2 = ccBrd0
> > >
> > >
> > >
> > > ccBrd3
> > >
> > >
> > >
> > > # config version=3.5
> > >
> > > @ CPU_1 family=tms320c671x
> > >
> > > $ sepk
> > >
> > > pod_drvr=xds510.dll
> > >
> > > pod_port=0x0
> > >
> > > $ /
> > >
> > > $ uscif
> > >
> > > slowclk=NO
> > >
> > > tdoedge=RISE
> > >
> > > $ /
> > >
> > > # /
> > >
> > >
> > >
> > >
> > >
> > > Ricardo
> > >
> > >
> > >
> > >
> > >
> > > On 11/1/07, Ricardo Jose de Oliveira Carvalho
> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yes Michael, Now my board is connecting, via JTAG, using the Gao
> xds510.
> > > >
> > > > I was pulldown (by wrong) a EMU pin. I read the SPRA584C
> Application Report (TI) and revises may design.
> > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Ricardo ________________________________
> > De: Michael Dunn [mailto:m...@gmail.com]
> > > > Enviada: qua 31/10/2007 16:29
> > > > Para: Ricardo Jose de Oliveira Carvalho
> > > > Cc: c...
> > > > Assunto: Re: [c6x] Error connecting to the target:
> > > >
> > > >
> > > >
> > > >
> > > > Ricardo,
> > > >
> > > > Have you had any success with your Gao emulator??
> > > >
> > > > mikedunn
> > > >
> > > >
> > > > On 10/26/07, Ricardo Jose de Oliveira Carvalho > > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Michael,
> > > > >
> > > > >
> > > > >
> > > > > Thanks for the reply and tips.
> > > > >
> > > > > However I have been other error (powerless) when I try rum
> xdsprobe test on the DSK. It is connecting but the not rum xdsprob
> test? (no is clear for me)
> > > > >
> > > > > What voltage must be used on PIN 5 of the JTAG? I am using
> 3.3V and the DSK also.
> > > > >
> > > > > But the green led of the Gao XDS510 is OFF when I connect the
> DSK and ON when I connect the USB cable.
> > > > >
> > > > > Ricardo
> > > > >
> > > > >
> > > > > Ricardo,
> > > > >
> > > > > On 10/24/07, Ricardo Jose de Oliveira Carvalho
> wrote:
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I am working with CCS 3.1
> > > > > >
> > > > > > Firstly a used the XDS510, via JTAG, to connect a 6713DSK
> with successful.
> > > > > >
> > > > > > Now I am trying uses it to connect a new board with a 6713B
> DSP, and I have been a fatal error:
> > > > > >
> > > > > > Error connecting to the target: Error 0x80000200/-1070 Fatal
> Error during: OCS,
> > > > > >
> > > > > > Does somebody know what I have to do in order to solve this
> fatal error?
> > > > >
> > > > > 1. Make sure that your target is alive. Check voltages and
> clocks.
> > > > > 2. Check your JTAG scan chain. From a DOS prompt in cc/bin
> directory
> > > > > run 'xdsprobe -i'. Examine the output for successful
> completion and
> > > > > an IR len of 46 [assuming that the DSP is the only thing in
> the scan
> > > > > path]. You can compare with the DSK output.
> > > > > If you get errors, run 'xdsprobe -g -c' and check the JTAG
> connector
> > > > > pins 3 and 7 for 'toggling data', pins 9 and 11 for clocks and
> that
> > > > > pin 2 is high.
> > > > >
> > > > > mikedunn
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Ricardo Carvalho.
> > > > > >
> > > > > > LQE FURB
> > > > > >
> > > > > > Blumenau
> > > > > >
> > > > > > Brazil
>
> Start a New Thread

Ricardo, Simon-

> On 11/5/07, Ricardo Jose de Oliveira Carvalho wrote:
> > Hi Make and Simon,
>
> > 1) I think that problem with the connection DSP and Host, via JTAG using TI xds510,
>
> Are you really using a TI XDS510 ISA card in your PC??? If not,
> please be careful about how you refer to products. There are dozens
> of different XDS510 class emulators in the world.
>
> > is on hardware, because, as sprs294b, the TMS320C6713B requires that both RESET and TRST resets be asserted upon power up. While RESET initializes the DSP core, TRST initializes the DSP emulation logic.
>
> It has been my experience that pulsing nTRST during powerup is a
> convenience thing. You can manually force nTRST by executing xdsprobe
> with the '-r' option [this will pulse nTRST and reset the JTAG state
> machine].

Ricardo, Simon -- do you have a 4.75k (or approx) pull-down on /TRST? My experience
has been that /TRST needs to be pulled down at *power up, regardless of the state of
/RESET* in order to obtain reliable JTAG operation. If DSP circuitry, however
briefly, thinks that JTAG is active, things can happen that no amount of /RESET
toggling can overcome.

Ricardo, you might be seeing the need to repeatedly power on/off due to lack of
pre-determined /TRST behavior at the instant of power-on.

One of the worst bugs I've ever seen was a client who insisted on conserving
pull-down Rs, and shared one between /TRST and a GPIO pin that was not used used
(never defined as an output). Not a big deal right? Wrong. At power-on the DSP's
GPIO states were undefined, and sometimes that GPIO pin would drive enough to
override the pull-down. Then JTAG was briefly active... then the chip refused to
behave no matter how many times /RESET was toggled. That's how I learned about /TRST
the hard way.

This was with a C5421 DSP back around 2000 or so, so maybe things are different now
as Mike suggests, but u might wanna check...

-Jeff

> mikedunn
> >
> > 2) In my design I have tow boards: One with only the DSP and peripherals and other with DSP + ALTERA FPGA.
> >
> > 3) In a single DSP I have to try several time turn on/off the power to have success in connection. Boot wend connected the xprobe didn't run, Its indicate a error (lossless power) I will confirm the error number. It must be observed that this same errors appear when connected with DSK. I do not investigate it.
> >
> > In the other board I have been implementing a reset logic using an ALTERA FPGA, in a similar way the DSK. Not conclude it yet.
> >
> >
> >
> >
> > Follow the answer of your questions:
> >
> > Have you been following the Gao thread by Simon??
> >
> >
> > No, I just follow the discussion.
> >
> >
> >
> > If you have time, I would appreciate it if you could answer a few questions.
> > 1. What is the exact model of your Gao emulator??
> >
> >
> >
> > I just have the GaoEmulation user manual version 3.24 (2005.12) for the XDS510 USB2.0 JTAG Emulator. Its came with "anghaixds510" drive.
> >
> >
> > 2. Can you run 'xdsprobe -f gao.cfg -p 0x240 -i' successfully??
> >
> >
> >
> > No, in a similar way with DSK, Its didn't run xprobe, an error is indicated. I will confirm the error message in a next email
> >
> > 3. With CCS configured for your target, could you post the contents of
> > 'C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat'
> > [it is a text file].
> >
> >
> >
> > There are four files: ccBrd0, 1 2 and 3:
> >
> >
> >
> > ccBrd0:
> >
> >
> >
> > # config version=3.5
> >
> > @ CPU_1 family=tms320c671x
> >
> > $ sepk
> >
> > pod_drvr=anghaiver3.dll
> >
> > $ /
> >
> > # /
> >
> >
> >
> > ccBrd1
> >
> >
> >
> > # config version=3.5
> >
> > @ CPU_1 family=tms320c621x
> >
> > $ sepk
> >
> > pod_drvr=xds510.dll
> >
> > $ /
> >
> > # /
> >
> > ccBrd2 = ccBrd0
> >
> >
> >
> > ccBrd3
> >
> >
> >
> > # config version=3.5
> >
> > @ CPU_1 family=tms320c671x
> >
> > $ sepk
> >
> > pod_drvr=xds510.dll
> >
> > pod_port=0x0
> >
> > $ /
> >
> > $ uscif
> >
> > slowclk=NO
> >
> > tdoedge=RISE
> >
> > $ /
> >
> > # /
> >
> >
> >
> >
> >
> > Ricardo
> >
> >
> >
> >
> >
> > On 11/1/07, Ricardo Jose de Oliveira Carvalho wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yes Michael, Now my board is connecting, via JTAG, using the Gao xds510.
> > >
> > > I was pulldown (by wrong) a EMU pin. I read the SPRA584C Application Report (TI) and revises may design.
> > >
> > >
> > >
> > > Thanks.
> > >
> > >
> > >
> > >
> > >
> > > Ricardo ________________________________
> De: Michael Dunn [mailto:m...@gmail.com]
> > > Enviada: qua 31/10/2007 16:29
> > > Para: Ricardo Jose de Oliveira Carvalho
> > > Cc: c...
> > > Assunto: Re: [c6x] Error connecting to the target:
> > >
> > >
> > >
> > >
> > > Ricardo,
> > >
> > > Have you had any success with your Gao emulator??
> > >
> > > mikedunn
> > >
> > >
> > > On 10/26/07, Ricardo Jose de Oliveira Carvalho wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Michael,
> > > >
> > > >
> > > >
> > > > Thanks for the reply and tips.
> > > >
> > > > However I have been other error (powerless) when I try rum xdsprobe test on the DSK. It is connecting but the not rum xdsprob test? (no is clear for me)
> > > >
> > > > What voltage must be used on PIN 5 of the JTAG? I am using 3.3V and the DSK also.
> > > >
> > > > But the green led of the Gao XDS510 is OFF when I connect the DSK and ON when I connect the USB cable.
> > > >
> > > > Ricardo
> > > >
> > > >
> > > > Ricardo,
> > > >
> > > > On 10/24/07, Ricardo Jose de Oliveira Carvalho wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > > I am working with CCS 3.1
> > > > >
> > > > > Firstly a used the XDS510, via JTAG, to connect a 6713DSK with successful.
> > > > >
> > > > > Now I am trying uses it to connect a new board with a 6713B DSP, and I have been a fatal error:
> > > > >
> > > > > Error connecting to the target: Error 0x80000200/-1070 Fatal Error during: OCS,
> > > > >
> > > > > Does somebody know what I have to do in order to solve this fatal error?
> > > >
> > > > 1. Make sure that your target is alive. Check voltages and clocks.
> > > > 2. Check your JTAG scan chain. From a DOS prompt in cc/bin directory
> > > > run 'xdsprobe -i'. Examine the output for successful completion and
> > > > an IR len of 46 [assuming that the DSP is the only thing in the scan
> > > > path]. You can compare with the DSK output.
> > > > If you get errors, run 'xdsprobe -g -c' and check the JTAG connector
> > > > pins 3 and 7 for 'toggling data', pins 9 and 11 for clocks and that
> > > > pin 2 is high.
> > > >
> > > > mikedunn
> > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > >
> > > > > Ricardo Carvalho.
> > > > >
> > > > > LQE FURB
> > > > >
> > > > > Blumenau
> > > > >
> > > > > Brazil Start a New Thread

On 11/6/07, Simon Mushi wrote:
> Hi Jeff,
>
> On Mon, 2007-11-05 at 20:47 -0600, Jeff Brower wrote:
> > Ricardo, Simon-
> >
> > > On 11/5/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > Hi Make and Simon,
> > >
> > > > 1) I think that problem with the connection DSP and Host, via JTAG
> > using TI xds510,
> > >
> > > Are you really using a TI XDS510 ISA card in your PC??? If not,
> > > please be careful about how you refer to products. There are dozens
> > > of different XDS510 class emulators in the world.
> > >
> > > > is on hardware, because, as sprs294b, the TMS320C6713B requires
> > that both RESET and TRST resets be asserted upon power up. While RESET
> > initializes the DSP core, TRST initializes the DSP emulation logic.
> > >
> > > It has been my experience that pulsing nTRST during powerup is a
> > > convenience thing. You can manually force nTRST by executing
> > xdsprobe
> > > with the '-r' option [this will pulse nTRST and reset the JTAG state
> > > machine].
> >
> > Ricardo, Simon -- do you have a 4.75k (or approx) pull-down on /TRST?
> > My experience
> > has been that /TRST needs to be pulled down at *power up, regardless
> > of the state of
> > /RESET* in order to obtain reliable JTAG operation. If DSP circuitry,
> > however
> > briefly, thinks that JTAG is active, things can happen that no amount
> > of /RESET
> > toggling can overcome.
> I have not physically modified the baseboard or emulator. In a
> conversation with Mike a while back I was going to throw together a
> connector to look at the jtag signals, but back then it began to look
> like my issue was driver related.
>
> I can now connect to the baseboard in CCS, and sometimes I can load
> executables succesfully and get to at least 1 bkpoint, but I am often
> getting errors like this during debugging:
>
> Trouble Halting Target CPU: Error 0x80000020/-1070 Fatal Error during:
> Execution, An unknown error prevented the emulator from accessing the
> processor in a timely fashion. It is recommended to RESET EMULATOR.
> This will disconnect each target from the emulator. The targets
> should then be power cycled or hard reset followed by an emureset and
> reconnect to each target. =20
> 3 other operation(s) were automatically canceled as a result=20
> Trouble Removing Breakpoint with the Action "Continue or Finish
> Stepping" at 0xa1f05488: Error 0x0000000A/-1153 Error during: Memory,
> Break Point, The memory at 0xA1F05488 continually indicated it was
> 'not ready'

This is a daughtercard address, not a normal memory address. I assume
that your code does not reside at 0xA1F05488.

The errors above seem to have one thing in common - they occur as a
result of a user initiated action. Knowing the frequency of the errors
[ every time, every other time, 1 out of 50 times, etc.] may help
define the best approach.

Step 1:
Ensure that you can load, step, and set/clear breakpoints reliably on
a simple program that only uses internal memory and performs no I/O. I
usually use an infinite loop that manipulates a few variables [add a
few +, -, |, &, and shifts so that the code is longer than just a few
bytes. Setup the variables in a watch window, set a breakpoint
somewhere in the loop and 'animate'. This simple process will exercise
the debug commands run, set/clear breakpoint, read/write cpu
registers, and read/write memory. If it runs ok, add a printf for a
couple of the variables.
Decision:
If step 1 fails, is it at a common place or a common error message??
If step 1 fails, and you reduce it to its simplist form, does it still fail??
If step 1 still fails, goto step 3.
If step 1 passes, goto step 2.
Step 2:
Adjust the memory map to put everything in external memory and repeat
the procedures in step 1.
Decision:
If step 2 fails [and step 1 passes], you have an external memory access problem.
Check EMIF setup for your external RAM.
Write simple mem test that loads into internal memory and reads/writes
external memory. DO NOT read a memory location immediately after
writing it - it will almost always pass. A simple, reasonably
comprehensive, easy to use starter pattern is x<<24 | x<<16 | x<<8 |
x where x = (address & 0x3C) >> 2

Step 3:
You have some type of 'JTAG communication issue between CCS and the target'.
Break out a scope, and run xdsprobe with the '-g 0xAAAAAAAA -c'
option. Ignore failures [although it still troubles me, and is
probably the problem, that the emulator cannot run this simple test].
Observe TDI [pin 3], TDO [pin 7], and TCLK_RETURN [pin 9]. Pay special
attention to TCLK_RETURN - look at the edges for crisp rise and fall.
I expect to see less than 6ns - if it is noticeably greater, it has
been my experience that the DSP could have a problem responding to
"slow slopes" [I don't know what the exact spec is]. Also, you can
have reflection problems that show up as a small 'hump' on one or both
of the clock edges. If this hump occurs in the wrong voltage range,
the target sees 2 clock edges instead of one and you get errors.

mikedunn
> All memory operations currently in progress were aborted in
> order to regain control of the processor. This is considered a
> catastrophic event, but the debugger should still be able to access
> memory and CPU registers. System state has been altered. It is
> strongly advised that the processor should be reset before resuming
> execution,
>
> I disconnect, reset the emulator, re-connect in CCS and try to reload
> the program
>
> Error connecting to the target: Error 0x00000202/-1153 Error during:
> Memory, OCS, The memory at 0x01BC002C continually indicated it was
> 'not ready' All memory operations currently in progress were aborted in
> order to regain control of the processor. This is considered a
> catastrophic event, but the debugger should still be able to access
> memory and CPU registers.
>
> Do you have an idea where these are coming from? Me, Emulator hardware,
> DSP hardware, drivers, CCS bug or just me again.
>
> Cheers,
> Simon
>
> >
> > Ricardo, you might be seeing the need to repeatedly power on/off due
> > to lack of
> > pre-determined /TRST behavior at the instant of power-on.
> >
> > One of the worst bugs I've ever seen was a client who insisted on
> > conserving
> > pull-down Rs, and shared one between /TRST and a GPIO pin that was not
> > used used
> > (never defined as an output). Not a big deal right? Wrong. At power-on
> > the DSP's
> > GPIO states were undefined, and sometimes that GPIO pin would drive
> > enough to
> > override the pull-down. Then JTAG was briefly active... then the chip
> > refused to
> > behave no matter how many times /RESET was toggled. That's how I
> > learned about /TRST
> > the hard way.
> >
> > This was with a C5421 DSP back around 2000 or so, so maybe things are
> > different now
> > as Mike suggests, but u might wanna check...
> >
> > -Jeff
> >
> > > mikedunn
> > > >
> > > > 2) In my design I have tow boards: One with only the DSP and
> > peripherals and other with DSP + ALTERA FPGA.
> > > >
> > > > 3) In a single DSP I have to try several time turn on/off the
> > power to have success in connection. Boot wend connected the xprobe
> > didn't run, Its indicate a error (lossless power) I will confirm the
> > error number. It must be observed that this same errors appear when
> > connected with DSK. I do not investigate it.
> > > >
> > > > In the other board I have been implementing a reset logic using an
> > ALTERA FPGA, in a similar way the DSK. Not conclude it yet.
> > > >
> > > >
> > > >
> > > >
> > > > Follow the answer of your questions:
> > > >
> > > > Have you been following the Gao thread by Simon??
> > > >
> > > >
> > > > No, I just follow the discussion.
> > > >
> > > >
> > > >
> > > > If you have time, I would appreciate it if you could answer a few
> > questions.
> > > > 1. What is the exact model of your Gao emulator??
> > > >
> > > >
> > > >
> > > > I just have the GaoEmulation user manual version 3.24 (2005.12)
> > for the XDS510 USB2.0 JTAG Emulator. Its came with "anghaixds510"
> > drive.
> > > >
> > > >
> > > > 2. Can you run 'xdsprobe -f gao.cfg -p 0x240 -i' successfully??
> > > >
> > > >
> > > >
> > > > No, in a similar way with DSK, Its didn't run xprobe, an error is
> > indicated. I will confirm the error message in a next email
> > > >
> > > > 3. With CCS configured for your target, could you post the
> > contents of
> > > > 'C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat'
> > > > [it is a text file].
> > > >
> > > >
> > > >
> > > > There are four files: ccBrd0, 1 2 and 3:
> > > >
> > > >
> > > >
> > > > ccBrd0:
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c671x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=anghaiver3.dll
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > >
> > > >
> > > > ccBrd1
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c621x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=xds510.dll
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > > ccBrd2 = ccBrd0
> > > >
> > > >
> > > >
> > > > ccBrd3
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c671x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=xds510.dll
> > > >
> > > > pod_port=0x0
> > > >
> > > > $ /
> > > >
> > > > $ uscif
> > > >
> > > > slowclk=NO
> > > >
> > > > tdoedge=RISE
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Ricardo
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 11/1/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yes Michael, Now my board is connecting, via JTAG, using the Gao
> > xds510.
> > > > >
> > > > > I was pulldown (by wrong) a EMU pin. I read the SPRA584C
> > Application Report (TI) and revises may design.
> > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ricardo ________________________________
> > > De: Michael Dunn [mailto:m...@gmail.com]
> > > > > Enviada: qua 31/10/2007 16:29
> > > > > Para: Ricardo Jose de Oliveira Carvalho
> > > > > Cc: c...
> > > > > Assunto: Re: [c6x] Error connecting to the target:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ricardo,
> > > > >
> > > > > Have you had any success with your Gao emulator??
> > > > >
> > > > > mikedunn
> > > > >
> > > > >
> > > > > On 10/26/07, Ricardo Jose de Oliveira Carvalho > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Michael,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks for the reply and tips.
> > > > > >
> > > > > > However I have been other error (powerless) when I try rum
> > xdsprobe test on the DSK. It is connecting but the not rum xdsprob
> > test? (no is clear for me)
> > > > > >
> > > > > > What voltage must be used on PIN 5 of the JTAG? I am using
> > 3.3V and the DSK also.
> > > > > >
> > > > > > But the green led of the Gao XDS510 is OFF when I connect the
> > DSK and ON when I connect the USB cable.
> > > > > >
> > > > > > Ricardo
> > > > > >
> > > > > >
> > > > > > Ricardo,
> > > > > >
> > > > > > On 10/24/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I am working with CCS 3.1
> > > > > > >
> > > > > > > Firstly a used the XDS510, via JTAG, to connect a 6713DSK
> > with successful.
> > > > > > >
> > > > > > > Now I am trying uses it to connect a new board with a 6713B
> > DSP, and I have been a fatal error:
> > > > > > >
> > > > > > > Error connecting to the target: Error 0x80000200/-1070 Fatal
> > Error during: OCS,
> > > > > > >
> > > > > > > Does somebody know what I have to do in order to solve this
> > fatal error?
> > > > > >
> > > > > > 1. Make sure that your target is alive. Check voltages and
> > clocks.
> > > > > > 2. Check your JTAG scan chain. From a DOS prompt in cc/bin
> > directory
> > > > > > run 'xdsprobe -i'. Examine the output for successful
> > completion and
> > > > > > an IR len of 46 [assuming that the DSP is the only thing in
> > the scan
> > > > > > path]. You can compare with the DSK output.
> > > > > > If you get errors, run 'xdsprobe -g -c' and check the JTAG
> > connector
> > > > > > pins 3 and 7 for 'toggling data', pins 9 and 11 for clocks and
> > that
> > > > > > pin 2 is high.
> > > > > >
> > > > > > mikedunn
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Ricardo Carvalho.
> > > > > > >
> > > > > > > LQE FURB
> > > > > > >
> > > > > > > Blumenau
> > > > > > >
> > > > > > > Brazil
> >
> >
> >
>

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

Start a New Thread

Simon-

> > > On 11/5/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > Hi Make and Simon,
> > >
> > > > 1) I think that problem with the connection DSP and Host, via JTAG
> > using TI xds510,
> > >
> > > Are you really using a TI XDS510 ISA card in your PC??? If not,
> > > please be careful about how you refer to products. There are dozens
> > > of different XDS510 class emulators in the world.
> > >
> > > > is on hardware, because, as sprs294b, the TMS320C6713B requires
> > that both RESET and TRST resets be asserted upon power up. While RESET
> > initializes the DSP core, TRST initializes the DSP emulation logic.
> > >
> > > It has been my experience that pulsing nTRST during powerup is a
> > > convenience thing. You can manually force nTRST by executing
> > xdsprobe
> > > with the '-r' option [this will pulse nTRST and reset the JTAG state
> > > machine].
> >
> > Ricardo, Simon -- do you have a 4.75k (or approx) pull-down on /TRST?
> > My experience
> > has been that /TRST needs to be pulled down at *power up, regardless
> > of the state of
> > /RESET* in order to obtain reliable JTAG operation. If DSP circuitry,
> > however
> > briefly, thinks that JTAG is active, things can happen that no amount
> > of /RESET
> > toggling can overcome.
> I have not physically modified the baseboard or emulator. In a
> conversation with Mike a while back I was going to throw together a
> connector to look at the jtag signals, but back then it began to look
> like my issue was driver related.
>
> I can now connect to the baseboard in CCS, and sometimes I can load
> executables succesfully and get to at least 1 bkpoint, but I am often
> getting errors like this during debugging:

It's not likely that an Innovative board of any type would give you CCS errors, or
have design problems with /TRST, EMUn, or other JTAG signals. In my experience,
Innovative's JTAG circuitry is solid and well-designed. Have you asked them which
emulator they've tried and "certify" with the M6713 board? I have a feeling the
answer is not going to be GAO Tek. Whatever they suggest, you should try that first,
and make sure you have a "known good" system. Then you can start changing out
components or subsystems as needed (one at a time!).

-Jeff

> Trouble Halting Target CPU: Error 0x80000020/-1070 Fatal Error during:
> Execution, An unknown error prevented the emulator from accessing the
> processor in a timely fashion. It is recommended to RESET EMULATOR.
> This will disconnect each target from the emulator. The targets
> should then be power cycled or hard reset followed by an emureset and
> reconnect to each target.
> 3 other operation(s) were automatically canceled as a result
> Trouble Removing Breakpoint with the Action "Continue or Finish
> Stepping" at 0xa1f05488: Error 0x0000000A/-1153 Error during: Memory,
> Break Point, The memory at 0xA1F05488 continually indicated it was
> 'not ready' All memory operations currently in progress were aborted in
> order to regain control of the processor. This is considered a
> catastrophic event, but the debugger should still be able to access
> memory and CPU registers. System state has been altered. It is
> strongly advised that the processor should be reset before resuming
> execution,
>
> I disconnect, reset the emulator, re-connect in CCS and try to reload
> the program
>
> Error connecting to the target: Error 0x00000202/-1153 Error during:
> Memory, OCS, The memory at 0x01BC002C continually indicated it was
> 'not ready' All memory operations currently in progress were aborted in
> order to regain control of the processor. This is considered a
> catastrophic event, but the debugger should still be able to access
> memory and CPU registers.
>
> Do you have an idea where these are coming from? Me, Emulator hardware,
> DSP hardware, drivers, CCS bug or just me again.
>
> Cheers,
> Simon
>
> >
> > Ricardo, you might be seeing the need to repeatedly power on/off due
> > to lack of
> > pre-determined /TRST behavior at the instant of power-on.
> >
> > One of the worst bugs I've ever seen was a client who insisted on
> > conserving
> > pull-down Rs, and shared one between /TRST and a GPIO pin that was not
> > used used
> > (never defined as an output). Not a big deal right? Wrong. At power-on
> > the DSP's
> > GPIO states were undefined, and sometimes that GPIO pin would drive
> > enough to
> > override the pull-down. Then JTAG was briefly active... then the chip
> > refused to
> > behave no matter how many times /RESET was toggled. That's how I
> > learned about /TRST
> > the hard way.
> >
> > This was with a C5421 DSP back around 2000 or so, so maybe things are
> > different now
> > as Mike suggests, but u might wanna check...
> >
> > -Jeff
> >
> > > mikedunn
> > > >
> > > > 2) In my design I have tow boards: One with only the DSP and
> > peripherals and other with DSP + ALTERA FPGA.
> > > >
> > > > 3) In a single DSP I have to try several time turn on/off the
> > power to have success in connection. Boot wend connected the xprobe
> > didn't run, Its indicate a error (lossless power) I will confirm the
> > error number. It must be observed that this same errors appear when
> > connected with DSK. I do not investigate it.
> > > >
> > > > In the other board I have been implementing a reset logic using an
> > ALTERA FPGA, in a similar way the DSK. Not conclude it yet.
> > > >
> > > >
> > > >
> > > >
> > > > Follow the answer of your questions:
> > > >
> > > > Have you been following the Gao thread by Simon??
> > > >
> > > >
> > > > No, I just follow the discussion.
> > > >
> > > >
> > > >
> > > > If you have time, I would appreciate it if you could answer a few
> > questions.
> > > > 1. What is the exact model of your Gao emulator??
> > > >
> > > >
> > > >
> > > > I just have the GaoEmulation user manual version 3.24 (2005.12)
> > for the XDS510 USB2.0 JTAG Emulator. Its came with "anghaixds510"
> > drive.
> > > >
> > > >
> > > > 2. Can you run 'xdsprobe -f gao.cfg -p 0x240 -i' successfully??
> > > >
> > > >
> > > >
> > > > No, in a similar way with DSK, Its didn't run xprobe, an error is
> > indicated. I will confirm the error message in a next email
> > > >
> > > > 3. With CCS configured for your target, could you post the
> > contents of
> > > > 'C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat'
> > > > [it is a text file].
> > > >
> > > >
> > > >
> > > > There are four files: ccBrd0, 1 2 and 3:
> > > >
> > > >
> > > >
> > > > ccBrd0:
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c671x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=anghaiver3.dll
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > >
> > > >
> > > > ccBrd1
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c621x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=xds510.dll
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > > ccBrd2 = ccBrd0
> > > >
> > > >
> > > >
> > > > ccBrd3
> > > >
> > > >
> > > >
> > > > # config version=3.5
> > > >
> > > > @ CPU_1 family=tms320c671x
> > > >
> > > > $ sepk
> > > >
> > > > pod_drvr=xds510.dll
> > > >
> > > > pod_port=0x0
> > > >
> > > > $ /
> > > >
> > > > $ uscif
> > > >
> > > > slowclk=NO
> > > >
> > > > tdoedge=RISE
> > > >
> > > > $ /
> > > >
> > > > # /
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Ricardo
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 11/1/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yes Michael, Now my board is connecting, via JTAG, using the Gao
> > xds510.
> > > > >
> > > > > I was pulldown (by wrong) a EMU pin. I read the SPRA584C
> > Application Report (TI) and revises may design.
> > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ricardo ________________________________
> > > De: Michael Dunn [mailto:m...@gmail.com]
> > > > > Enviada: qua 31/10/2007 16:29
> > > > > Para: Ricardo Jose de Oliveira Carvalho
> > > > > Cc: c...
> > > > > Assunto: Re: [c6x] Error connecting to the target:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ricardo,
> > > > >
> > > > > Have you had any success with your Gao emulator??
> > > > >
> > > > > mikedunn
> > > > >
> > > > >
> > > > > On 10/26/07, Ricardo Jose de Oliveira Carvalho > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Michael,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks for the reply and tips.
> > > > > >
> > > > > > However I have been other error (powerless) when I try rum
> > xdsprobe test on the DSK. It is connecting but the not rum xdsprob
> > test? (no is clear for me)
> > > > > >
> > > > > > What voltage must be used on PIN 5 of the JTAG? I am using
> > 3.3V and the DSK also.
> > > > > >
> > > > > > But the green led of the Gao XDS510 is OFF when I connect the
> > DSK and ON when I connect the USB cable.
> > > > > >
> > > > > > Ricardo
> > > > > >
> > > > > >
> > > > > > Ricardo,
> > > > > >
> > > > > > On 10/24/07, Ricardo Jose de Oliveira Carvalho
> > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I am working with CCS 3.1
> > > > > > >
> > > > > > > Firstly a used the XDS510, via JTAG, to connect a 6713DSK
> > with successful.
> > > > > > >
> > > > > > > Now I am trying uses it to connect a new board with a 6713B
> > DSP, and I have been a fatal error:
> > > > > > >
> > > > > > > Error connecting to the target: Error 0x80000200/-1070 Fatal
> > Error during: OCS,
> > > > > > >
> > > > > > > Does somebody know what I have to do in order to solve this
> > fatal error?
> > > > > >
> > > > > > 1. Make sure that your target is alive. Check voltages and
> > clocks.
> > > > > > 2. Check your JTAG scan chain. From a DOS prompt in cc/bin
> > directory
> > > > > > run 'xdsprobe -i'. Examine the output for successful
> > completion and
> > > > > > an IR len of 46 [assuming that the DSP is the only thing in
> > the scan
> > > > > > path]. You can compare with the DSK output.
> > > > > > If you get errors, run 'xdsprobe -g -c' and check the JTAG
> > connector
> > > > > > pins 3 and 7 for 'toggling data', pins 9 and 11 for clocks and
> > that
> > > > > > pin 2 is high.
> > > > > >
> > > > > > mikedunn
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Ricardo Carvalho.
> > > > > > >
> > > > > > > LQE FURB
> > > > > > >
> > > > > > > Blumenau
> > > > > > >
> > > > > > > Brazil Start a New Thread