Forums

TMS320C6713 MCBSP with external clock

Started by eng_shahjee December 30, 2009
I want to use MCBSP with external clock source. I configured
CLKX and CLKR as inputs. FSX is configured to generate frame sync on every DXR2XSR transfer. FSR is driven by external frame sync signal.

The data is not transferred to XSR from DXR so Frame Sync has not been generated. actually XRDY is zero and didn't get one but XEMPTY bit is one when I reset and set again the XRST with code composer, one word transmitted and again it stoped.

what is the reason? kindly help me.

_____________________________________
Shahzad-

> I want to use MCBSP with external clock source. I configured
> CLKX and CLKR as inputs. FSX is configured to generate frame sync
> on every DXR2XSR transfer. FSR is driven by external frame sync signal.
>
> The data is not transferred to XSR from DXR so Frame Sync has not been
> generated.

Something does not make sense here. If you have external CLKR and FSR, then you
should receive data in DRR, without doubt. First, does that happen? If so, is
received data formatted as you expect (number of bytes per frame, msb ordering, etc)?

Second, there is no connection between receiving and transmitting unless you "do
something" in software or with DMA, for example take data received in DRR and send to
DXR. Are you doing that?

My suggestion is to separate carefully your receive and transmit tests, start with
receiving, and then re-post again and clearly state the *first thing* that you find
wrong.

-Jeff

> actually XRDY is zero and didn't get one but XEMPTY bit is
> one when I reset and set again the XRST with code composer, one word
> transmitted and again it stoped.
>
> what is the reason? kindly help me.

_____________________________________
I have major concern with transmitter test.

Very amazing that when i used following settings.

CLKSM = INTERNAL (Internal CPU/2 Clock)
CLKXM = OUTPUT (generated by sample rate generator)
CLKGDV = (0-255)
FSGM = DXR2XSR

Transmitter works fine.

But when i used following setting.
CLKSM = INTERNAL or CLKS (Dont care)
CLKXM = INPUT (External clock)
FSGM = DXR2XSR

It does not work.
Regards,

Shahzad Ahmed

On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower wrote:

> Shahzad-
>
> > I want to use MCBSP with external clock source. I configured
> > CLKX and CLKR as inputs. FSX is configured to generate frame sync
> > on every DXR2XSR transfer. FSR is driven by external frame sync signal.
> >
> > The data is not transferred to XSR from DXR so Frame Sync has not been
> > generated.
>
> actually XRDY is zero and didn't get one but XEMPTY bit is
> one when I reset and set again the XRST with code composer, one word
> transmitted and again it stoped.
>
> what is the reason? kindly help me.

>
> Something does not make sense here. If you have external CLKR and FSR,
> then you
> should receive data in DRR, without doubt. First, does that happen? If
> so, is
> received data formatted as you expect (number of bytes per frame, msb
> ordering, etc)?
>
> Second, there is no connection between receiving and transmitting unless
> you "do
> something" in software or with DMA, for example take data received in DRR
> and send to
> DXR. Are you doing that?
>
> My suggestion is to separate carefully your receive and transmit tests,
> start with
> receiving, and then re-post again and clearly state the *first thing* that
> you find
> wrong.
>
> -Jeff
Shahzad Ahmed-

> I have major concern with transmitter test.
>
> Very amazing that when i used following settings.
>
> CLKSM = INTERNAL (Internal CPU/2 Clock)
> CLKXM = OUTPUT (generated by sample rate generator)
> CLKGDV = (0-255)
> FSGM = DXR2XSR
>
> Transmitter works fine.
>
> But when i used following setting.
> CLKSM = INTERNAL or CLKS (Dont care)
> CLKXM = INPUT (External clock)
> FSGM = DXR2XSR
>
> It does not work.

How are you sending data to DXR? Do you have a software polling loop?

By the way, can you answer my previous questions? It's hard for me to figure out what you're doing and what is the
objective, and I don't want to spend time guessing, which is why I ask. If not then possibly someone else can help
you.

-Jeff
> On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower wrote:
>
>> Shahzad-
>>
>> > I want to use MCBSP with external clock source. I configured
>> > CLKX and CLKR as inputs. FSX is configured to generate frame sync
>> > on every DXR2XSR transfer. FSR is driven by external frame sync signal.
>> >
>> > The data is not transferred to XSR from DXR so Frame Sync has not been
>> > generated.
>>
> > actually XRDY is zero and didn't get one but XEMPTY bit is
> > one when I reset and set again the XRST with code composer, one word
> > transmitted and again it stoped.
> >
> > what is the reason? kindly help me.
>
>>
>> Something does not make sense here. If you have external CLKR and FSR,
>> then you
>> should receive data in DRR, without doubt. First, does that happen? If
>> so, is
>> received data formatted as you expect (number of bytes per frame, msb
>> ordering, etc)?
>>
>> Second, there is no connection between receiving and transmitting unless
>> you "do
>> something" in software or with DMA, for example take data received in DRR
>> and send to
>> DXR. Are you doing that?
>>
>> My suggestion is to separate carefully your receive and transmit tests,
>> start with
>> receiving, and then re-post again and clearly state the *first thing* that
>> you find
>> wrong.
>>
>> -Jeff

_____________________________________
Shahzad-

I suggest for the time being to ignore whether you see FSX output, and focus on XRDY. If you have:

-continuous external CLKX
-FSXM=1
-FSGM=0
-poll XRDY and it's 1
-write a word to DXR

then it has to be the case you get a DXR-to-XSR transfer, and see XRDY go back 1 again.

How fast is CLKX and what is your transmit word width? How long are you waiting to poll XRDY again? Are you waiting
at least the time for one transmit word to be shifted out? There is a note about this in the C6x McBSP reference
guide (pg 14).

-Jeff

> Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as external
> clock.
> I have configured CLKX of McBSP as an input and this CLKX is driven by
> Encoder Shift Clock.
>
> I want to clarify some things. I have not been using send data signal for
> FSX. I have configured FSX as a output and FSX will be generated when whole
> data will be shifted from DXR to XSR.
>
> When FSX will be generated this will drive Encoder Enable (Pin # 19) of
> HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be
> shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock
> rate.
>
> Question--is the transmit shift clock being produced by the HI-15530 when
> the encoder enable line is set 'active' by the McBSP?
>
> Ans: Encoder Shift Clock is already enabled and there is no need for the
> clock to enable.
> Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have
> checked all clock signals (Encoder Shift Clock, Decoder Shift Clock, Encoder
> Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are
> fine.
>
> Question--when the transmit shift clock and the send data signal, being
> produced by the HI-15530, are 'active', are the data bits being shifted out
> by the McBSP?
>
> Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal will
> only be generated when Encoder will be enable by applying FSX signal on
> Encoder Enable pin of HI-15530. There is no use of Send Data signal. It is
> only for checking of Encoder Whether it is working or not.
> Question--is the 'send clock' running at twice the speed of the encoder
> shift clock?
>
> Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
>
> Do you get my points.
>
> I think the problem is somewhere in Clock. What do you think.
>
> Please help me.
> Regards,
>
> Shahzad Ahmed
>
> On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams
> wrote:
>
>> shahzad,
>>
>> do you have the data sheet for the HI-15530?
>> It can be found by going to:
>>
>> and clicking the .pdf link near the bottom of the page.
>>
>> ===================> If I understand you correctly, you are trying to use the clock input to the
>> McBSP on pin CLKX as the 'external' clock.
>>
>> I suspect the problem is the McBSP is not correctly initialized to produce
>> the FSX signal during the whole transmission sequence or not clocking the
>> data on the correct edge of the incoming clock signal or not starting the
>> clocking of the data bits when the 'data send' signal is asserted?
>> Your description of the problem seems to be missing certain key elements.
>>
>> a logic analyzer (or possibly a dual trace oscilloscope) will answer the
>> following questions.
>> --is the transmit shift clock being produced by the HI-15530 when the
>> encoder enable line is set 'active' by the McBSP?
>>
>> --when the transmit shift clock and the send data signal, being produced by
>> the HI-15530, are 'active', are the data bits being shifted out by the
>> McBSP?
>>
>> --When the data bits are being shifted out, are the state transitions at
>> the correct relationship to the transmit shift clock, such that the data bit
>> is set/transitions at the falling edge of the transmit shift clock?
>>
>> --are the data bits being shifted out, beginning when the 'send data'
>> signal is asserted by the HI-15530?
>>
>> --is the 'send clock' running at twice the speed of the encoder shift
>> clock?
>> R. Williams
>> *---------- Original Message -----------*
>> From: shahzad ahmed
>> To: c...
>> Sent: Thu, 31 Dec 2009 11:39:19 +0500
>> Subject: [c6x] TMS320C6713 MCBSP with external clock
>>
>> >
>> >
>> > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester
>> encoder and decoder).
>> >
>> > You can refer application note on following link for further details.
>> >
>> > http://www.holtic.com/AppNotes/AN-510_A.pdf
>> >
>> > I have interfaced MCBSP with HI-15530 as follows.
>> >
>> > MCBSP------------HI-15530
>> >
>> > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin
>> number 2)
>> >
>> > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin number
>> 19)
>> >
>> > DX -----------> Serial Data In (Pin
>> number 18)
>> >
>> > CLKR <-------- Decoder Shift Clock
>> (Pin number 9)
>> >
>> > FSR <------------ Take Data (Pin
>> number 3)
>> >
>> > DR <--------------Serial Data Out
>> (Pin number 4)
>> >
>> > I have been using software polling loop for sending data at DXR. as i
>> already told you the transmitter works fine with internal clock but it did
>> not work for external clock.
>> >
>> > Regards,
>> >
>> > Shahzad Ahmed
>> >
>> > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower wrote:
>> >
>>>
>>> Shahzad Ahmed-
>>> >
>>> > > I have major concern with transmitter test.
>>> > >
>>> > > Very amazing that when i used following settings.
>>> > >
>>> > > CLKSM = INTERNAL (Internal CPU/2 Clock)
>>> > > CLKXM = OUTPUT (generated by sample rate generator)
>>> > > CLKGDV = (0-255)
>>> > > FSGM = DXR2XSR
>>> > >
>>> > > Transmitter works fine.
>>> > >
>>> > > But when i used following setting.
>>> > >
>>> > >
>>> > > CLKSM = INTERNAL or CLKS (Dont care)
>>> > > CLKXM = INPUT (External clock)
>>> > > FSGM = DXR2XSR
>>> > >
>>> > > It does not work.
>>> >
>>> > How are you sending data to DXR? Do you have a software polling loop?
>>> >
>>> > By the way, can you answer my previous questions? It's hard for me to
>>> figure out what you're doing and what is the
>>> > objective, and I don't want to spend time guessing, which is why I ask.
>>> If not then possibly someone else can help
>>> > you.
>>> >
>>> > -Jeff
>>> >
>>> >
>>> > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower wrote:
>>>
>>> > >
>>> > >> Shahzad-
>>> > >>
>>> > >> > I want to use MCBSP with external clock source. I configured
>>> > >> > CLKX and CLKR as inputs. FSX is configured to generate frame sync
>>> > >> > on every DXR2XSR transfer. FSR is driven by external frame sync
>>> signal.
>>> > >> >
>>> > >> > The data is not transferred to XSR from DXR so Frame Sync has not
>>> been
>>> > >> > generated.
>>> > >>
>>> > > > actually XRDY is zero and didn't get one but XEMPTY bit is
>>> > > > one when I reset and set again the XRST with code composer, one
>>> word
>>> > > > transmitted and again it stoped.
>>> > > >
>>> > > > what is the reason? kindly help me.
>>> > >
>>> > >>
>>> > >> Something does not make sense here. If you have external CLKR and
>>> FSR,
>>> > >> then you
>>> > >> should receive data in DRR, without doubt. First, does that happen?
>>> If
>>> > >> so, is
>>> > >> received data formatted as you expect (number of bytes per frame, msb
>>>
>>> > >> ordering, etc)?
>>> > >>
>>> > >> Second, there is no connection between receiving and transmitting
>>> unless
>>> > >> you "do
>>> > >> something" in software or with DMA, for example take data received in
>>> DRR
>>> > >> and send to
>>> > >> DXR. Are you doing that?
>>> > >>
>>> > >> My suggestion is to separate carefully your receive and transmit
>>> tests,
>>> > >> start with
>>> > >> receiving, and then re-post again and clearly state the *first thing*
>>> that
>>> > >> you find
>>> > >> wrong.
>>> > >>
>>> > >> -Jeff

_____________________________________
Shahzad,

First, the 'send data' signal is the indication from the HI-15530 that it is ready to receive data no that clock cycle for the first bit of data.
That signal should not be ignored as the data has to arrive at the HI-15530 when the HI-15530 is expecting it, not before, not after.
This isa McBSP setup parameter.

Second, the data edges/transitions must happen during the correct phase of the clock, otherwise the data may be invalid, prior bit, next bit, or in transition when the HI-15530 is sampling the data line. This is a McBSP setup parameter.

Finally, is the data actually being sent by the McBSP ?
I suspect it is being sent, just at a time when the HI-15530 is not expecting it.

R. Williams

---------- Original Message -----------
From: shahzad ahmed
To: Richard Williams
Cc: c..., Jeff Brower
Sent: Thu, 31 Dec 2009 23:53:37 +0500
Subject: Re: [c6x] TMS320C6713 MCBSP with external clock

> Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as external clock.
> I have configured CLKX of McBSP as an input and this CLKX is driven by Encoder Shift Clock.
>
> I want to clarify some things. I have not been using send data signal for FSX. I have configured FSX as a output and FSX will be generated when whole data will be shifted from DXR to XSR.
>
> When FSX will be generated this will drive Encoder Enable (Pin # 19) of HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock rate.
>
> Question--is the transmit shift clock being produced by the HI-15530 when the encoder enable line is set 'active' by the McBSP?
>
> Ans: Encoder Shift Clock is already enabled and there is no need for the clock to enable.
> Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have checked all clock signals (Encoder Shift Clock, Decoder Shift Clock, Encoder Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are fine.
>
> Question--when the transmit shift clock and the send data signal, beingproduced by the HI-15530, are 'active', are the data bits being shiftedout by the McBSP?
>
> Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal will only be generated when Encoder will be enable by applying FSX signal on Encoder Enable pin of HI-15530. There is no use of Send Data signal. It is only for checking of Encoder Whether it is working or not.
>
> Question--is the 'send clock' running at twice the speed of the encoder shift clock?
>
> Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
>
> Do you get my points.
>
> I think the problem is somewhere in Clock. What do you think.
>
> Please help me.
>
> Regards,
>
> Shahzad Ahmed
>
> On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams wrote:
>
> shahzad,
>
> do you have the data sheet for the HI-15530?
> It can be found by going to:
>
> and clicking the .pdf link near the bottom of the page.
>
> ===================> If I understand you correctly, you are trying to use the clock input to the McBSP on pin CLKX as the 'external' clock.
>
> I suspect the problem is the McBSP is not correctly initialized to produce the FSX signal during the whole transmission sequence or not clocking the data on the correct edge of the incoming clock signal or not starting the clocking of the data bits when the 'data send' signal is asserted?
>
> Your description of the problem seems to be missing certain key elements.
>
> a logic analyzer (or possibly a dual trace oscilloscope) will answer the following questions.
> --is the transmit shift clock being produced by the HI-15530 when the encoder enable line is set 'active' by the McBSP?
>
> --when the transmit shift clock and the send data signal, being produced by the HI-15530, are 'active', are the data bits being shifted out by the McBSP?
>
> --When the data bits are being shifted out, are the state transitions at the correct relationship to the transmit shift clock, such that the data bit is set/transitions at the falling edge of the transmit shift clock?
>
> --are the data bits being shifted out, beginning when the 'send data' signal is asserted by the HI-15530?
>
> --is the 'send clock' running at twice the speed of the encoder shift clock?
> R. Williams
>
> ---------- Original Message -----------
> From: shahzad ahmed
> To: c...
> Sent: Thu, 31 Dec 2009 11:39:19 +0500
> Subject: [c6x] TMS320C6713 MCBSP with external clock
>
> >
> >
> > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester encoder and decoder).
> >
> > You can refer application note on following link for further details.
> >
> > http://www.holtic.com/AppNotes/AN-510_A.pdf
> >
> > I have interfaced MCBSP with HI-15530 as follows.
> >
> > MCBSP------------HI-15530
> >
> > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin number 2)
> >
> > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin number 19)
> >
> > DX -----------> Serial Data In (Pin number 18)
> >
> > CLKR <-------- Decoder Shift Clock (Pin number 9)
> >
> > FSR <------------ Take Data (Pin number 3)
> >
> > DR <--------------Serial Data Out (Pin number 4)
> >
> > I have been using software polling loop for sending data at DXR. as i already told you the transmitter works fine with internal clock but it did not work for external clock.
> >
> > Regards,
> >
> > Shahzad Ahmed
> >
> > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower wrote:
> > Shahzad Ahmed-
> >
> > > I have major concern with transmitter test.
> > >
> > > Very amazing that when i used following settings.
> > >
> > > CLKSM = INTERNAL (Internal CPU/2 Clock)
> > > CLKXM = OUTPUT (generated by sample rate generator)
> > > CLKGDV = (0-255)
> > > FSGM = DXR2XSR
> > >
> > > Transmitter works fine.
> > >
> > > But when i used following setting.
> > >
> > >
> > > CLKSM = INTERNAL or CLKS (Dont care)
> > > CLKXM = INPUT (External clock)
> > > FSGM = DXR2XSR
> > >
> > > It does not work.
> >
> > How are you sending data to DXR? Do you have a software polling loop?
> >
> > By the way, can you answer my previous questions? It's hard for me to figure out what you're doing and what is the
> > objective, and I don't want to spend time guessing, which is why I ask. If not then possibly someone else can help
> > you.
> >
> > -Jeff
> >
> >
> > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower wrote:
> > >
> > >> Shahzad-
> > >>
> > >> > I want to use MCBSP with external clock source. I configured
> > >> > CLKX and CLKR as inputs. FSX is configured to generate frame sync
> > >> > on every DXR2XSR transfer. FSR is driven by external frame sync signal.
> > >> >
> > >> > The data is not transferred to XSR from DXR so Frame Sync has not been
> > >> > generated.
> > >>
> > > > actually XRDY is zero and didn't get one but XEMPTY bit is
> > > > one when I reset and set again the XRST with code composer, one word
> > > > transmitted and again it stoped.
> > > >
> > > > what is the reason? kindly help me.
> > >
> > >>
> > >> Something does not make sense here. If you have external CLKR and FSR,
> > >> then you
> > >> should receive data in DRR, without doubt. First, does that happen? If
> > >> so, is
> > >> received data formatted as you expect (number of bytes per frame, msb
> > >> ordering, etc)?
> > >>
> > >> Second, there is no connection between receiving and transmitting unless
> > >> you "do
> > >> something" in software or with DMA, for example take data received in DRR
> > >> and send to
> > >> DXR. Are you doing that?
> > >>
> > >> My suggestion is to separate carefully your receive and transmit tests,
> > >> start with
> > >> receiving, and then re-post again and clearly state the *first thing* that
> > >> you find
> > >> wrong.
> > >>
> > >> -Jeff
> >
> >
> >
> >
> ------- End of Original Message -------
>
------- End of Original Message -------
shahzad,

*I* would strongly suggest a careful reading of the timing of the various signals for the HI-15530.

Notice the rising edge of the 'encoder enable' signal starts a communication sequence.
and the encoder enable signal is to be 'low' by the end of the communication sequence.
Otherwise another communication sequence will not be initiated.

Notice the number of clocks before any data bits are to be transfered.

Notice the data is to transition on the falling edge of the encoder clock signal.

Notice the Send Data signal transitions to 'high' to indicate when to start sending the data bits and transitions to 'low' to indicate when to stop sending data bits.

Therefore, the communication sequence for 6713 would be::
1) set encoder enable signal high
2) wait for send data signal to transition to high
3) immediately set first data bit level.
4) set encoder enable signal to low
5) at each encoder shift clock transition from high to low, set next data bit level

The above can (probably) be performed by the proper setup of the McBSP.

I.E. the 'send data' signal cannot be ignored.

R. Williams

---------- Original Message -----------
From: shahzad ahmed
To: Richard Williams
Cc: c..., Jeff Brower
Sent: Thu, 31 Dec 2009 23:53:37 +0500
Subject: Re: [c6x] TMS320C6713 MCBSP with external clock

> Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as external clock.
> I have configured CLKX of McBSP as an input and this CLKX is driven by Encoder Shift Clock.
>
> I want to clarify some things. I have not been using send data signal for FSX. I have configured FSX as a output and FSX will be generated when whole data will be shifted from DXR to XSR.
>
> When FSX will be generated this will drive Encoder Enable (Pin # 19) of HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock rate.
>
> Question--is the transmit shift clock being produced by the HI-15530 when the encoder enable line is set 'active' by the McBSP?
>
> Ans: Encoder Shift Clock is already enabled and there is no need for the clock to enable.
> Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have checked all clock signals (Encoder Shift Clock, Decoder Shift Clock, Encoder Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are fine.
>
> Question--when the transmit shift clock and the send data signal, beingproduced by the HI-15530, are 'active', are the data bits being shiftedout by the McBSP?
>
> Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal will only be generated when Encoder will be enable by applying FSX signal on Encoder Enable pin of HI-15530. There is no use of Send Data signal. It is only for checking of Encoder Whether it is working or not.
>
> Question--is the 'send clock' running at twice the speed of the encoder shift clock?
>
> Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
>
> Do you get my points.
>
> I think the problem is somewhere in Clock. What do you think.
>
> Please help me.
>
> Regards,
>
> Shahzad Ahmed
>
> On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams wrote:
>
> shahzad,
>
> do you have the data sheet for the HI-15530?
> It can be found by going to:
>
> and clicking the .pdf link near the bottom of the page.
>
> ===================> If I understand you correctly, you are trying to use the clock input to the McBSP on pin CLKX as the 'external' clock.
>
> I suspect the problem is the McBSP is not correctly initialized to produce the FSX signal during the whole transmission sequence or not clocking the data on the correct edge of the incoming clock signal or not starting the clocking of the data bits when the 'data send' signal is asserted?
>
> Your description of the problem seems to be missing certain key elements.
>
> a logic analyzer (or possibly a dual trace oscilloscope) will answer the following questions.
> --is the transmit shift clock being produced by the HI-15530 when the encoder enable line is set 'active' by the McBSP?
>
> --when the transmit shift clock and the send data signal, being produced by the HI-15530, are 'active', are the data bits being shifted out by the McBSP?
>
> --When the data bits are being shifted out, are the state transitions at the correct relationship to the transmit shift clock, such that the data bit is set/transitions at the falling edge of the transmit shift clock?
>
> --are the data bits being shifted out, beginning when the 'send data' signal is asserted by the HI-15530?
>
> --is the 'send clock' running at twice the speed of the encoder shift clock?
> R. Williams
>
> ---------- Original Message -----------
> From: shahzad ahmed
> To: c...
> Sent: Thu, 31 Dec 2009 11:39:19 +0500
> Subject: [c6x] TMS320C6713 MCBSP with external clock
>
> >
> >
> > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester encoder and decoder).
> >
> > You can refer application note on following link for further details.
> >
> > http://www.holtic.com/AppNotes/AN-510_A.pdf
> >
> > I have interfaced MCBSP with HI-15530 as follows.
> >
> > MCBSP------------HI-15530
> >
> > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin number 2)
> >
> > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin number 19)
> >
> > DX -----------> Serial Data In (Pin number 18)
> >
> > CLKR <-------- Decoder Shift Clock (Pin number 9)
> >
> > FSR <------------ Take Data (Pin number 3)
> >
> > DR <--------------Serial Data Out (Pin number 4)
> >
> > I have been using software polling loop for sending data at DXR. as i already told you the transmitter works fine with internal clock but it did not work for external clock.
> >
> > Regards,
> >
> > Shahzad Ahmed
> >
> > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower wrote:
> > Shahzad Ahmed-
> >
> > > I have major concern with transmitter test.
> > >
> > > Very amazing that when i used following settings.
> > >
> > > CLKSM = INTERNAL (Internal CPU/2 Clock)
> > > CLKXM = OUTPUT (generated by sample rate generator)
> > > CLKGDV = (0-255)
> > > FSGM = DXR2XSR
> > >
> > > Transmitter works fine.
> > >
> > > But when i used following setting.
> > >
> > >
> > > CLKSM = INTERNAL or CLKS (Dont care)
> > > CLKXM = INPUT (External clock)
> > > FSGM = DXR2XSR
> > >
> > > It does not work.
> >
> > How are you sending data to DXR? Do you have a software polling loop?
> >
> > By the way, can you answer my previous questions? It's hard for me to figure out what you're doing and what is the
> > objective, and I don't want to spend time guessing, which is why I ask. If not then possibly someone else can help
> > you.
> >
> > -Jeff
> >
> >
> > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower wrote:
> > >
> > >> Shahzad-
> > >>
> > >> > I want to use MCBSP with external clock source. I configured
> > >> > CLKX and CLKR as inputs. FSX is configured to generate frame sync
> > >> > on every DXR2XSR transfer. FSR is driven by external frame sync signal.
> > >> >
> > >> > The data is not transferred to XSR from DXR so Frame Sync has not been
> > >> > generated.
> > >>
> > > > actually XRDY is zero and didn't get one but XEMPTY bit is
> > > > one when I reset and set again the XRST with code composer, one word
> > > > transmitted and again it stoped.
> > > >
> > > > what is the reason? kindly help me.
> > >
> > >>
> > >> Something does not make sense here. If you have external CLKR and FSR,
> > >> then you
> > >> should receive data in DRR, without doubt. First, does that happen? If
> > >> so, is
> > >> received data formatted as you expect (number of bytes per frame, msb
> > >> ordering, etc)?
> > >>
> > >> Second, there is no connection between receiving and transmitting unless
> > >> you "do
> > >> something" in software or with DMA, for example take data received in DRR
> > >> and send to
> > >> DXR. Are you doing that?
> > >>
> > >> My suggestion is to separate carefully your receive and transmit tests,
> > >> start with
> > >> receiving, and then re-post again and clearly state the *first thing* that
> > >> you find
> > >> wrong.
> > >>
> > >> -Jeff
> >
> >
> >
> >
> ------- End of Original Message -------
>
------- End of Original Message -------
I have done it. I have been providing Encoder Shift Clock (1 MHz clock) to
CLKX. Transmit word width can be programmed through XWDLEN2. I have set 20
bit word length. XPHASE was single phase.

The problem was that i was doing all the work on Bread Board. The source of
the clock HI-15530 was on bread board and getting 5 v supply from power
supply. connection of the 5V power supply to HI-15530 was loose and clock
was not generated properly due to this loose connection. When i rechecked
all connection then i found the problem. Now XRDY bit is flipping on every
clock cycle.

Regards,

Shahzad Ahmed

On Fri, Jan 1, 2010 at 12:41 AM, Jeff Brower wrote:

