Just for everyone's information, I got the following response from ADI. I know that the SPI bus is full duplex, but nowhere in the documentation does it say that the SPIRX must be at least partially empty before the SPITX will shift out data. I tried disabling the MISO pin with the DMISO bit, but that didn't help any. I should not have assumed that if the GM bit is clear, incoming data that gets overwritten would be discarded and the SPI port would basically ignore it. "I have contacted the designers regarding your problem. I was told that since SPI in LCHH is intended to be full duplex, the SPICLK will stall on transmit buffer becoming empty OR on receive buffer becoming full. This is the expected behavior from the SPI. Dummy reads from the receive buffer will have to be done even if the received data is not of interest. Please insert a dummy read of receive buffer in the SPI transmit interrupt service routine in order to avoid the problem that you are facing. This will be mentioned clearly in the next version of the hardware reference manual. We apologize for the inconvenience caused." I hope this will prevent someone else from running around so much on this in the future. Robert Allen Senior Software Engineer Goodrich Sensor Systems --- In , h h <hh_ca@y...> wrote: > I had a whole lot of SPI fun on the 21161N with the > 21161N configured as a slave. I was told by an AD > field support engineer that there were some problems > with their dsp revision 1.0(or 1.1?). The newer > revision 1.2 and above is supposed to solve those > issues. So if you are having problems with 21161 SPI, > check the hardware revision. > > __________________________________ >

I spoke too soon!! After setting those two bits, I was able to transmit a single word without getting the two extra words. When I tried transmitting more data, I ran into another problem!! I am using the SPI by core access, not DMA. I have a buffer with 5 words to transmit. I can write out the first two, but the next two don't come out and the 5th causes a core hang, because I am writing to a full FIFO. For some reason, the data stops coming out of the SPITX. I haven't written to the SPICTL or anything. I don't understand. ADI is looking at it, but I don't have much confidence in them being able to help. They weren't the ones who helped with the my first problem. Their suggestion, so far is to use DMA. I would rather just have the thing work like it's supposed to. If I clear those two bits, I can write as many words out as I want. Of course, I have a problem writing out less than 3 words like before! This is getting very frustrating. I have 6 devices on the SPI, that I need to talk to. I am beginning to doubt that I will be able to get any of this working!!! Robert Allen, Senior Software Engineer Goodrich Sensor Systems --- In , "rallen_prsch911" <rallen_prsch911@y...> wrote: > I have one of the 21161N EZ-KITs, and it has rev 1.2 chip on it, and > it was still acting up. > > Al Clark steered me to the documentation errata, that states both > SPRINT and SPTINT bits need to be set for correct operation of the > SPI hardware. After I enable the interrupts, things worked fine. > > Thanks for the input. > > Robert Allen > Senior Software Engineer > Goodrich Sensor Systems > > --- In , h h <hh_ca@y...> wrote: > > I had a whole lot of SPI fun on the 21161N with the > > 21161N configured as a slave. I was told by an AD > > field support engineer that there were some problems > > with their dsp revision 1.0(or 1.1?). The newer > > revision 1.2 and above is supposed to solve those > > issues. So if you are having problems with 21161 SPI, > > check the hardware revision. > > > > > > > > __________________________________ > >

Calculate the cost/benefit of having bus driver. Could think of alternatively using just a serial IF to talk to each DSP from host side. It mostly depend on teh amount of data you need to transfer. ADSP21161 has nice paralell independet ports for that. This chip makes many things much easier. ----- Original Message ----- From: "Mike Rosing" <> To: "Steve Holle" <> Cc: <> Sent: Wednesday, September 03, 2003 8:03 PM Subject: Re: [adsp] ADSP-21065L to Coldfire > On Wed, 3 Sep 2003, Steve Holle wrote: > > > Each 21065L will have it's own SRAM and each host port will be mapped into > > a separate memory mapped area in the Coldfire. > > But data bus is common (or how else does Coldfire talk to each 21065?). > If every dsp has it's own address and data bus, and you use a tristate > switch to connect the Coldfire to one dsp at a time, you'd have a very > fast system since each dsp would only have to relinquish its bus when > the Coldfire needs to get in. > > A very nice toy :-) Have fun with it! > > Patience, persistence, truth, > Dr. mike > > _____________________________________ > 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://groups.yahoo.com/group/adsp > > Other Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/

