AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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 > > _____________________________________

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )