Loopback at McBSP in 6711

Hi Mike,
    
Sorry for the delay, the person who used to test this was indisposed
till yesterday, so I just tested this today.

As you suggested I tried the following things:

1. Tried clkgdv! & Divisor=1, here corruption increases.

2. Sent 1 extra stop bit(i.e. 2+1) with the same setup i.e clkgdvc &
Divisor=3. But still see the corrupted bits.

3. Sent 10 stop bits, set the CLKGDV of McBsp as 41 & the Duart
Divisor as 2. This also doesn't make any difference. In fact the
corruption increased a little. 

4. Also sent values from -32768 to +32767 (range of a short
int)incremented by 1, for the 3rd & 4th bytes. Here too we get wrong
values sometimes. Here there's one value that comes in corrupted
sometimes.

5. When a fixed pattern was sent for the 3rd & 4th bytes i.e. 0x22 &
0x22, it works & we don't get any corrupted bits. It shows a smooth
straight line.
 
Thank you for your help. Please suggest how I can fix this.
	dipak.
	--- In c6x@c6x@..., Mike Dunn <mike-dunn@...> wrote:
>
> Dipak,
> 
> --- dipakonline2 <dipakonline2@...> wrote:
> 
> > Hi Mike
> > 	Thanks for the help.
> > Here are the inputs to your queries.
> > 
> > We have set the CLKGDV of McBsp as 63
> > & the Duart Divisor is 3 to get a baud rate of 76800
> > bytes/sec.
> Can you try 21 and 1 as divisors?? If this helps, it
> might indicate that the combination of 'rs232 driver
> chip/cable length/cable capacitance/rs232 receiver
> chip/data rate' will not work. -OR- The transmitter
> cannot service the data rate.
> 
> As an experiment you may want to try sending several
> [10?] stop bits.  Stop bits have no effect except to
> establish 'minimum spacing' between messages. If this
> works, it would indicate that the receiver cannot
> service the data rate
> > 
> > We are using 1 McBsp frame = 1 DUART bit technique.
> > 
> > We are basically sending 3 short integers(6 bytes)
> > from McBsp.
> > We are also adding 1 start bit & 2 stop bits to
> > every frame so for
> > every byte the frame length is 
> > 8bits+1stop bit+2startbits = 11bits 
> I assume that you mean 1 Start + 2 stop bits.
> 
> > & after this, for each bit we send one byte/frame 
> > i.e. 0xFFFF or 0x0000 
> > (using 1 McBsp frame = 1 DUART bit technique.)
> > 
> > So we send 6*11= 66 bytes/msec OR 66000bytes/sec.
> > 
> > On the data recovery end we DMA the values from 
> > the DUART into a buffer.
> > Here, we always get the 1st two & the 
> > last two bytes correctly & the corruption, whenever
> > it occurs,
> > is always in the middle(3rd & 4th ) bytes. These
> > corruptions occur
> > sometimes, have no set pattern nor fixed time
> > interval.
> You will probably locate the problem with one of the
> above techniques.  If not, you may want to try the
> following test.
> Set up a test to send all 1's for each of the 6 bytes.
>  With a fixed and known pattern, the Rx data pattern
> [corrupted] may give a clue as to what is going on.
> 
> Let us know what happens.
> 
> mikedunn
> > 
> > Dipak
> > 
> > PS:
> > Link of the RS232 cable that we'r using(incase its
> > of any help)
>
	

Hello Dipak,

I apologize.
I must have been "inverted" when I made the
suggestions :-)

I should have said to increase the divisors [X3 or X4]
to slow down the data rate - I am not sure what i was
thinking...

sorry 'bout that.

mikedunn

--- dipakonline2 <dipakonline2@dipa...> wrote:

> Hi Mike,
>     
> Sorry for the delay, the person who used to test
> this was indisposed
> till yesterday, so I just tested this today.
> 
> As you suggested I tried the following things:
> 
> 1. Tried clkgdv! & Divisor=1, here corruption
> increases.
> 
> 2. Sent 1 extra stop bit(i.e. 2+1) with the same
> setup i.e clkgdvc &
> Divisor=3. But still see the corrupted bits.
> 
> 3. Sent 10 stop bits, set the CLKGDV of McBsp as 41
> & the Duart
> Divisor as 2. This also doesn't make any difference.
> In fact the
> corruption increased a little. 
> 
> 4. Also sent values from -32768 to +32767 (range of
> a short
> int)incremented by 1, for the 3rd & 4th bytes. Here
> too we get wrong
> values sometimes. Here there's one value that comes
> in corrupted
> sometimes.
> 
> 5. When a fixed pattern was sent for the 3rd & 4th
> bytes i.e. 0x22 &
> 0x22, it works & we don't get any corrupted bits. It
> shows a smooth
> straight line.
>  
> Thank you for your help. Please suggest how I can
> fix this.
>  
> 
> dipak.
> 
> 
> 
> 
> --- In c6x@c6x@..., Mike Dunn
> <mike-dunn@...> wrote:
> >
> > Dipak,
> > 
> > --- dipakonline2 <dipakonline2@...> wrote:
> > 
> > > Hi Mike
> > > 	Thanks for the help.
> > > Here are the inputs to your queries.
> > > 
> > > We have set the CLKGDV of McBsp as 63
> > > & the Duart Divisor is 3 to get a baud rate of
> 76800
> > > bytes/sec.
> > Can you try 21 and 1 as divisors?? If this helps,
> it
> > might indicate that the combination of 'rs232
> driver
> > chip/cable length/cable capacitance/rs232 receiver
> > chip/data rate' will not work. -OR- The
> transmitter
> > cannot service the data rate.
> > 
> > As an experiment you may want to try sending
> several
> > [10?] stop bits.  Stop bits have no effect except
> to
> > establish 'minimum spacing' between messages. If
> this
> > works, it would indicate that the receiver cannot
> > service the data rate
> > > 
> > > We are using 1 McBsp frame = 1 DUART bit
> technique.
> > > 
> > > We are basically sending 3 short integers(6
> bytes)
> > > from McBsp.
> > > We are also adding 1 start bit & 2 stop bits to
> > > every frame so for
> > > every byte the frame length is 
> > > 8bits+1stop bit+2startbits = 11bits 
> > I assume that you mean 1 Start + 2 stop bits.
> > 
> > > & after this, for each bit we send one
> byte/frame 
> > > i.e. 0xFFFF or 0x0000 
> > > (using 1 McBsp frame = 1 DUART bit technique.)
> > > 
> > > So we send 6*11= 66 bytes/msec OR
> 66000bytes/sec.
> > > 
> > > On the data recovery end we DMA the values from 
> > > the DUART into a buffer.
> > > Here, we always get the 1st two & the 
> > > last two bytes correctly & the corruption,
> whenever
> > > it occurs,
> > > is always in the middle(3rd & 4th ) bytes. These
> > > corruptions occur
> > > sometimes, have no set pattern nor fixed time
> > > interval.
> > You will probably locate the problem with one of
> the
> > above techniques.  If not, you may want to try the
> > following test.
> > Set up a test to send all 1's for each of the 6
> bytes.
> >  With a fixed and known pattern, the Rx data
> pattern
> > [corrupted] may give a clue as to what is going
> on.
> > 
> > Let us know what happens.
> > 
> > mikedunn
> > > 
> > > Dipak
> > > 
> > > PS:
> > > Link of the RS232 cable that we'r using(incase
> its
> > > of any help)
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     c6x-unsubscribe@c6x-...
> 
>  
> 
> 
> 
>
	

Hello Mike,

Thanks for your help.
We tried sending data at a slower rate i.e. clkgdv = 80
& divisor = 4 making the baud rate 57.6K but the corruption
still occurs. 

Any other reason that could be causing these corrupted bits
of data.

dipak.

--- In c6x@c6x@..., Mike Dunn <mike-dunn@...> wrote:
>
> Hello Dipak,
> 
> I apologize.
> I must have been "inverted" when I made the
> suggestions :-)
> 
> I should have said to increase the divisors [X3 or X4]
> to slow down the data rate - I am not sure what i was
> thinking...
> 
> sorry 'bout that.
> 
> mikedunn
> 
> --- dipakonline2 <dipakonline2@...> wrote:
> 
> > Hi Mike,
> >     
> > Sorry for the delay, the person who used to test
> > this was indisposed
> > till yesterday, so I just tested this today.
> > 
> > As you suggested I tried the following things:
> > 
> > 1. Tried clkgdv! & Divisor=1, here corruption
> > increases.
> > 
> > 2. Sent 1 extra stop bit(i.e. 2+1) with the same
> > setup i.e clkgdvc &
> > Divisor=3. But still see the corrupted bits.
> > 
> > 3. Sent 10 stop bits, set the CLKGDV of McBsp as 41
> > & the Duart
> > Divisor as 2. This also doesn't make any difference.
> > In fact the
> > corruption increased a little. 
> > 
> > 4. Also sent values from -32768 to +32767 (range of
> > a short
> > int)incremented by 1, for the 3rd & 4th bytes. Here
> > too we get wrong
> > values sometimes. Here there's one value that comes
> > in corrupted
> > sometimes.
> > 
> > 5. When a fixed pattern was sent for the 3rd & 4th
> > bytes i.e. 0x22 &
> > 0x22, it works & we don't get any corrupted bits. It
> > shows a smooth
> > straight line.
> >  
> > Thank you for your help. Please suggest how I can
> > fix this.
> >  
> > 
> > dipak.
> > 
> > 
> > 
> > 
> > --- In c6x@c6x@..., Mike Dunn
> > <mike-dunn@> wrote:
> > >
> > > Dipak,
> > > 
> > > --- dipakonline2 <dipakonline2@> wrote:
> > > 
> > > > Hi Mike
> > > > 	Thanks for the help.
> > > > Here are the inputs to your queries.
> > > > 
> > > > We have set the CLKGDV of McBsp as 63
> > > > & the Duart Divisor is 3 to get a baud rate of
> > 76800
> > > > bytes/sec.
> > > Can you try 21 and 1 as divisors?? If this helps,
> > it
> > > might indicate that the combination of 'rs232
> > driver
> > > chip/cable length/cable capacitance/rs232 receiver
> > > chip/data rate' will not work. -OR- The
> > transmitter
> > > cannot service the data rate.
> > > 
> > > As an experiment you may want to try sending
> > several
> > > [10?] stop bits.  Stop bits have no effect except
> > to
> > > establish 'minimum spacing' between messages. If
> > this
> > > works, it would indicate that the receiver cannot
> > > service the data rate
> > > > 
> > > > We are using 1 McBsp frame = 1 DUART bit
> > technique.
> > > > 
> > > > We are basically sending 3 short integers(6
> > bytes)
> > > > from McBsp.
> > > > We are also adding 1 start bit & 2 stop bits to
> > > > every frame so for
> > > > every byte the frame length is 
> > > > 8bits+1stop bit+2startbits = 11bits 
> > > I assume that you mean 1 Start + 2 stop bits.
> > > 
> > > > & after this, for each bit we send one
> > byte/frame 
> > > > i.e. 0xFFFF or 0x0000 
> > > > (using 1 McBsp frame = 1 DUART bit technique.)
> > > > 
> > > > So we send 6*11= 66 bytes/msec OR
> > 66000bytes/sec.
> > > > 
> > > > On the data recovery end we DMA the values from 
> > > > the DUART into a buffer.
> > > > Here, we always get the 1st two & the 
> > > > last two bytes correctly & the corruption,
> > whenever
> > > > it occurs,
> > > > is always in the middle(3rd & 4th ) bytes. These
> > > > corruptions occur
> > > > sometimes, have no set pattern nor fixed time
> > > > interval.
> > > You will probably locate the problem with one of
> > the
> > > above techniques.  If not, you may want to try the
> > > following test.
> > > Set up a test to send all 1's for each of the 6
> > bytes.
> > >  With a fixed and known pattern, the Rx data
> > pattern
> > > [corrupted] may give a clue as to what is going
> > on.
> > > 
> > > Let us know what happens.
> > > 
> > > mikedunn
> > > > 
> > > > Dipak
> > > > 
> > > > PS:
> > > > Link of the RS232 cable that we'r using(incase
> > its
> > > > of any help)
> > >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >     c6x-unsubscribe@c6x-...
> > 
> >  
> > 
> > 
> > 
> >
>
	

Hello Dipak,

You can try this...

plan A
1. Set up DSP1 to send a 'test pattern' of 6 bytes -
define the bytes so that each one is an ascii
character. 
2. Replace DSP2 with a PC run a terminal emulator at
the correct baud rate.
3. observe

plan B [a bit more work]
1. Set up DSP2 to receive test pattern
2. replace DSP1 with a PC running a program to output
a continuous 6 byte test pattern.
3. observe

The results might give a clue.

mikedunn

--- dipakonline2 <dipakonline2@dipa...> wrote:

> Hello Mike,
> 
> Thanks for your help.
> We tried sending data at a slower rate i.e. clkgdv > 80
> & divisor = 4 making the baud rate 57.6K but the
> corruption
> still occurs. 
> 
> Any other reason that could be causing these
> corrupted bits
> of data.
> 
> dipak.
> 
> --- In c6x@c6x@..., Mike Dunn
> <mike-dunn@...> wrote:
> >
> > Hello Dipak,
> > 
> > I apologize.
> > I must have been "inverted" when I made the
> > suggestions :-)
> > 
> > I should have said to increase the divisors [X3 or
> X4]
> > to slow down the data rate - I am not sure what i
> was
> > thinking...
> > 
> > sorry 'bout that.
> > 
> > mikedunn
> > 
> > --- dipakonline2 <dipakonline2@...> wrote:
> > 
> > > Hi Mike,
> > >     
> > > Sorry for the delay, the person who used to test
> > > this was indisposed
> > > till yesterday, so I just tested this today.
> > > 
> > > As you suggested I tried the following things:
> > > 
> > > 1. Tried clkgdv! & Divisor=1, here corruption
> > > increases.
> > > 
> > > 2. Sent 1 extra stop bit(i.e. 2+1) with the same
> > > setup i.e clkgdvc &
> > > Divisor=3. But still see the corrupted bits.
> > > 
> > > 3. Sent 10 stop bits, set the CLKGDV of McBsp as
> 41
> > > & the Duart
> > > Divisor as 2. This also doesn't make any
> difference.
> > > In fact the
> > > corruption increased a little. 
> > > 
> > > 4. Also sent values from -32768 to +32767 (range
> of
> > > a short
> > > int)incremented by 1, for the 3rd & 4th bytes.
> Here
> > > too we get wrong
> > > values sometimes. Here there's one value that
> comes
> > > in corrupted
> > > sometimes.
> > > 
> > > 5. When a fixed pattern was sent for the 3rd &
> 4th
> > > bytes i.e. 0x22 &
> > > 0x22, it works & we don't get any corrupted
> bits. It
> > > shows a smooth
> > > straight line.
> > >  
> > > Thank you for your help. Please suggest how I
> can
> > > fix this.
> > >  
> > > 
> > > dipak.
> > > 
> > > 
> > > 
> > > 
> > > --- In c6x@c6x@..., Mike Dunn
> > > <mike-dunn@> wrote:
> > > >
> > > > Dipak,
> > > > 
> > > > --- dipakonline2 <dipakonline2@> wrote:
> > > > 
> > > > > Hi Mike
> > > > > 	Thanks for the help.
> > > > > Here are the inputs to your queries.
> > > > > 
> > > > > We have set the CLKGDV of McBsp as 63
> > > > > & the Duart Divisor is 3 to get a baud rate
> of
> > > 76800
> > > > > bytes/sec.
> > > > Can you try 21 and 1 as divisors?? If this
> helps,
> > > it
> > > > might indicate that the combination of 'rs232
> > > driver
> > > > chip/cable length/cable capacitance/rs232
> receiver
> > > > chip/data rate' will not work. -OR- The
> > > transmitter
> > > > cannot service the data rate.
> > > > 
> > > > As an experiment you may want to try sending
> > > several
> > > > [10?] stop bits.  Stop bits have no effect
> except
> > > to
> > > > establish 'minimum spacing' between messages.
> If
> > > this
> > > > works, it would indicate that the receiver
> cannot
> > > > service the data rate
> > > > > 
> > > > > We are using 1 McBsp frame = 1 DUART bit
> > > technique.
> > > > > 
> > > > > We are basically sending 3 short integers(6
> > > bytes)
> > > > > from McBsp.
> > > > > We are also adding 1 start bit & 2 stop bits
> to
> > > > > every frame so for
> > > > > every byte the frame length is 
> > > > > 8bits+1stop bit+2startbits = 11bits 
> > > > I assume that you mean 1 Start + 2 stop bits.
> > > > 
> > > > > & after this, for each bit we send one
> > > byte/frame 
> > > > > i.e. 0xFFFF or 0x0000 
> > > > > (using 1 McBsp frame = 1 DUART bit
> technique.)
> > > > > 
> > > > > So we send 6*11= 66 bytes/msec OR
> > > 66000bytes/sec.
> > > > > 
> > > > > On the data recovery end we DMA the values
> from 
> > > > > the DUART into a buffer.
> > > > > Here, we always get the 1st two & the 
> > > > > last two bytes correctly & the corruption,
> > > whenever
> > > > > it occurs,
> > > > > is always in the middle(3rd & 4th ) bytes.
> These
> > > > > corruptions occur
> > > > > sometimes, have no set pattern nor fixed
> time
> > > > > interval.
> > > > You will probably locate the problem with one
> of
> > > the
> > > > above techniques.  If not, you may want to try
> the
> > > > following test.
> > > > Set up a test to send all 1's for each of the
> 6
> > > bytes.
> > > >  With a fixed and known pattern, the Rx data
> > > pattern
> > > > [corrupted] may give a clue as to what is
> going
> > > on.
> > > > 
> > > > Let us know what happens.
> > > > 
> > > > mikedunn
> > > > > 
> > > > > Dipak
> > > > > 
> > > > > PS:
> > > > > Link of the RS232 cable that we'r
> using(incase
> > > its
> > > > > of any help)
> > > >
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > NEW!  You can now post a message or access and
> > > search the archives of this group on
> DSPRelated.com:
> > > http://www.dsprelated.com/groups/c6x/1.php
> 
=== message truncated ==