Hi
Im chandrasekha from BEL, Chennai, India. We developed
TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
spectrum digital emulator drivers in PC. First time tried to connect
the board with CCS3.3 through XDS 510 USB emulator but could not
succeeded to establish the connection. The error we are facing is
" Error Connecting to Target
Bad Target Silicon Revision Number
Please check your multi-processor configuration.
The number of devices in the JTAG scan path
must be correct for the silicon revision to be read.
Or, you may have selected the wrong DSP device driver."
But it is passing diagnostic test. what is the minimum GEL file
required to connect CCS with Target? what is the latest version for
CCS and emulator drivers to support TMS320C6727 DSP?
Can you suggest solution to solve this problem.
Best Regards
Chandra Sekhar
TMS320C6727 DSP HELP
Started by ●April 2, 2008
Reply by ●April 2, 20082008-04-02
Hi Chandra ,
On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
wrote:
> Hi
>
> Im chandrasekha from BEL, Chennai, India. We developed
> TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> spectrum digital emulator drivers in PC. First time tried to connect
> the board with CCS3.3 through XDS 510 USB emulator but could not
> succeeded to establish the connection. The error we are facing is
>
> " Error Connecting to Target
> Bad Target Silicon Revision Number
> Please check your multi-processor configuration.
> The number of devices in the JTAG scan path
> must be correct for the silicon revision to be read.
> Or, you may have selected the wrong DSP device driver."
>
> But it is passing diagnostic test. what is the minimum GEL file
> required to connect CCS with Target?
You can connect to a 6727 without a GEL file.
> what is the latest version for
> CCS and emulator drivers to support TMS320C6727 DSP?
I believe that any version of CCS 3.3 will work.
If you have the latest SD drivers from their web site, you should be
okay [they have been supporting 6727 for about 2 years]
> Can you suggest solution to solve this problem.
When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
A common mistake when connecting to 6727 is to configure it
incorrectly. When looking at a correct configuration in CCS setup, you
should see an '8 bit bypass' with the 6727 device below it.
mikedunn
>
> Best Regards
> Chandra Sekhar
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
wrote:
> Hi
>
> Im chandrasekha from BEL, Chennai, India. We developed
> TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> spectrum digital emulator drivers in PC. First time tried to connect
> the board with CCS3.3 through XDS 510 USB emulator but could not
> succeeded to establish the connection. The error we are facing is
>
> " Error Connecting to Target
> Bad Target Silicon Revision Number
> Please check your multi-processor configuration.
> The number of devices in the JTAG scan path
> must be correct for the silicon revision to be read.
> Or, you may have selected the wrong DSP device driver."
>
> But it is passing diagnostic test. what is the minimum GEL file
> required to connect CCS with Target?
You can connect to a 6727 without a GEL file.
> what is the latest version for
> CCS and emulator drivers to support TMS320C6727 DSP?
I believe that any version of CCS 3.3 will work.
If you have the latest SD drivers from their web site, you should be
okay [they have been supporting 6727 for about 2 years]
> Can you suggest solution to solve this problem.
When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
A common mistake when connecting to 6727 is to configure it
incorrectly. When looking at a correct configuration in CCS setup, you
should see an '8 bit bypass' with the 6727 device below it.
mikedunn
>
> Best Regards
> Chandra Sekhar
>
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●April 2, 20082008-04-02
Mike-
> On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
> wrote:
> > Hi
> >
> > Im chandrasekha from BEL, Chennai, India. We developed
> > TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> > spectrum digital emulator drivers in PC. First time tried to connect
> > the board with CCS3.3 through XDS 510 USB emulator but could not
> > succeeded to establish the connection. The error we are facing is
> >
> > " Error Connecting to Target
> > Bad Target Silicon Revision Number
> > Please check your multi-processor configuration.
> > The number of devices in the JTAG scan path
> > must be correct for the silicon revision to be read.
> > Or, you may have selected the wrong DSP device driver."
> >
> > But it is passing diagnostic test. what is the minimum GEL file
> > required to connect CCS with Target?
>
> You can connect to a 6727 without a GEL file.
>
> > what is the latest version for
> > CCS and emulator drivers to support TMS320C6727 DSP?
>
> I believe that any version of CCS 3.3 will work.
> If you have the latest SD drivers from their web site, you should be
> okay [they have been supporting 6727 for about 2 years]
> > Can you suggest solution to solve this problem.
>
> When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
> A common mistake when connecting to 6727 is to configure it
> incorrectly. When looking at a correct configuration in CCS setup, you
> should see an '8 bit bypass' with the 6727 device below it.
What is the 8-bit bypass for? Is there a device within a device in the 6727, like a
Flash or something, that is being bypassed in the CCS setup?
-Jeff
> On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
> wrote:
> > Hi
> >
> > Im chandrasekha from BEL, Chennai, India. We developed
> > TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> > spectrum digital emulator drivers in PC. First time tried to connect
> > the board with CCS3.3 through XDS 510 USB emulator but could not
> > succeeded to establish the connection. The error we are facing is
> >
> > " Error Connecting to Target
> > Bad Target Silicon Revision Number
> > Please check your multi-processor configuration.
> > The number of devices in the JTAG scan path
> > must be correct for the silicon revision to be read.
> > Or, you may have selected the wrong DSP device driver."
> >
> > But it is passing diagnostic test. what is the minimum GEL file
> > required to connect CCS with Target?
>
> You can connect to a 6727 without a GEL file.
>
> > what is the latest version for
> > CCS and emulator drivers to support TMS320C6727 DSP?
>
> I believe that any version of CCS 3.3 will work.
> If you have the latest SD drivers from their web site, you should be
> okay [they have been supporting 6727 for about 2 years]
> > Can you suggest solution to solve this problem.
>
> When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
> A common mistake when connecting to 6727 is to configure it
> incorrectly. When looking at a correct configuration in CCS setup, you
> should see an '8 bit bypass' with the 6727 device below it.
What is the 8-bit bypass for? Is there a device within a device in the 6727, like a
Flash or something, that is being bypassed in the CCS setup?
-Jeff
Reply by ●April 2, 20082008-04-02
Hi Jeff,
On 4/2/08, Jeff Brower wrote:
> Mike-
>
> > On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
> > wrote:
> > > Hi
> > >
> > > Im chandrasekha from BEL, Chennai, India. We developed
> > > TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> > > spectrum digital emulator drivers in PC. First time tried to connect
> > > the board with CCS3.3 through XDS 510 USB emulator but could not
> > > succeeded to establish the connection. The error we are facing is
> > >
> > > " Error Connecting to Target
> > > Bad Target Silicon Revision Number
> > > Please check your multi-processor configuration.
> > > The number of devices in the JTAG scan path
> > > must be correct for the silicon revision to be read.
> > > Or, you may have selected the wrong DSP device driver."
> > >
> > > But it is passing diagnostic test. what is the minimum GEL file
> > > required to connect CCS with Target?
> >
> > You can connect to a 6727 without a GEL file.
> >
> > > what is the latest version for
> > > CCS and emulator drivers to support TMS320C6727 DSP?
> >
> > I believe that any version of CCS 3.3 will work.
> > If you have the latest SD drivers from their web site, you should be
> > okay [they have been supporting 6727 for about 2 years]
> > > Can you suggest solution to solve this problem.
> >
> > When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
> > A common mistake when connecting to 6727 is to configure it
> > incorrectly. When looking at a correct configuration in CCS setup, you
> > should see an '8 bit bypass' with the 6727 device below it.
>
> What is the 8-bit bypass for?
This is what I understand from some TI engineers:
Short answer - special chip test access to DSP internals.
Long answer -
C6x devices have implemented 'special factory test access' in a variety of ways.
c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
[one up and one down, I don't remember which] to access 'test stuff'.
The first time that I ran into this [due to a new board short], it
drove me a little crazy until i saw the 'weird IR length' with
xdsprobe.
c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
their test tools to get to it.
c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
There is apparently some way the test guys get to the test logic
through some magical subpath.
> Is there a device within a device in the 6727, like a
> Flash or something, that is being bypassed in the CCS setup?
The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
The similar DA7xx devicesuse a customer specified custom masked ROM.
There is no Flash to the best of my knowledge.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 4/2/08, Jeff Brower wrote:
> Mike-
>
> > On Wed, Apr 2, 2008 at 12:53 AM, chsekharprattipati
> > wrote:
> > > Hi
> > >
> > > Im chandrasekha from BEL, Chennai, India. We developed
> > > TMSS320C6727 DSP Custom board. We installed CCS 3.3 and latest
> > > spectrum digital emulator drivers in PC. First time tried to connect
> > > the board with CCS3.3 through XDS 510 USB emulator but could not
> > > succeeded to establish the connection. The error we are facing is
> > >
> > > " Error Connecting to Target
> > > Bad Target Silicon Revision Number
> > > Please check your multi-processor configuration.
> > > The number of devices in the JTAG scan path
> > > must be correct for the silicon revision to be read.
> > > Or, you may have selected the wrong DSP device driver."
> > >
> > > But it is passing diagnostic test. what is the minimum GEL file
> > > required to connect CCS with Target?
> >
> > You can connect to a 6727 without a GEL file.
> >
> > > what is the latest version for
> > > CCS and emulator drivers to support TMS320C6727 DSP?
> >
> > I believe that any version of CCS 3.3 will work.
> > If you have the latest SD drivers from their web site, you should be
> > okay [they have been supporting 6727 for about 2 years]
> > > Can you suggest solution to solve this problem.
> >
> > When you ran SDconfig, it should have shown 54 IR bits and 2 devices.
> > A common mistake when connecting to 6727 is to configure it
> > incorrectly. When looking at a correct configuration in CCS setup, you
> > should see an '8 bit bypass' with the 6727 device below it.
>
> What is the 8-bit bypass for?
This is what I understand from some TI engineers:
Short answer - special chip test access to DSP internals.
Long answer -
C6x devices have implemented 'special factory test access' in a variety of ways.
c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
[one up and one down, I don't remember which] to access 'test stuff'.
The first time that I ran into this [due to a new board short], it
drove me a little crazy until i saw the 'weird IR length' with
xdsprobe.
c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
their test tools to get to it.
c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
There is apparently some way the test guys get to the test logic
through some magical subpath.
> Is there a device within a device in the 6727, like a
> Flash or something, that is being bypassed in the CCS setup?
The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
The similar DA7xx devicesuse a customer specified custom masked ROM.
There is no Flash to the best of my knowledge.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●April 2, 20082008-04-02
Mike-
> > What is the 8-bit bypass for?
>
> This is what I understand from some TI engineers:
> Short answer - special chip test access to DSP internals.
> Long answer -
> C6x devices have implemented 'special factory test access' in a variety of ways.
> c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
> [one up and one down, I don't remember which] to access 'test stuff'.
> The first time that I ran into this [due to a new board short], it
> drove me a little crazy until i saw the 'weird IR length' with
> xdsprobe.
> c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
> their test tools to get to it.
Ok... internal test access seen as another device on the JTAG chain, that's one way
to do it. So C7627 doesn't depend on EMUn signals?
> c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
> There is apparently some way the test guys get to the test logic
> through some magical subpath.
> > Is there a device within a device in the 6727, like a
> > Flash or something, that is being bypassed in the CCS setup?
> The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
> The similar DA7xx devicesuse a customer specified custom masked ROM.
> There is no Flash to the best of my knowledge.
Yes I get it now -- all about test access. Thanks.
-Jeff
> > What is the 8-bit bypass for?
>
> This is what I understand from some TI engineers:
> Short answer - special chip test access to DSP internals.
> Long answer -
> C6x devices have implemented 'special factory test access' in a variety of ways.
> c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
> [one up and one down, I don't remember which] to access 'test stuff'.
> The first time that I ran into this [due to a new board short], it
> drove me a little crazy until i saw the 'weird IR length' with
> xdsprobe.
> c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
> their test tools to get to it.
Ok... internal test access seen as another device on the JTAG chain, that's one way
to do it. So C7627 doesn't depend on EMUn signals?
> c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
> There is apparently some way the test guys get to the test logic
> through some magical subpath.
> > Is there a device within a device in the 6727, like a
> > Flash or something, that is being bypassed in the CCS setup?
> The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
> The similar DA7xx devicesuse a customer specified custom masked ROM.
> There is no Flash to the best of my knowledge.
Yes I get it now -- all about test access. Thanks.
-Jeff
Reply by ●April 2, 20082008-04-02
Jeff,
On 4/2/08, Jeff Brower wrote:
> Mike-
>
> > > What is the 8-bit bypass for?
> >
> > This is what I understand from some TI engineers:
> > Short answer - special chip test access to DSP internals.
> > Long answer -
> > C6x devices have implemented 'special factory test access' in a variety of ways.
> > c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
> > [one up and one down, I don't remember which] to access 'test stuff'.
> > The first time that I ran into this [due to a new board short], it
> > drove me a little crazy until i saw the 'weird IR length' with
> > xdsprobe.
> > c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
> > their test tools to get to it.
>
> Ok... internal test access seen as another device on the JTAG chain, that's one way
> to do it.
The c672x appears to be yet another c67 device that was 'caught in the
generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
my *personal guess* is that the test infrastructure was new/updated
and was designed so that it could 'hide behind' an ICEpick - but there
was no place to hide :-)
> So C7627 doesn't depend on EMUn signals?
As long as the EMU signals are pulled high, the c672x [and any other
c6x device that I know of] doesn't care and will happily perform basic
debug with CCS.
>
> > c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
> > There is apparently some way the test guys get to the test logic
> > through some magical subpath.
> > > Is there a device within a device in the 6727, like a
> > > Flash or something, that is being bypassed in the CCS setup?
> > The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
> > The similar DA7xx devicesuse a customer specified custom masked ROM.
> > There is no Flash to the best of my knowledge.
>
> Yes I get it now -- all about test access. Thanks.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On 4/2/08, Jeff Brower wrote:
> Mike-
>
> > > What is the 8-bit bypass for?
> >
> > This is what I understand from some TI engineers:
> > Short answer - special chip test access to DSP internals.
> > Long answer -
> > C6x devices have implemented 'special factory test access' in a variety of ways.
> > c62xx/670x/671x and maybe c64 use a special 'EMU pin configuration'
> > [one up and one down, I don't remember which] to access 'test stuff'.
> > The first time that I ran into this [due to a new board short], it
> > drove me a little crazy until i saw the 'weird IR length' with
> > xdsprobe.
> > c672x has a special 'test device'. They use 8 bit IR + 46 bypass on
> > their test tools to get to it.
>
> Ok... internal test access seen as another device on the JTAG chain, that's one way
> to do it.
The c672x appears to be yet another c67 device that was 'caught in the
generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
my *personal guess* is that the test infrastructure was new/updated
and was designed so that it could 'hide behind' an ICEpick - but there
was no place to hide :-)
> So C7627 doesn't depend on EMUn signals?
As long as the EMU signals are pulled high, the c672x [and any other
c6x device that I know of] doesn't care and will happily perform basic
debug with CCS.
>
> > c64+ uses 'ICEpick' which is a 'JTAG router' to get to each DSP/ARM.
> > There is apparently some way the test guys get to the test logic
> > through some magical subpath.
> > > Is there a device within a device in the 6727, like a
> > > Flash or something, that is being bypassed in the CCS setup?
> > The c672x devices use a masked ROM with DSP/BIOS [and some other stuff] in it.
> > The similar DA7xx devicesuse a customer specified custom masked ROM.
> > There is no Flash to the best of my knowledge.
>
> Yes I get it now -- all about test access. Thanks.
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●April 2, 20082008-04-02
Mike-
> The c672x appears to be yet another c67 device that was 'caught in the
> generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
> register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
> my *personal guess* is that the test infrastructure was new/updated
> and was designed so that it could 'hide behind' an ICEpick - but there
> was no place to hide :-)
My speculation is that once a floating-point audio DSP was specified "we need this"
by marketing, TI engineering management told the worker bees something like "take
blocks and modules from existing devices and put something together. And by the way,
keep it very cheap". I.e. not a lot of new design work was allowed.
> > So C7627 doesn't depend on EMUn signals?
> As long as the EMU signals are pulled high, the c672x [and any other
> c6x device that I know of] doesn't care and will happily perform basic
> debug with CCS.
I was thinking that with multiple internal devices appearing on the JTAG chain, the
EMUn signals might no longer be needed. It sounds like they are still there on C6727
and serve a purpose.
-Jeff
> The c672x appears to be yet another c67 device that was 'caught in the
> generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
> register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
> my *personal guess* is that the test infrastructure was new/updated
> and was designed so that it could 'hide behind' an ICEpick - but there
> was no place to hide :-)
My speculation is that once a floating-point audio DSP was specified "we need this"
by marketing, TI engineering management told the worker bees something like "take
blocks and modules from existing devices and put something together. And by the way,
keep it very cheap". I.e. not a lot of new design work was allowed.
> > So C7627 doesn't depend on EMUn signals?
> As long as the EMU signals are pulled high, the c672x [and any other
> c6x device that I know of] doesn't care and will happily perform basic
> debug with CCS.
I was thinking that with multiple internal devices appearing on the JTAG chain, the
EMUn signals might no longer be needed. It sounds like they are still there on C6727
and serve a purpose.
-Jeff
Reply by ●April 3, 20082008-04-03
Jeff,
On Wed, Apr 2, 2008 at 8:00 PM, Jeff Brower wrote:
> Mike-
> > The c672x appears to be yet another c67 device that was 'caught in the
> > generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
> > register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
> > my *personal guess* is that the test infrastructure was new/updated
> > and was designed so that it could 'hide behind' an ICEpick - but there
> > was no place to hide :-)
>
> My speculation is that once a floating-point audio DSP was specified "we need this"
> by marketing, TI engineering management told the worker bees something like "take
> blocks and modules from existing devices and put something together. And by the way,
> keep it very cheap". I.e. not a lot of new design work was allowed.
> > > So C7627 doesn't depend on EMUn signals?
> > As long as the EMU signals are pulled high, the c672x [and any other
> > c6x device that I know of] doesn't care and will happily perform basic
> > debug with CCS.
>
> I was thinking that with multiple internal devices appearing on the JTAG chain, the
> EMUn signals might no longer be needed. It sounds like they are still there on C6727
> and serve a purpose.
EMU pins - everyone who has read the right docs or looked at a
schematic or pinout for the 14 pin header "knows about them". But very
few really understand them. People worry about them when they
shouldn't and ignore them when they should be ckecking them.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Wed, Apr 2, 2008 at 8:00 PM, Jeff Brower wrote:
> Mike-
> > The c672x appears to be yet another c67 device that was 'caught in the
> > generation gap'. Since it seems to be part 'some 6711/6713' + 'c64
> > register set' + ROM + 'first c6x watchdog' + 'new cache' + 'new DMA',
> > my *personal guess* is that the test infrastructure was new/updated
> > and was designed so that it could 'hide behind' an ICEpick - but there
> > was no place to hide :-)
>
> My speculation is that once a floating-point audio DSP was specified "we need this"
> by marketing, TI engineering management told the worker bees something like "take
> blocks and modules from existing devices and put something together. And by the way,
> keep it very cheap". I.e. not a lot of new design work was allowed.
> > > So C7627 doesn't depend on EMUn signals?
> > As long as the EMU signals are pulled high, the c672x [and any other
> > c6x device that I know of] doesn't care and will happily perform basic
> > debug with CCS.
>
> I was thinking that with multiple internal devices appearing on the JTAG chain, the
> EMUn signals might no longer be needed. It sounds like they are still there on C6727
> and serve a purpose.
EMU pins - everyone who has read the right docs or looked at a
schematic or pinout for the 14 pin header "knows about them". But very
few really understand them. People worry about them when they
shouldn't and ignore them when they should be ckecking them.
mikedunn
>
> -Jeff
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
