Hi Wei,

You are correct. RRDY will assert after reception of the first full
frame. We poll for this event and read the McBSP. We are unable to
repeat the process for the second frame without using FSR again.

I read you last email on using CLKX and FSX in SPI slave mode. That is
a very interesting find! I will look into that first thing Monday
morning.

Victor

--- In c..., "iewil2000" wrote:
>
> Hi Victor,
>
> read_ready() is any function to test the RRDY bit in the register. I
> saw you've already taken care of it. Do you mean RRDY won't set if
> you don't repeat FSR?
>
> Wei
>
> --- In c..., "rotenovt" wrote:
> >
> > Hi Wei,
> >
> > We only use GPIO because our data source does not have any framing
> > information. It is only data and clock. In SPI slave mode the McBSP
> > requires that FSR is asserted before the McBSP will start receiving
> > data. We have tried tying the DSP GPIO to its own FSR to meet this
> > McBSP requirement.
> >
> > I assumed that after the first FSR I would not be required to repeat
> > the process. I simply read after a MCBSP_rrdy event has been
> thrown.
> >
> > Experimentation has shown us that we need to toggle FSR after
> > receiving every frame.
> >
> > Is the read_ready() you refer to a CSL call? What does it do?
> >
> > Victor
> >
> >
> > --- In c..., "iewil2000" wrote:
> > >
> > > I only have experience with SPI master on McBsp, when GPIO is
> used to
> > > send out CSn. When McBsp works as slave SPI, I speculate GPIO has
> > > nothing to do with McBsp directly. McBsp doesn't respond to GPIO.
> You
> > > shouldn't need to send a stroke to GPIO to kick McBsp to work.
> You
> > > just need a issue a read_ready() and read_mcbsp() to read a word
> > > (length up to your defintion) from the port. When clock comes,
> you
> > > will get the data. If you want to read another work, just repeat
> the
> > > read_ready() and read_mcbsp().
> > >
> > > GPIO will only be useful when you want to develop more efficient
> > > code, when you want CPU do something else when waiting for data.
> GPIO
> > > will inform the code something comes.
> > >
> > > Wei
> > >
> > > --- In c..., "rotenovt" wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I have a device that is sending synchronous data (clock & data)
> to
> > > my
> > > > 5510 DSP. The clock is continuous and does not stop when the
> device
> > > is
> > > > powered.
> > > >
> > > > I am using a McBSP in SPI Slave mode. I understand that I need
> to
> > > > initially assert the FSR line so that the McBSP can begin
> receiving
> > > data.
> > > >
> > > > I assert the FSR line with a GPIO on the DSP.
> > > >
> > > > I correctly receive the first frame of data and then the McBSP
> > > hangs.
> > > > I have determined that the McBSP requires me to reassert the FSR
> > > > (strobe) so that I can begin to receive the next frame.
> > > >
> > > > My question is this: Can I set up the McBSP to continuously
> receive
> > > > data with only the first FSR assertion? I would prefer not to
> > > strobe
> > > > the FSR after each frame.
> > > >
> > > > TI seems to think that this should be possible but has been
> unable
> > > to
> > > > guide me. Any suggestions/comments?
> > > >
> > > > Victor
> > > >
> > >
>

Hi Victor,

read_ready() is any function to test the RRDY bit in the register. I
saw you've already taken care of it. Do you mean RRDY won't set if
you don't repeat FSR?

Wei

