Reply by Jeff Brower July 26, 20022002-07-26
Kevin-

Sounds like you are off and running. Using your own .cmd file in CCS is not a
bad
idea in the long run, as long as it works of course. There are a lot of things
that
you can do with Sections and Memory directives that are not the easiest in CCS.

Thanks for the info on the PCI9030. We've used the 9056 before.

Jeff Brower
DSP sw/hw engineer
Signalogic Kevin Hansen wrote:
>
> Jeff,
>
> We found the answer. The mistake was in his .CMD file. I'm not sure why he
> wasn't using the .CMD file created by CCS..
>
> I used the PCI9030 from PLX as the PCI-XBUS interface. The 9030 is used in
> multiplexed mode, so not much interface logic would normally be needed.
> However, I needed the XBUS to be able to operate in any of its modes and to
> be able to communicate with a hypothetical XBUS on a daughterboard. So,
> since there could be up to three XBUS masters, I needed to build an
> external arbiter. Of course, the 9030 is target-only, but being a PCI bus
> master wasn't a requirement.
>
> Thanks again,
> Kevin
>
> At 08:02 AM 7/25/2002 -0500, Jeff Brower wrote:
> >Kevin-
> >
> >Sure, I hope everything starts working better for you. Another gotcha that I
> >remember: be sure your code does not attempt to write to program memory
> >area on the
> >C6203. Only DMA or XBUS accesses can go there.
> >
> >Also I was curious: what chip/processor has the PCI bus interface you are
> >using for
> >the C6203? The interface we did before was
> >
> > asynchronous <--> logic <--> C6203
> >
> >so we had FIFOs in the logic to handle burst transfers. As I remember the
> >XBUS
> >timing was not particularly compatible with any type of PCI or other
processor
> >without some significant logic in between.
> >
> >Jeff Brower
> >DSP sw/hw engineer
> >Signalogic



Reply by Kevin Hansen July 26, 20022002-07-26
Jeff,

We found the answer. The mistake was in his .CMD file. I'm not sure why he
wasn't using the .CMD file created by CCS..

I used the PCI9030 from PLX as the PCI-XBUS interface. The 9030 is used in
multiplexed mode, so not much interface logic would normally be needed.
However, I needed the XBUS to be able to operate in any of its modes and to
be able to communicate with a hypothetical XBUS on a daughterboard. So,
since there could be up to three XBUS masters, I needed to build an
external arbiter. Of course, the 9030 is target-only, but being a PCI bus
master wasn't a requirement.

Thanks again,
Kevin

At 08:02 AM 7/25/2002 -0500, Jeff Brower wrote:
>Kevin-
>
>Sure, I hope everything starts working better for you. Another gotcha that I
>remember: be sure your code does not attempt to write to program memory
>area on the
>C6203. Only DMA or XBUS accesses can go there.
>
>Also I was curious: what chip/processor has the PCI bus interface you are
>using for
>the C6203? The interface we did before was
>
> asynchronous <--> logic <--> C6203
>
>so we had FIFOs in the logic to handle burst transfers. As I remember the
>XBUS
>timing was not particularly compatible with any type of PCI or other processor
>without some significant logic in between.
>
>Jeff Brower
>DSP sw/hw engineer
>Signalogic


Reply by Jeff Brower July 25, 20022002-07-25
Kevin-

> Here's the setup. The JTAG port may be accessed from either an onboard
> emulator or an external emulator (through a connector). However, what I'm
> trying to do has nothing to do with CCS because I'm writing from the PCI
> bus into the XBUS. The intent is to load the program through the XBUS and
> start execution using the DSP_INT bit.
>
> The test program simply blinks a couple of LEDs located in the DSP memory
> map. If we load the program using CCS, it works fine. If we load the
> program using our loader, then start CCS and begin program execution, it
works.
>
> Stop the presses. The person that's working on this issue just came into my
> office to try the process on my hardware to make sure his board wasn't
> broken. I noticed that he asked me to start CCS at an address other than
> 0x00000000 in program memory. That looks like the problem right there, and
> maybe he doesn't have the reset vector set correctly.
>
> Thanks for sparking the idea,

Sure, I hope everything starts working better for you. Another gotcha that I
remember: be sure your code does not attempt to write to program memory area on
the
C6203. Only DMA or XBUS accesses can go there.

Also I was curious: what chip/processor has the PCI bus interface you are using
for
the C6203? The interface we did before was

asynchronous <--> logic <--> C6203

so we had FIFOs in the logic to handle burst transfers. As I remember the XBUS
timing was not particularly compatible with any type of PCI or other processor
without some significant logic in between.

Jeff Brower
DSP sw/hw engineer
Signalogic > At 12:28 PM 7/22/2002 -0500, Jeff Brower wrote:
> >Kevin-
> >
> > > We are having trouble waking up the 6203 DSP from an XBUS boot
> > > process. We can see that the code has been loaded correctly through
> > > the XBUS, but asserting DSP_INT doesn't appear to wake the DSP up.
> > > We know the code is OK because it runs if it's loaded through an
> > > emulator with Code Composer Studio. The DSP is not in RESET.
> > >
> > > Is there something simple we might be overlooking that's keeping the
> > > 6203 from booting?
> >
> >We've worked with C6203 extensively. As I recall from one project I was
> >involved in,
> >getting the DSP code to run the first time was not the easiest thing, and
> >we were not
> >able to do it unless the emulator was disconnected. I think what we did
> >is have the
> >DSP run a short loop, set a variable, and then continue to look at this
> >variable
> >using XBUS reads. Have you set CCS to run-free? Where in the code is the
> >reset
> >vector in location 0 pointing?
> >
> >Jeff Brower
> >DSP sw/hw engineer
> >Signalogic
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you want
your answer to be distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://www.yahoogroups.com/group/c6x
>
> Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/




Reply by Kevin Hansen July 24, 20022002-07-24
Jeff,

Here's the setup. The JTAG port may be accessed from either an onboard
emulator or an external emulator (through a connector). However, what I'm
trying to do has nothing to do with CCS because I'm writing from the PCI
bus into the XBUS. The intent is to load the program through the XBUS and
start execution using the DSP_INT bit.

The test program simply blinks a couple of LEDs located in the DSP memory
map. If we load the program using CCS, it works fine. If we load the
program using our loader, then start CCS and begin program execution, it works.

Stop the presses. The person that's working on this issue just came into my
office to try the process on my hardware to make sure his board wasn't
broken. I noticed that he asked me to start CCS at an address other than
0x00000000 in program memory. That looks like the problem right there, and
maybe he doesn't have the reset vector set correctly.

Thanks for sparking the idea,

Kevin

At 12:28 PM 7/22/2002 -0500, Jeff Brower wrote:
>Kevin-
>
> > We are having trouble waking up the 6203 DSP from an XBUS boot
> > process. We can see that the code has been loaded correctly through
> > the XBUS, but asserting DSP_INT doesn't appear to wake the DSP up.
> > We know the code is OK because it runs if it's loaded through an
> > emulator with Code Composer Studio. The DSP is not in RESET.
> >
> > Is there something simple we might be overlooking that's keeping the
> > 6203 from booting?
>
>We've worked with C6203 extensively. As I recall from one project I was
>involved in,
>getting the DSP code to run the first time was not the easiest thing, and
>we were not
>able to do it unless the emulator was disconnected. I think what we did
>is have the
>DSP run a short loop, set a variable, and then continue to look at this
>variable
>using XBUS reads. Have you set CCS to run-free? Where in the code is the
>reset
>vector in location 0 pointing?
>
>Jeff Brower
>DSP sw/hw engineer
>Signalogic


Reply by Jeff Brower July 22, 20022002-07-22
Kevin-

> We are having trouble waking up the 6203 DSP from an XBUS boot
> process. We can see that the code has been loaded correctly through
> the XBUS, but asserting DSP_INT doesn't appear to wake the DSP up.
> We know the code is OK because it runs if it's loaded through an
> emulator with Code Composer Studio. The DSP is not in RESET.
>
> Is there something simple we might be overlooking that's keeping the
> 6203 from booting?

We've worked with C6203 extensively. As I recall from one project I was
involved in,
getting the DSP code to run the first time was not the easiest thing, and we
were not
able to do it unless the emulator was disconnected. I think what we did is have
the
DSP run a short loop, set a variable, and then continue to look at this variable
using XBUS reads. Have you set CCS to run-free? Where in the code is the reset
vector in location 0 pointing?

Jeff Brower
DSP sw/hw engineer
Signalogic




Reply by kevjhansen July 20, 20022002-07-20
We are having trouble waking up the 6203 DSP from an XBUS boot
process. We can see that the code has been loaded correctly through
the XBUS, but asserting DSP_INT doesn't appear to wake the DSP up.
We know the code is OK because it runs if it's loaded through an
emulator with Code Composer Studio. The DSP is not in RESET.

Is there something simple we might be overlooking that's keeping the
6203 from booting?

Thank you,
Kevin