> >
> > On a positive note, I find that often just the act of writing up my
>  question
> > and posting to comp.dsp helps solve the problem.  It forces me to
>  thoroughly
> > go through everything again, and that often finds the mistake.  In this
> > case, I found the problem just a few minutes after posting!
> 
> In some situations, I encounter something proprietary enough that I can't
> post here. In such cases, I ask someone to listen to my woes (even if I feel
> they don't have the knowledge to solve my problem) and in just talking
> through it and trying to explain the problem, I discover something I
> overlooked.
> Amazing how the human brain works eh?

I've experienced the same situations as you, where just expressing
what the problem seems to be helps you find the answer by yourself,
'cause it makes you reorganize the situation in your brain again.

The funny situation in my case is that often times the person to whom
I express what the problem is, is my mother!!!! And as you might
think, she knows nothing about DSP, chips, electronics, etc. But she
has learned a lot!!! And me too.

Regards,

JaaC

> 
> Cheers
> Bhaskar
>

"Bhaskar Thiagarajan" <bhaskart@deja.com> wrote in message
news:c2b6ao$1qhsm6$1@ID-82263.news.uni-berlin.de...
>
> In some situations, I encounter something proprietary enough that I can't
> post here. In such cases, I ask someone to listen to my woes (even if I
feel
> they don't have the knowledge to solve my problem) and in just talking
> through it and trying to explain the problem, I discover something I
> overlooked.
> Amazing how the human brain works eh?
>
> Cheers
> Bhaskar

Yes, I have many times had the experience of starting to ask someone for
help and half way through explaining the problem, discovering the answer.
The mere act of verbalizing it can be very helpful.

"Jon Harris" <goldentully@hotmail.com> wrote in message
news:c2aopc$1rs3cp$1@ID-210375.news.uni-berlin.de...
> Solved the problem.  Turns out I had my serial ports backwards, so I was
> always sending a frame sync, even when I thought I wasn't.  Further
> confusion was added since because of the BGA parts on the board--since you
> can't directly probe the pins, you rely on test-points, which adds one
more
> level of indirection and possibility for error.
>
> On a positive note, I find that often just the act of writing up my
question
> and posting to comp.dsp helps solve the problem.  It forces me to
thoroughly
> go through everything again, and that often finds the mistake.  In this
> case, I found the problem just a few minutes after posting!

In some situations, I encounter something proprietary enough that I can't
post here. In such cases, I ask someone to listen to my woes (even if I feel
they don't have the knowledge to solve my problem) and in just talking
through it and trying to explain the problem, I discover something I
overlooked.
Amazing how the human brain works eh?

Cheers
Bhaskar

>
> "Jon Harris" <goldentully@hotmail.com> wrote in message
> news:c2akt3$1qtoa4$1@ID-210375.news.uni-berlin.de...
> > I am having problems with SHARC 21161 transmit serial port starting too
> > early with external frame sync.  On my board, an external device
supplies
> a
> > frame sync signal to the DSP.  The DSP is supposed to wait until it
> receives
> > the frame sync before starting the serial transfer.  In this way, the
> > external device can drive the transfer.
> >
> > However, I see on the oscilloscope that the SHARC starts the serial port
> > transfer as soon as I enable its serial port rather than waiting for the
> > frame sync.  There is a bit to tell the SHARC that it must wait for the
> > external frame sync, which of course I am setting.  But it still jumps
the
> > gun.  Even when I hold frame sync permanently low, it still transfers
> data!
> >
> > Any ideas?  Has anyone else used this mode before?  I checked the
anomaly
> > list but didn't find anything on this.
> >
> > The value I am writing to the SCTL1 register is 0x0204B1F1, e.g.:
> >  r0 = 0x0204B1F1;  !transmit DMA enable on A, external frame sync and
bit
> > clock
> >  dm(SPCTL1) = r0;
> >
> > I have also tried several other combinations of settings with no change.
> I
> > just can't seem to make that SHARC wait for the frame sync!
> >
> > -Jon
> >
> >
> >
>
>

Solved the problem.  Turns out I had my serial ports backwards, so I was
always sending a frame sync, even when I thought I wasn't.  Further
confusion was added since because of the BGA parts on the board--since you
can't directly probe the pins, you rely on test-points, which adds one more
level of indirection and possibility for error.

On a positive note, I find that often just the act of writing up my question
and posting to comp.dsp helps solve the problem.  It forces me to thoroughly
go through everything again, and that often finds the mistake.  In this
case, I found the problem just a few minutes after posting!

"Jon Harris" <goldentully@hotmail.com> wrote in message
news:c2akt3$1qtoa4$1@ID-210375.news.uni-berlin.de...
> I am having problems with SHARC 21161 transmit serial port starting too
> early with external frame sync.  On my board, an external device supplies
a
> frame sync signal to the DSP.  The DSP is supposed to wait until it
receives
> the frame sync before starting the serial transfer.  In this way, the
> external device can drive the transfer.
>
> However, I see on the oscilloscope that the SHARC starts the serial port
> transfer as soon as I enable its serial port rather than waiting for the
> frame sync.  There is a bit to tell the SHARC that it must wait for the
> external frame sync, which of course I am setting.  But it still jumps the
> gun.  Even when I hold frame sync permanently low, it still transfers
data!
>
> Any ideas?  Has anyone else used this mode before?  I checked the anomaly
> list but didn't find anything on this.
>
> The value I am writing to the SCTL1 register is 0x0204B1F1, e.g.:
>  r0 = 0x0204B1F1;  !transmit DMA enable on A, external frame sync and bit
> clock
>  dm(SPCTL1) = r0;
>
> I have also tried several other combinations of settings with no change.
I
> just can't seem to make that SHARC wait for the frame sync!
>
> -Jon
>
>
>

I am having problems with SHARC 21161 transmit serial port starting too
early with external frame sync.  On my board, an external device supplies a
frame sync signal to the DSP.  The DSP is supposed to wait until it receives
the frame sync before starting the serial transfer.  In this way, the
external device can drive the transfer.

However, I see on the oscilloscope that the SHARC starts the serial port
transfer as soon as I enable its serial port rather than waiting for the
frame sync.  There is a bit to tell the SHARC that it must wait for the
external frame sync, which of course I am setting.  But it still jumps the
gun.  Even when I hold frame sync permanently low, it still transfers data!

Any ideas?  Has anyone else used this mode before?  I checked the anomaly
list but didn't find anything on this.

The value I am writing to the SCTL1 register is 0x0204B1F1, e.g.:
 r0 = 0x0204B1F1;  !transmit DMA enable on A, external frame sync and bit
clock
 dm(SPCTL1) = r0;

I have also tried several other combinations of settings with no change.  I
just can't seem to make that SHARC wait for the frame sync!

-Jon