--- In c..., "rotenovt" wrote:
>
> Hi Wei,
>
> We only use GPIO because our data source does not have any framing
> information. It is only data and clock. In SPI slave mode the McBSP
> requires that FSR is asserted before the McBSP will start receiving
> data. We have tried tying the DSP GPIO to its own FSR to meet this
> McBSP requirement.
>
> I assumed that after the first FSR I would not be required to repeat
> the process. I simply read after a MCBSP_rrdy event has been
thrown.
>
> Experimentation has shown us that we need to toggle FSR after
> receiving every frame.
>
> Is the read_ready() you refer to a CSL call? What does it do?
>
> Victor
> --- In c..., "iewil2000" wrote:
> >
> > I only have experience with SPI master on McBsp, when GPIO is
used to
> > send out CSn. When McBsp works as slave SPI, I speculate GPIO has
> > nothing to do with McBsp directly. McBsp doesn't respond to GPIO.
You
> > shouldn't need to send a stroke to GPIO to kick McBsp to work.
You
> > just need a issue a read_ready() and read_mcbsp() to read a word
> > (length up to your defintion) from the port. When clock comes,
you
> > will get the data. If you want to read another work, just repeat
the
> > read_ready() and read_mcbsp().
> >
> > GPIO will only be useful when you want to develop more efficient
> > code, when you want CPU do something else when waiting for data.
GPIO
> > will inform the code something comes.
> >
> > Wei
> >
> > --- In c..., "rotenovt" wrote:
> > >
> > > Hi All,
> > >
> > > I have a device that is sending synchronous data (clock & data)
to
> > my
> > > 5510 DSP. The clock is continuous and does not stop when the
device
> > is
> > > powered.
> > >
> > > I am using a McBSP in SPI Slave mode. I understand that I need
to
> > > initially assert the FSR line so that the McBSP can begin
receiving
> > data.
> > >
> > > I assert the FSR line with a GPIO on the DSP.
> > >
> > > I correctly receive the first frame of data and then the McBSP
> > hangs.
> > > I have determined that the McBSP requires me to reassert the FSR
> > > (strobe) so that I can begin to receive the next frame.
> > >
> > > My question is this: Can I set up the McBSP to continuously
receive
> > > data with only the first FSR assertion? I would prefer not to
> > strobe
> > > the FSR after each frame.
> > >
> > > TI seems to think that this should be possible but has been
unable
> > to
> > > guide me. Any suggestions/comments?
> > >
> > > Victor
> > >
>

Hi Wei,

We only use GPIO because our data source does not have any framing
information. It is only data and clock. In SPI slave mode the McBSP
requires that FSR is asserted before the McBSP will start receiving
data. We have tried tying the DSP GPIO to its own FSR to meet this
McBSP requirement.

I assumed that after the first FSR I would not be required to repeat
the process. I simply read after a MCBSP_rrdy event has been thrown.

Experimentation has shown us that we need to toggle FSR after
receiving every frame.

Is the read_ready() you refer to a CSL call? What does it do?

Victor
--- In c..., "iewil2000" wrote:
>
> I only have experience with SPI master on McBsp, when GPIO is used to
> send out CSn. When McBsp works as slave SPI, I speculate GPIO has
> nothing to do with McBsp directly. McBsp doesn't respond to GPIO. You
> shouldn't need to send a stroke to GPIO to kick McBsp to work. You
> just need a issue a read_ready() and read_mcbsp() to read a word
> (length up to your defintion) from the port. When clock comes, you
> will get the data. If you want to read another work, just repeat the
> read_ready() and read_mcbsp().
>
> GPIO will only be useful when you want to develop more efficient
> code, when you want CPU do something else when waiting for data. GPIO
> will inform the code something comes.
>
> Wei
>
> --- In c..., "rotenovt" wrote:
> >
> > Hi All,
> >
> > I have a device that is sending synchronous data (clock & data) to
> my
> > 5510 DSP. The clock is continuous and does not stop when the device
> is
> > powered.
> >
> > I am using a McBSP in SPI Slave mode. I understand that I need to
> > initially assert the FSR line so that the McBSP can begin receiving
> data.
> >
> > I assert the FSR line with a GPIO on the DSP.
> >
> > I correctly receive the first frame of data and then the McBSP
> hangs.
> > I have determined that the McBSP requires me to reassert the FSR
> > (strobe) so that I can begin to receive the next frame.
> >
> > My question is this: Can I set up the McBSP to continuously receive
> > data with only the first FSR assertion? I would prefer not to
> strobe
> > the FSR after each frame.
> >
> > TI seems to think that this should be possible but has been unable
> to
> > guide me. Any suggestions/comments?
> >
> > Victor
>

Victor,

I find the following description for TI document. Basically they ask
you to use CLKX and FSX instead of CLKR and FSR when McBsp acts as
slave. That might be the source of your problem.

"
The right block diagram shows the interface when the McBSP is the SPI
slave. In this case, the clock and chip select signals are supplied
by the SPI device. As a slave, the McBSP CLKX and FSX pins are
configured as inputs. The FSX pin is connected to the chip select
output (/CS) from the SPI device.
As you noticed from these two block diagrams, the CLKX and FSX are
used, even when the McBSP is the slave. Don't use CLKR/FSR in an SPI
interface! Please refer to the device peripheral reference guide and
other documentations for detailed information on how to setup the
McBSP for an SPI interface.
"

The file name is dm20010307_McBSParchive.ppt.

Wei