> Shahzad-
>
> I suggest for the time being to ignore whether you see FSX output, and
> focus on XRDY. If you have:
>
> -continuous external CLKX
> -FSXM=1
> -FSGM=0
> -poll XRDY and it's 1
> -write a word to DXR
>
> then it has to be the case you get a DXR-to-XSR transfer, and see XRDY go
> back 1 again.
>
> How fast is CLKX and what is your transmit word width? How long are you
> waiting to poll XRDY again? Are you waiting
> at least the time for one transmit word to be shifted out? There is a note
> about this in the C6x McBSP reference
> guide (pg 14).
>
> -Jeff
>
> > Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as
> external
> > clock.
> > I have configured CLKX of McBSP as an input and this CLKX is driven by
> > Encoder Shift Clock.
> >
> > I want to clarify some things. I have not been using send data signal for
> > FSX. I have configured FSX as a output and FSX will be generated when
> whole
> > data will be shifted from DXR to XSR.
> >
> > When FSX will be generated this will drive Encoder Enable (Pin # 19) of
> > HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be
> > shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock
> > rate.
> >
> > Question--is the transmit shift clock being produced by the HI-15530 when
> > the encoder enable line is set 'active' by the McBSP?
> >
> > Ans: Encoder Shift Clock is already enabled and there is no need for the
> > clock to enable.
> > Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have
> > checked all clock signals (Encoder Shift Clock, Decoder Shift Clock,
> Encoder
> > Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are
> > fine.
> >
> > Question--when the transmit shift clock and the send data signal, being
> > produced by the HI-15530, are 'active', are the data bits being shifted
> out
> > by the McBSP?
> >
> > Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal
> will
> > only be generated when Encoder will be enable by applying FSX signal on
> > Encoder Enable pin of HI-15530. There is no use of Send Data signal. It
> is
> > only for checking of Encoder Whether it is working or not.
> >
> >
> > Question--is the 'send clock' running at twice the speed of the encoder
> > shift clock?
> >
> > Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
> >
> > Do you get my points.
> >
> > I think the problem is somewhere in Clock. What do you think.
> >
> > Please help me.
> >
> >
> > Regards,
> >
> > Shahzad Ahmed
> >
> > On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams
> > wrote:
> >
> >> shahzad,
> >>
> >> do you have the data sheet for the HI-15530?
> >> It can be found by going to:
> >>
> >> and clicking the .pdf link near the bottom of the page.
> >>
> >> ===================> If I understand you correctly, you are trying to
> use the clock input to the
> >> McBSP on pin CLKX as the 'external' clock.
> >>
> >> I suspect the problem is the McBSP is not correctly initialized to
> produce
> >> the FSX signal during the whole transmission sequence or not clocking
> the
> >> data on the correct edge of the incoming clock signal or not starting
> the
> >> clocking of the data bits when the 'data send' signal is asserted?
> >>
> >>
> >> Your description of the problem seems to be missing certain key
> elements.
> >>
> >> a logic analyzer (or possibly a dual trace oscilloscope) will answer the
> >> following questions.
> >> --is the transmit shift clock being produced by the HI-15530 when the
> >> encoder enable line is set 'active' by the McBSP?
> >>
> >> --when the transmit shift clock and the send data signal, being produced
> by
> >> the HI-15530, are 'active', are the data bits being shifted out by the
> >> McBSP?
> >>
> >> --When the data bits are being shifted out, are the state transitions at
> >> the correct relationship to the transmit shift clock, such that the data
> bit
> >> is set/transitions at the falling edge of the transmit shift clock?
> >>
> >> --are the data bits being shifted out, beginning when the 'send data'
> >> signal is asserted by the HI-15530?
> >>
> >> --is the 'send clock' running at twice the speed of the encoder shift
> >> clock?
> >>
> >>
> >> R. Williams
> >>
> >>
> >> *---------- Original Message -----------*
> >> From: shahzad ahmed
> >> To: c...
> >> Sent: Thu, 31 Dec 2009 11:39:19 +0500
> >> Subject: [c6x] TMS320C6713 MCBSP with external clock
> >>
> >> >
> >> >
> >> > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester
> >> encoder and decoder).
> >> >
> >> > You can refer application note on following link for further details.
> >> >
> >> > http://www.holtic.com/AppNotes/AN-510_A.pdf
> >> >
> >> > I have interfaced MCBSP with HI-15530 as follows.
> >> >
> >> > MCBSP------------HI-15530
> >> >
> >> > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin
> >> number 2)
> >> >
> >> > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin
> number
> >> 19)
> >> >
> >> > DX -----------> Serial Data In
> (Pin
> >> number 18)
> >> >
> >> > CLKR <-------- Decoder Shift Clock
> >> (Pin number 9)
> >> >
> >> > FSR <------------ Take Data (Pin
> >> number 3)
> >> >
> >> > DR <--------------Serial Data Out
> >> (Pin number 4)
> >> >
> >> > I have been using software polling loop for sending data at DXR. as i
> >> already told you the transmitter works fine with internal clock but it
> did
> >> not work for external clock.
> >> >
> >> > Regards,
> >> >
> >> > Shahzad Ahmed
> >> >
> >> > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower > >wrote:
> >> >
> >>>
> >>> Shahzad Ahmed-
> >>> >
> >>> > > I have major concern with transmitter test.
> >>> > >
> >>> > > Very amazing that when i used following settings.
> >>> > >
> >>> > > CLKSM = INTERNAL (Internal CPU/2 Clock)
> >>> > > CLKXM = OUTPUT (generated by sample rate generator)
> >>> > > CLKGDV = (0-255)
> >>> > > FSGM = DXR2XSR
> >>> > >
> >>> > > Transmitter works fine.
> >>> > >
> >>> > > But when i used following setting.
> >>> > >
> >>> > >
> >>> > > CLKSM = INTERNAL or CLKS (Dont care)
> >>> > > CLKXM = INPUT (External clock)
> >>> > > FSGM = DXR2XSR
> >>> > >
> >>> > > It does not work.
> >>> >
> >>> > How are you sending data to DXR? Do you have a software polling
> loop?
> >>> >
> >>> > By the way, can you answer my previous questions? It's hard for me
> to
> >>> figure out what you're doing and what is the
> >>> > objective, and I don't want to spend time guessing, which is why I
> ask.
> >>> If not then possibly someone else can help
> >>> > you.
> >>> >
> >>> > -Jeff
> >>> >
> >>> >
> >>> > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower <
> j...@signalogic.com>wrote:
> >>>
> >>> > >
> >>> > >> Shahzad-
> >>> > >>
> >>> > >> > I want to use MCBSP with external clock source. I configured
> >>> > >> > CLKX and CLKR as inputs. FSX is configured to generate frame
> sync
> >>> > >> > on every DXR2XSR transfer. FSR is driven by external frame sync
> >>> signal.
> >>> > >> >
> >>> > >> > The data is not transferred to XSR from DXR so Frame Sync has
> not
> >>> been
> >>> > >> > generated.
> >>> > >>
> >>> > > > actually XRDY is zero and didn't get one but XEMPTY bit is
> >>> > > > one when I reset and set again the XRST with code composer,
> one
> >>> word
> >>> > > > transmitted and again it stoped.
> >>> > > >
> >>> > > > what is the reason? kindly help me.
> >>> > >
> >>> > >>
> >>> > >> Something does not make sense here. If you have external CLKR and
> >>> FSR,
> >>> > >> then you
> >>> > >> should receive data in DRR, without doubt. First, does that
> happen?
> >>> If
> >>> > >> so, is
> >>> > >> received data formatted as you expect (number of bytes per frame,
> msb
> >>>
> >>> > >> ordering, etc)?
> >>> > >>
> >>> > >> Second, there is no connection between receiving and transmitting
> >>> unless
> >>> > >> you "do
> >>> > >> something" in software or with DMA, for example take data received
> in
> >>> DRR
> >>> > >> and send to
> >>> > >> DXR. Are you doing that?
> >>> > >>
> >>> > >> My suggestion is to separate carefully your receive and transmit
> >>> tests,
> >>> > >> start with
> >>> > >> receiving, and then re-post again and clearly state the *first
> thing*
> >>> that
> >>> > >> you find
> >>> > >> wrong.
> >>> > >>
> >>> > >> -Jeff
FSX has been generated but it has not been activating the encoder. Because
we are applying FSX Pulse directly on Encoder Enable. I have measured
Voltage level of FSX signal. It was something round about
98.0 mV. IC HI-15530 has been tested by connecting/disconnecting 5V supply
sequence wise on Encoder Enable Pin. Encoder was enable and *send
data*signal was generated. but this procedure was just for checking
the HI-15530.
We can not apply this method in normal operation of HI-15530.

