Reply by Richard Williams●January 2, 20102010-01-02
shahzad,
The following excerpt from the data sheet of the 6713 may be of primary
importance (from page 135)
" FSRP = FSXP = 1. As a SPI master, FSX is inverted to provide active-low
slave-enable output. As a slave, the active-low signal input on FSX
and FSR is inverted before being used internally.
CLKXM = FSXM = 1, CLKRM = FSRM = 0 for master McBSP
CLKXM = CLKRM = FSXM = FSRM = 0 for slave McBSP
# FSX should be low before the rising edge of clock to enable slave devices and
then begin a SPI transfer at the rising edge of the master clock
(CLKX)."
This means the voltage from the FSX pin will be low, as you measured it, during
a data transfer.
To me, this seems to be out of step with what you want for activation of the
HI-15530 encoder operation.
R. Williams
---------- Original Message -----------
From: shahzad ahmed
To: Richard Williams
Cc: c..., Jeff Brower
Sent: Fri, 1 Jan 2010 12:55:11 +0500
Subject: Re: [c6x] TMS320C6713 MCBSP with external clock
>
>
> 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.
>
>
Reply by Richard Williams●January 2, 20102010-01-02
a small oops,
" Otherwise another communication sequence will not be initiated. "
Keeping the encoder enable signal high immediately starts another communication
sequence.
Sorry for the mis-statement.
R. Williams
---------- Original Message -----------
From: "Jeff Brower"
To: "Shahzad Ahmed"
Cc: "Richard Williams" , c...
Sent: Fri, 1 Jan 2010 15:35:29 -0600 (CST)
Subject: Re: [c6x] TMS320C6713 MCBSP with external clock
> Shahzad-
>
> > 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.
>
> Suggest to follow Richard's advice.
>
> I would add one idea: temporarily insert a 100 Ohm series R on FSX and see if
the signal is still low on the C6713
> side. In that way, you can isolate any possible output contention from the
HI-15530, and make sure it's not affecting
> the signal in some way.
>
> -Jeff
>
> > 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 -------
Reply by Jeff Brower●January 1, 20102010-01-01
Shahzad-
> 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.
Suggest to follow Richard's advice.
I would add one idea: temporarily insert a 100 Ohm series R on FSX and see if
the signal is still low on the C6713
side. In that way, you can isolate any possible output contention from the
HI-15530, and make sure it's not affecting
the signal in some way.
-Jeff
> 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
_____________________________________
Reply by Jeff Brower●January 1, 20102010-01-01
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
_____________________________________
Reply by shahzad ahmed●January 1, 20102010-01-01
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 -------*
>
Reply by shahzad ahmed●January 1, 20102010-01-01
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
Reply by Richard Williams●January 1, 20102010-01-01
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 -------
Reply by Richard Williams●January 1, 20102010-01-01
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 -------
Reply by Jeff Brower●December 31, 20092009-12-31
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
_____________________________________
Reply by Jeff Brower●December 31, 20092009-12-31
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