--- In c..., "rotenovt" wrote:
>
> Hi Wei,
>
> We only use GPIO because our data source does not have any framing
> information. It is only data and clock. In SPI slave mode the McBSP
> requires that FSR is asserted before the McBSP will start receiving
> data. We have tried tying the DSP GPIO to its own FSR to meet this
> McBSP requirement.
>
> I assumed that after the first FSR I would not be required to repeat
> the process. I simply read after a MCBSP_rrdy event has been
thrown.
>
> Experimentation has shown us that we need to toggle FSR after
> receiving every frame.
>
> Is the read_ready() you refer to a CSL call? What does it do?
>
> Victor
> --- In c..., "iewil2000" wrote:
> >
> > I only have experience with SPI master on McBsp, when GPIO is
used to
> > send out CSn. When McBsp works as slave SPI, I speculate GPIO has
> > nothing to do with McBsp directly. McBsp doesn't respond to GPIO.
You
> > shouldn't need to send a stroke to GPIO to kick McBsp to work.
You
> > just need a issue a read_ready() and read_mcbsp() to read a word
> > (length up to your defintion) from the port. When clock comes,
you
> > will get the data. If you want to read another work, just repeat
the
> > read_ready() and read_mcbsp().
> >
> > GPIO will only be useful when you want to develop more efficient
> > code, when you want CPU do something else when waiting for data.
GPIO
> > will inform the code something comes.
> >
> > Wei
> >
> > --- In c..., "rotenovt" wrote:
> > >
> > > Hi All,
> > >
> > > I have a device that is sending synchronous data (clock & data)
to
> > my
> > > 5510 DSP. The clock is continuous and does not stop when the
device
> > is
> > > powered.
> > >
> > > I am using a McBSP in SPI Slave mode. I understand that I need
to
> > > initially assert the FSR line so that the McBSP can begin
receiving
> > data.
> > >
> > > I assert the FSR line with a GPIO on the DSP.
> > >
> > > I correctly receive the first frame of data and then the McBSP
> > hangs.
> > > I have determined that the McBSP requires me to reassert the FSR
> > > (strobe) so that I can begin to receive the next frame.
> > >
> > > My question is this: Can I set up the McBSP to continuously
receive
> > > data with only the first FSR assertion? I would prefer not to
> > strobe
> > > the FSR after each frame.
> > >
> > > TI seems to think that this should be possible but has been
unable
> > to
> > > guide me. Any suggestions/comments?
> > >
> > > Victor
> > >
>

Victor-

> --- In c..., Jeff Brower wrote:
>>
>> Victor-
>>
>> > I have a device that is sending synchronous data (clock & data) to my
>> > 5510 DSP. The clock is continuous and does not stop when the device is
>> > powered.
>> >
>> > I am using a McBSP in SPI Slave mode. I understand that I need to
>> > initially assert the FSR line so that the McBSP can begin
> receiving data.
>> >
>> > I assert the FSR line with a GPIO on the DSP.
>> >
>> > I correctly receive the first frame of data and then the McBSP hangs.
>> > I have determined that the McBSP requires me to reassert the FSR
>> > (strobe) so that I can begin to receive the next frame.
>> >
>> > My question is this: Can I set up the McBSP to continuously receive
>> > data with only the first FSR assertion? I would prefer not to strobe
>> > the FSR after each frame.
>> >
>> > TI seems to think that this should be possible but has been unable to
>> > guide me. Any suggestions/comments?
>>
>> What kind of device is connected to the 5510? This device has no
> framesync or other
>> stop/start signal?
>>
>> One idea is to run the clock into a Timer input and have the Timer
> output generate a
>> pulse every N number of clock cycles.
>>
>> -Jeff
>> Hi Jeff,
>
> We are connected to a pattern generator. The pattern generator simply
> sends data and clock. I like the idea of using the timer.
> Unfortunately, we have already decided to use a 6xxx series with GPIO
> to handle the data & clock.
>
> I still have not figured out why the McBSP requires FSR after the
> first frame. It seems to me that I should be able to assert the FSR
> initially and never have to worry about it again.
>
> If anyone has run into this before I would be interested to know if
> they ever got the McBSP working in slave mode without FSR.

The problem with using GPIO for fast serial port comm is cycle stall. On 6x devices, delays of 120 nsec or more to
toggle a GPIO bit can occur. By the time you actually toggle framesync, many clocks will have elapsed.

Basically, we found that GPIO is not suitable for any type of fast communication protocol where fast response (small
delay) was required.

-Jeff