The conclusion is that Voltage level of FSX signal is not able to drive
Encoder Enable pin of HI-15530.

What could be the solution for this type of problem.

Regards,

Shahzad Ahmed.

On Fri, Jan 1, 2010 at 3:58 AM, Richard Williams wrote:

> shahzad,
>
> *I* would strongly suggest a careful reading of the timing of the various
> signals for the HI-15530.
> Notice the rising edge of the 'encoder enable' signal starts a
> communication sequence.
> and the encoder enable signal is to be 'low' by the end of the
> communication sequence.
> Otherwise another communication sequence will not be initiated.
>
> Notice the number of clocks before any data bits are to be transfered.
>
> Notice the data is to transition on the falling edge of the encoder clock
> signal.
>
> Notice the Send Data signal transitions to 'high' to indicate when to start
> sending the data bits and transitions to 'low' to indicate when to stop
> sending data bits.
>
> Therefore, the communication sequence for 6713 would be::
> 1) set encoder enable signal high
> 2) wait for send data signal to transition to high
> 3) immediately set first data bit level.
> 4) set encoder enable signal to low
> 5) at each encoder shift clock transition from high to low, set next data
> bit level
>
> The above can (probably) be performed by the proper setup of the McBSP.
>
> I.E. the 'send data' signal cannot be ignored.
>
> R. Williams
> *---------- Original Message -----------*
> From: shahzad ahmed
> To: Richard Williams
> Cc: c..., Jeff Brower
> Sent: Thu, 31 Dec 2009 23:53:37 +0500
> Subject: Re: [c6x] TMS320C6713 MCBSP with external clock
>
> > Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as
> external clock.
> > I have configured CLKX of McBSP as an input and this CLKX is driven by
> Encoder Shift Clock.
> >
> > I want to clarify some things. I have not been using send data signal
> for FSX. I have configured FSX as a output and FSX will be generated when
> whole data will be shifted from DXR to XSR.
> >
> > When FSX will be generated this will drive Encoder Enable (Pin # 19) of
> HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be
> shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock
> rate.
> >
> > Question--is the transmit shift clock being produced by the HI-15530 when
> the encoder enable line is set 'active' by the McBSP?
> >
> > Ans: Encoder Shift Clock is already enabled and there is no need for the
> clock to enable.
> > Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have
> checked all clock signals (Encoder Shift Clock, Decoder Shift Clock, Encoder
> Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are
> fine.
> >
> > Question--when the transmit shift clock and the send data signal, being
> produced by the HI-15530, are 'active', are the data bits being shifted out
> by the McBSP?
> >
> > Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal
> will only be generated when Encoder will be enable by applying FSX signal on
> Encoder Enable pin of HI-15530. There is no use of Send Data signal. It is
> only for checking of Encoder Whether it is working or not.
> >
> > Question--is the 'send clock' running at twice the speed of the encoder
> shift clock?
> >
> > Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
>
> >
> > Do you get my points.
> >
> > I think the problem is somewhere in Clock. What do you think.
> >
> > Please help me.
> >
> > Regards,
> >
> > Shahzad Ahmed
> >
> > On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams <
> r...@lewiscounty.com> wrote:
> >>
>> > shahzad,
>> >
>> > do you have the data sheet for the HI-15530?
>> > It can be found by going to:
>> >
>> > and clicking the .pdf link near the bottom of the page.
>> >
>> > ===================>> > If I understand you correctly, you are trying to use the clock input to
>> the McBSP on pin CLKX as the 'external' clock.
>> >
>> > I suspect the problem is the McBSP is not correctly initialized to
>> produce the FSX signal during the whole transmission sequence or not
>> clocking the data on the correct edge of the incoming clock signal or not
>> starting the clocking of the data bits when the 'data send' signal is
>> asserted?
>> >
>> > Your description of the problem seems to be missing certain key
>> elements.
>> >
>> > a logic analyzer (or possibly a dual trace oscilloscope) will answer the
>> following questions.
>> > --is the transmit shift clock being produced by the HI-15530 when the
>> encoder enable line is set 'active' by the McBSP?
>> >
>> > --when the transmit shift clock and the send data signal, being produced
>> by the HI-15530, are 'active', are the data bits being shifted out by the
>> McBSP?
>> >
>> > --When the data bits are being shifted out, are the state transitions at
>> the correct relationship to the transmit shift clock, such that the data bit
>> is set/transitions at the falling edge of the transmit shift clock?
>> >
>> > --are the data bits being shifted out, beginning when the 'send data'
>> signal is asserted by the HI-15530?
>> >
>> > --is the 'send clock' running at twice the speed of the encoder shift
>> clock?
>> >
>>
>> >
>> > R. Williams
>> >
>> > *---------- Original Message -----------*
>> > From: shahzad ahmed
>> > To: c...
>> > Sent: Thu, 31 Dec 2009 11:39:19 +0500
>> > Subject: [c6x] TMS320C6713 MCBSP with external clock
>> >
>> > >
>> > >
>> > > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester
>> encoder and decoder).
>> > >
>> > > You can refer application note on following link for further details.
>> > >
>> > > http://www.holtic.com/AppNotes/AN-510_A.pdf
>> > >
>> > > I have interfaced MCBSP with HI-15530 as follows.
>> > >
>> > > MCBSP------------HI-15530
>> > >
>> > > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin
>> number 2)
>> > >
>> > > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin
>> number 19)
>> > >
>> > > DX -----------> Serial Data In
>> (Pin number 18)
>> > >
>> > > CLKR <-------- Decoder Shift Clock
>> (Pin number 9)
>> > >
>> > > FSR <------------ Take Data (Pin
>> number 3)
>> > >
>> > > DR <--------------Serial Data Out
>> (Pin number 4)
>> > >
>> > > I have been using software polling loop for sending data at DXR. as i
>> already told you the transmitter works fine with internal clock but it did
>> not work for external clock.
>> > >
>> > > Regards,
>> > >
>> > > Shahzad Ahmed
>> > >
>> > > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower >> > wrote:
>> > >
>>>
>>> Shahzad Ahmed-
>>> > >
>>> > > > I have major concern with transmitter test.
>>> > > >
>>> > > > Very amazing that when i used following settings.
>>> > > >
>>> > > > CLKSM = INTERNAL (Internal CPU/2 Clock)
>>> > > > CLKXM = OUTPUT (generated by sample rate generator)
>>> > > > CLKGDV = (0-255)
>>> > > > FSGM = DXR2XSR
>>> > > >
>>> > > > Transmitter works fine.
>>> > > >
>>> > > > But when i used following setting.
>>> > > >
>>> > > >
>>> > > > CLKSM = INTERNAL or CLKS (Dont care)
>>> > > > CLKXM = INPUT (External clock)
>>> > > > FSGM = DXR2XSR
>>> > > >
>>> > > > It does not work.
>>> > >
>>> > > How are you sending data to DXR? Do you have a software polling
>>> loop?
>>> > >
>>> > > By the way, can you answer my previous questions? It's hard for me
>>> to figure out what you're doing and what is the
>>> > > objective, and I don't want to spend time guessing, which is why I
>>> ask. If not then possibly someone else can help
>>> > > you.
>>> > >
>>> > > -Jeff
>>> > >
>>> > >
>>> > > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower <
>>> j...@signalogic.com>wrote:
>>> > > >
>>> > > >> Shahzad-
>>> > > >>
>>> > > >> > I want to use MCBSP with external clock source. I configured
>>> > > >> > CLKX and CLKR as inputs. FSX is configured to generate frame
>>> sync
>>> > > >> > on every DXR2XSR transfer. FSR is driven by external frame sync
>>> signal.
>>> > > >> >
>>> > > >> > The data is not transferred to XSR from DXR so Frame Sync has
>>> not been
>>> > > >> > generated.
>>> > > >>
>>> > > > > actually XRDY is zero and didn't get one but XEMPTY bit is
>>> > > > > one when I reset and set again the XRST with code composer,
>>> one word
>>> > > > > transmitted and again it stoped.
>>> > > > >
>>> > > > > what is the reason? kindly help me.
>>> > > >
>>> > > >>
>>> > > >> Something does not make sense here. If you have external CLKR and
>>> FSR,
>>> > > >> then you
>>> > > >> should receive data in DRR, without doubt. First, does that
>>> happen? If
>>> > > >> so, is
>>> > > >> received data formatted as you expect (number of bytes per frame,
>>> msb
>>> > > >> ordering, etc)?
>>> > > >>
>>> > > >> Second, there is no connection between receiving and transmitting
>>> unless
>>> > > >> you "do
>>> > > >> something" in software or with DMA, for example take data received
>>> in DRR
>>> > > >> and send to
>>> > > >> DXR. Are you doing that?
>>> > > >>
>>> > > >> My suggestion is to separate carefully your receive and transmit
>>> tests,
>>> > > >> start with
>>> > > >> receiving, and then re-post again and clearly state the *first
>>> thing* that
>>> > > >> you find
>>> > > >> wrong.
>>> > > >>
>>> > > >> -Jeff
>>> > >
>>> > >
>> > >
>> > >
>> > *------- End of Original Message -------*
>> >
> *------- End of Original Message -------*
>
Shahzad-