There are issues with the earlier silicon. The biggest issue was with the PLL. All of our boards use Rev 1.2 Silicon. Here is the answer to the SPI problem You *HAVE* to set both interrupt enables (SPRINT, SPTINT) in the SPICTL register. This isn't listed in the Chip's errata. It is buried in the "documentation errata" but is not easy to find. Also, there's some garbage in the 21161 manual's example SPI code about writing two values to the SPI transmit register before you enable it. If you try that, it causes more problems that it solves. I think they wrote that sample code with an earlier version of the silicon. Enable those two bits, and write SPI code like you normally would, and you should be OK. Question: >I am just starting trying to use it, and I have found some curious >behavior. No matter what configuration I put ni SPICTL, when I write >to SPITX, I get three words transmitted out. The first word is the >correct length and data. The next two words have 0's for the data, >but the right word length. I don't want these two extra words to >come out. I am not hooked to any other devices (that I know). I am >using the ADI development kit, so I know what the schematic tells >me. I think that I have the relevant devices disconnected from the >SPI bus. >__________________________________ >_____________________________________ >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://groups.yahoo.com/group/adsp > >Other Groups: http://www.dsprelated.com/groups.php3 >">http://docs.yahoo.com/info/terms/ Al Clark Danville Signal Processing, Inc. -------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com

I have one of the 21161N EZ-KITs, and it has rev 1.2 chip on it, and it was still acting up. Al Clark steered me to the documentation errata, that states both SPRINT and SPTINT bits need to be set for correct operation of the SPI hardware. After I enable the interrupts, things worked fine. Thanks for the input. Robert Allen Senior Software Engineer Goodrich Sensor Systems --- In , h h <hh_ca@y...> wrote: > I had a whole lot of SPI fun on the 21161N with the > 21161N configured as a slave. I was told by an AD > field support engineer that there were some problems > with their dsp revision 1.0(or 1.1?). The newer > revision 1.2 and above is supposed to solve those > issues. So if you are having problems with 21161 SPI, > check the hardware revision. > > __________________________________ >

At 11:03 AM 9/3/2003 -0700, Mike Rosing wrote: >On Wed, 3 Sep 2003, Steve Holle wrote: > > > Each 21065L will have it's own SRAM and each host port will be mapped into > > a separate memory mapped area in the Coldfire. > >But data bus is common (or how else does Coldfire talk to each 21065?). >If every dsp has it's own address and data bus, and you use a tristate >switch to connect the Coldfire to one dsp at a time, you'd have a very >fast system since each dsp would only have to relinquish its bus when >the Coldfire needs to get in. > >A very nice toy :-) Have fun with it! > >Patience, persistence, truth, >Dr. mike That's exactly what we are doing, with tristate buffers controlled by each DSPs bus grant signals. >_____________________________________ >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://groups.yahoo.com/group/adsp > >Other Groups: http://www.dsprelated.com/groups.php3 >">http://docs.yahoo.com/info/terms/

I had a whole lot of SPI fun on the 21161N with the 21161N configured as a slave. I was told by an AD field support engineer that there were some problems with their dsp revision 1.0(or 1.1?). The newer revision 1.2 and above is supposed to solve those issues. So if you are having problems with 21161 SPI, check the hardware revision. __________________________________

On Wed, 3 Sep 2003, Steve Holle wrote: > Each 21065L will have it's own SRAM and each host port will be mapped into > a separate memory mapped area in the Coldfire. But data bus is common (or how else does Coldfire talk to each 21065?). If every dsp has it's own address and data bus, and you use a tristate switch to connect the Coldfire to one dsp at a time, you'd have a very fast system since each dsp would only have to relinquish its bus when the Coldfire needs to get in. A very nice toy :-) Have fun with it! Patience, persistence, truth, Dr. mike

At 08:32 AM 9/3/2003 -0700, Mike Rosing wrote: >On Wed, 3 Sep 2003, Steve Holle wrote: > > > We were hoping to use DMA to transfer from SRAM to the host port. Is this > > workable? > >Yes. I'm not sure about bus contention, so make sure only one 21065 >has access to the SRAM at a time. Other than that, should work fine! > >Patience, persistence, truth, >Dr. mike Each 21065L will have it's own SRAM and each host port will be mapped into a separate memory mapped area in the Coldfire. >_____________________________________ >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://groups.yahoo.com/group/adsp > >Other Groups: http://www.dsprelated.com/groups.php3 >">http://docs.yahoo.com/info/terms/