Sign in

Not a member? | Forgot your Password?

Search c55x

Search tips

Subscribe to c55x

Search tips

Free PDF Downloads

A Quadrature Signals Tutorial: Complex, But Not Complicated

Understanding the 'Phasing Method' of Single Sideband Demodulation

Complex Digital Signal Processing in Telecommunications

Introduction to Sound Processing

C++ Tutorial

Introduction of C Programming for DSP Applications

Fixed-Point Arithmetic: An Introduction

Cascaded Integrator-Comb (CIC) Filter Introduction

Discussion Groups

FFT Spectral Analysis Software

See Also

Embedded SystemsFPGA

Discussion Groups | TMS320C55x | McBSP as Slave Without Multiple FSR Strobes

Technical discussions about the TI C55x DSPs (including the c5501, c5502, c5503, c5507, c5509, c5510 and OMAP5910).

  

Post a new Thread



Is this thread worth a thumbs up?

0

McBSP as Slave Without Multiple FSR Strobes - rotenovt - Nov 30 10:56:59 2007

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





Re: McBSP as Slave Without Multiple FSR Strobes - Jeff Brower - Nov 30 14:26:43 2007

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





Re: McBSP as Slave Without Multiple FSR Strobes - iewil2000 - Dec 2 2:27:21 2007

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...@yahoogroups.com, "rotenovt" <victor1@...> 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
>





Re: McBSP as Slave Without Multiple FSR Strobes - rotenovt - Dec 7 7:46:23 2007

--- In c...@yahoogroups.com, Jeff Brower <jbrower@...> 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





Re: Re: McBSP as Slave Without Multiple FSR Strobes - Jeff Brower - Dec 7 10:45:07 2007

Victor-

> --- In c...@yahoogroups.com, Jeff Brower <jbrower@...> 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





Re: McBSP as Slave Without Multiple FSR Strobes - iewil2000 - Dec 7 12:50:33 2007

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...@yahoogroups.com, "rotenovt" <victor1@...> 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...@yahoogroups.com, "iewil2000" <liwei2000@>
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...@yahoogroups.com, "rotenovt" <victor1@>
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
> > >
>





Re: McBSP as Slave Without Multiple FSR Strobes - rotenovt - Dec 7 21:50:52 2007

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...@yahoogroups.com, "iewil2000" <liwei2000@...> 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...@yahoogroups.com, "rotenovt" <victor1@> 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
>





Re: McBSP as Slave Without Multiple FSR Strobes - iewil2000 - Dec 8 10:13:54 2007

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...@yahoogroups.com, "rotenovt" <victor1@...> 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...@yahoogroups.com, "iewil2000" <liwei2000@>
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...@yahoogroups.com, "rotenovt" <victor1@>
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
> > >
>





Re: McBSP as Slave Without Multiple FSR Strobes - rotenovt - Dec 12 4:13:12 2007

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...@yahoogroups.com, "iewil2000" <liwei2000@...> 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...@yahoogroups.com, "rotenovt" <victor1@> 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...@yahoogroups.com, "iewil2000" <liwei2000@>
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...@yahoogroups.com, "rotenovt"
<victor1@> 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
> > > >
> > >
>