> I have done it. I have been providing Encoder Shift Clock (1 MHz clock) to
> CLKX. Transmit word width can be programmed through XWDLEN2. I have set 20
> bit word length. XPHASE was single phase.
>
> The problem was that i was doing all the work on Bread Board. The source of
> the clock HI-15530 was on bread board and getting 5 v supply from power
> supply. connection of the 5V power supply to HI-15530 was loose and clock
> was not generated properly due to this loose connection. When i rechecked
> all connection then i found the problem. Now XRDY bit is flipping on every
> clock cycle.

Excellent work. I was sure that if you had a reliable CLKX input then you would see XRDY toggle.

-Jeff

> On Fri, Jan 1, 2010 at 12:41 AM, Jeff Brower wrote:
>
>> Shahzad-
>>
>> I suggest for the time being to ignore whether you see FSX output, and
>> focus on XRDY. If you have:
>>
>> -continuous external CLKX
>> -FSXM=1
>> -FSGM=0
>> -poll XRDY and it's 1
>> -write a word to DXR
>>
>> then it has to be the case you get a DXR-to-XSR transfer, and see XRDY go
>> back 1 again.
>>
>> How fast is CLKX and what is your transmit word width? How long are you
>> waiting to poll XRDY again? Are you waiting
>> at least the time for one transmit word to be shifted out? There is a note
>> about this in the C6x McBSP reference
>> guide (pg 14).
>>
>> -Jeff
>>
>> > Yes I have been using (Pin # 2) Encoder Shift Clock of HI-15530 as
>> external
>> > clock.
>> > I have configured CLKX of McBSP as an input and this CLKX is driven by
>> > Encoder Shift Clock.
>> >
>> > I want to clarify some things. I have not been using send data signal for
>> > FSX. I have configured FSX as a output and FSX will be generated when
>> whole
>> > data will be shifted from DXR to XSR.
>> >
>> > When FSX will be generated this will drive Encoder Enable (Pin # 19) of
>> > HI-15530. After generation of FSX, Data coming on DX pin of McBSP will be
>> > shifted to Serial Data in (Pin # 18) of HI-15530 on Encoder Shift Clock
>> > rate.
>> >
>> > Question--is the transmit shift clock being produced by the HI-15530 when
>> > the encoder enable line is set 'active' by the McBSP?
>> >
>> > Ans: Encoder Shift Clock is already enabled and there is no need for the
>> > clock to enable.
>> > Encoder Shift Clock is continuous and driving CLKX pin of McBSP. I have
>> > checked all clock signals (Encoder Shift Clock, Decoder Shift Clock,
>> Encoder
>> > Clock, Decoder Clock and Send Clock) on Logic Analyzer. All signals are
>> > fine.
>> >
>> > Question--when the transmit shift clock and the send data signal, being
>> > produced by the HI-15530, are 'active', are the data bits being shifted
>> out
>> > by the McBSP?
>> >
>> > Ans: Encoder Shift Clock is driving the CLKX of McBSP. Send Data signal
>> will
>> > only be generated when Encoder will be enable by applying FSX signal on
>> > Encoder Enable pin of HI-15530. There is no use of Send Data signal. It
>> is
>> > only for checking of Encoder Whether it is working or not.
>> >
>> >
>> > Question--is the 'send clock' running at twice the speed of the encoder
>> > shift clock?
>> >
>> > Ans: Yes Send Clock is running at twice the speed of encoder shift clock.
>> >
>> > Do you get my points.
>> >
>> > I think the problem is somewhere in Clock. What do you think.
>> >
>> > Please help me.
>> >
>> >
>> > Regards,
>> >
>> > Shahzad Ahmed
>> >
>> > On Thu, Dec 31, 2009 at 10:59 PM, Richard Williams
>> > wrote:
>> >
>> >> shahzad,
>> >>
>> >> do you have the data sheet for the HI-15530?
>> >> It can be found by going to:
>> >>
>> >> and clicking the .pdf link near the bottom of the page.
>> >>
>> >> ===================> If I understand you correctly, you are trying to
>> use the clock input to the
>> >> McBSP on pin CLKX as the 'external' clock.
>> >>
>> >> I suspect the problem is the McBSP is not correctly initialized to
>> produce
>> >> the FSX signal during the whole transmission sequence or not clocking
>> the
>> >> data on the correct edge of the incoming clock signal or not starting
>> the
>> >> clocking of the data bits when the 'data send' signal is asserted?
>> >>
>> >>
>> >> Your description of the problem seems to be missing certain key
>> elements.
>> >>
>> >> a logic analyzer (or possibly a dual trace oscilloscope) will answer the
>> >> following questions.
>> >> --is the transmit shift clock being produced by the HI-15530 when the
>> >> encoder enable line is set 'active' by the McBSP?
>> >>
>> >> --when the transmit shift clock and the send data signal, being produced
>> by
>> >> the HI-15530, are 'active', are the data bits being shifted out by the
>> >> McBSP?
>> >>
>> >> --When the data bits are being shifted out, are the state transitions at
>> >> the correct relationship to the transmit shift clock, such that the data
>> bit
>> >> is set/transitions at the falling edge of the transmit shift clock?
>> >>
>> >> --are the data bits being shifted out, beginning when the 'send data'
>> >> signal is asserted by the HI-15530?
>> >>
>> >> --is the 'send clock' running at twice the speed of the encoder shift
>> >> clock?
>> >>
>> >>
>> >> R. Williams
>> >>
>> >>
>> >> *---------- Original Message -----------*
>> >> From: shahzad ahmed
>> >> To: c...
>> >> Sent: Thu, 31 Dec 2009 11:39:19 +0500
>> >> Subject: [c6x] TMS320C6713 MCBSP with external clock
>> >>
>> >> >
>> >> >
>> >> > Actually i have been interfacing MCBSP with HI-15530 IC (Manchester
>> >> encoder and decoder).
>> >> >
>> >> > You can refer application note on following link for further details.
>> >> >
>> >> > http://www.holtic.com/AppNotes/AN-510_A.pdf
>> >> >
>> >> > I have interfaced MCBSP with HI-15530 as follows.
>> >> >
>> >> > MCBSP------------HI-15530
>> >> >
>> >> > CLKX (Input) <--------------------------------Encoder Shift Clock (Pin
>> >> number 2)
>> >> >
>> >> > FSX (DXR2XSR) -------------------------------> Encoder Enable (Pin
>> number
>> >> 19)
>> >> >
>> >> > DX -----------> Serial Data In
>> (Pin
>> >> number 18)
>> >> >
>> >> > CLKR <-------- Decoder Shift Clock
>> >> (Pin number 9)
>> >> >
>> >> > FSR <------------ Take Data (Pin
>> >> number 3)
>> >> >
>> >> > DR <--------------Serial Data Out
>> >> (Pin number 4)
>> >> >
>> >> > I have been using software polling loop for sending data at DXR. as i
>> >> already told you the transmitter works fine with internal clock but it
>> did
>> >> not work for external clock.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Shahzad Ahmed
>> >> >
>> >> > On Thu, Dec 31, 2009 at 10:57 AM, Jeff Brower >> >wrote:
>> >> >
>> >>>
>> >>> Shahzad Ahmed-
>> >>> >
>> >>> > > I have major concern with transmitter test.
>> >>> > >
>> >>> > > Very amazing that when i used following settings.
>> >>> > >
>> >>> > > CLKSM = INTERNAL (Internal CPU/2 Clock)
>> >>> > > CLKXM = OUTPUT (generated by sample rate generator)
>> >>> > > CLKGDV = (0-255)
>> >>> > > FSGM = DXR2XSR
>> >>> > >
>> >>> > > Transmitter works fine.
>> >>> > >
>> >>> > > But when i used following setting.
>> >>> > >
>> >>> > >
>> >>> > > CLKSM = INTERNAL or CLKS (Dont care)
>> >>> > > CLKXM = INPUT (External clock)
>> >>> > > FSGM = DXR2XSR
>> >>> > >
>> >>> > > It does not work.
>> >>> >
>> >>> > How are you sending data to DXR? Do you have a software polling
>> loop?
>> >>> >
>> >>> > By the way, can you answer my previous questions? It's hard for me
>> to
>> >>> figure out what you're doing and what is the
>> >>> > objective, and I don't want to spend time guessing, which is why I
>> ask.
>> >>> If not then possibly someone else can help
>> >>> > you.
>> >>> >
>> >>> > -Jeff
>> >>> >
>> >>> >
>> >>> > > On Wed, Dec 30, 2009 at 11:29 PM, Jeff Brower <
>> j...@signalogic.com>wrote:
>> >>>
>> >>> > >
>> >>> > >> Shahzad-
>> >>> > >>
>> >>> > >> > I want to use MCBSP with external clock source. I configured
>> >>> > >> > CLKX and CLKR as inputs. FSX is configured to generate frame
>> sync
>> >>> > >> > on every DXR2XSR transfer. FSR is driven by external frame sync
>> >>> signal.
>> >>> > >> >
>> >>> > >> > The data is not transferred to XSR from DXR so Frame Sync has
>> not
>> >>> been
>> >>> > >> > generated.
>> >>> > >>
>> >>> > > > actually XRDY is zero and didn't get one but XEMPTY bit is
>> >>> > > > one when I reset and set again the XRST with code composer,
>> one
>> >>> word
>> >>> > > > transmitted and again it stoped.
>> >>> > > >
>> >>> > > > what is the reason? kindly help me.
>> >>> > >
>> >>> > >>
>> >>> > >> Something does not make sense here. If you have external CLKR and
>> >>> FSR,
>> >>> > >> then you
>> >>> > >> should receive data in DRR, without doubt. First, does that
>> happen?
>> >>> If
>> >>> > >> so, is
>> >>> > >> received data formatted as you expect (number of bytes per frame,
>> msb
>> >>>
>> >>> > >> ordering, etc)?
>> >>> > >>
>> >>> > >> Second, there is no connection between receiving and transmitting
>> >>> unless
>> >>> > >> you "do
>> >>> > >> something" in software or with DMA, for example take data received
>> in
>> >>> DRR
>> >>> > >> and send to
>> >>> > >> DXR. Are you doing that?
>> >>> > >>
>> >>> > >> My suggestion is to separate carefully your receive and transmit
>> >>> tests,
>> >>> > >> start with
>> >>> > >> receiving, and then re-post again and clearly state the *first
>> thing*
>> >>> that
>> >>> > >> you find
>> >>> > >> wrong.
>> >>> > >>
>> >>> > >> -Jeff

_____________________________________