--- In c..., Jeff Brower wrote:
>
> Victor-
>
> > I have a device that is sending synchronous data (clock & data) to my
> > 5510 DSP. The clock is continuous and does not stop when the device is
> > powered.
> >
> > I am using a McBSP in SPI Slave mode. I understand that I need to
> > initially assert the FSR line so that the McBSP can begin
receiving data.
> >
> > I assert the FSR line with a GPIO on the DSP.
> >
> > I correctly receive the first frame of data and then the McBSP hangs.
> > I have determined that the McBSP requires me to reassert the FSR
> > (strobe) so that I can begin to receive the next frame.
> >
> > My question is this: Can I set up the McBSP to continuously receive
> > data with only the first FSR assertion? I would prefer not to strobe
> > the FSR after each frame.
> >
> > TI seems to think that this should be possible but has been unable to
> > guide me. Any suggestions/comments?
>
> What kind of device is connected to the 5510? This device has no
framesync or other
> stop/start signal?
>
> One idea is to run the clock into a Timer input and have the Timer
output generate a
> pulse every N number of clock cycles.
>
> -Jeff
>

Hi Jeff,

We are connected to a pattern generator. The pattern generator simply
sends data and clock. I like the idea of using the timer.
Unfortunately, we have already decided to use a 6xxx series with GPIO
to handle the data & clock.

I still have not figured out why the McBSP requires FSR after the
first frame. It seems to me that I should be able to assert the FSR
initially and never have to worry about it again.

If anyone has run into this before I would be interested to know if
they ever got the McBSP working in slave mode without FSR.

Victor

I only have experience with SPI master on McBsp, when GPIO is used to
send out CSn. When McBsp works as slave SPI, I speculate GPIO has
nothing to do with McBsp directly. McBsp doesn't respond to GPIO. You
shouldn't need to send a stroke to GPIO to kick McBsp to work. You
just need a issue a read_ready() and read_mcbsp() to read a word
(length up to your defintion) from the port. When clock comes, you
will get the data. If you want to read another work, just repeat the
read_ready() and read_mcbsp().

GPIO will only be useful when you want to develop more efficient
code, when you want CPU do something else when waiting for data. GPIO
will inform the code something comes.

Wei

--- In c..., "rotenovt" wrote:
>
> Hi All,
>
> I have a device that is sending synchronous data (clock & data) to
my
> 5510 DSP. The clock is continuous and does not stop when the device
is
> powered.
>
> I am using a McBSP in SPI Slave mode. I understand that I need to
> initially assert the FSR line so that the McBSP can begin receiving
data.
>
> I assert the FSR line with a GPIO on the DSP.
>
> I correctly receive the first frame of data and then the McBSP
hangs.
> I have determined that the McBSP requires me to reassert the FSR
> (strobe) so that I can begin to receive the next frame.
>
> My question is this: Can I set up the McBSP to continuously receive
> data with only the first FSR assertion? I would prefer not to
strobe
> the FSR after each frame.
>
> TI seems to think that this should be possible but has been unable
to
> guide me. Any suggestions/comments?
>
> Victor
>

Victor-

> I have a device that is sending synchronous data (clock & data) to my
> 5510 DSP. The clock is continuous and does not stop when the device is
> powered.
>
> I am using a McBSP in SPI Slave mode. I understand that I need to
> initially assert the FSR line so that the McBSP can begin receiving data.
>
> I assert the FSR line with a GPIO on the DSP.
>
> I correctly receive the first frame of data and then the McBSP hangs.
> I have determined that the McBSP requires me to reassert the FSR
> (strobe) so that I can begin to receive the next frame.
>
> My question is this: Can I set up the McBSP to continuously receive
> data with only the first FSR assertion? I would prefer not to strobe
> the FSR after each frame.
>
> TI seems to think that this should be possible but has been unable to
> guide me. Any suggestions/comments?

What kind of device is connected to the 5510? This device has no framesync or other
stop/start signal?

One idea is to run the clock into a Timer input and have the Timer output generate a
pulse every N number of clock cycles.

-Jeff

Hi All,

I have a device that is sending synchronous data (clock & data) to my
5510 DSP. The clock is continuous and does not stop when the device is
powered.

I am using a McBSP in SPI Slave mode. I understand that I need to
initially assert the FSR line so that the McBSP can begin receiving data.

I assert the FSR line with a GPIO on the DSP.

I correctly receive the first frame of data and then the McBSP hangs.
I have determined that the McBSP requires me to reassert the FSR
(strobe) so that I can begin to receive the next frame.

My question is this: Can I set up the McBSP to continuously receive
data with only the first FSR assertion? I would prefer not to strobe
the FSR after each frame.

TI seems to think that this should be possible but has been unable to
guide me. Any suggestions/comments?

Victor