Re: SCC UART stalling/hanging - progress

On Thu, 2004-10-21 at 11:49, Dan Malek wrote:

On Oct 21, 2004, at 11:15 AM, Jeff Angielski wrote:

quoted

No flow control.  8N1 at 230kbps on SCC2 in UART mode.

WTF?  Does it work at other baud rates, like 115200?

I have seen the SCC stall with 57600 and 115200 as well, but not as
often.  I have not test anything slower than that.

If you just transmit out the port and watch on an o'scope
or something, does it keep running?  

The data on the tx/rx lines on the scope go idle at the same time the
software thinks the SCCs have gone idle.

When it fails, how long does it usually run?

Unfortunately I have not discovered any pattern to the madness. 
Sometimes it works fine for MBs of data and sometimes it stalls after
only 30k bytes worth of data.  The only thing of note is that it seems
to happen more often with the faster baud rate.

Jeff Angielski

When testing with 57600, the stall was slightly different.  I did not
see a problem with the TX_WAKEUP, rather something was inconsistent with
the SCC itself.  The "Tx interrupt buffer pointer" in the SCC parameter
ram was outside the range of valid buffer addresses.

There are 4 buffers starting at: 0x00194284, 0x001942a4, 0x001842c4, and
0x001842e4.  The "Tx interrupt buffer pointer" was 0x00194304 which is 1
byte passed the end of the last buffer.  The TBPTR was ok, just the
interrupt buffer pointer was "bad".

Is this a bug in the hardware or does the Tx internal pointer get
wrapped at some other time?

FWIW, here is the dump of the parameter ram at that point in time:

SCC parameter ram:
==================
bdi2000>md 0xf0008100
f0008100 : 01100130 30300020 30001000 0019425e  ...000. 0.....B^
f0008110 : 01280006 e50679e3 30000000 00194304  .(....y.0.....C.
                                      ^^^^^^^^ <- "Tx internal buf ptr"
f0008120 : 01300000 0000f2fd 8c1e5e6f f4b7b9ca  .0........^o....
           ^^^^^^^^ <- TBPTR
f0008130 : 1a744c5d 9f2da4bd 00200000 00010000  .tL].-... ......
f0008140 : 00000000 00001bfd 00000000 7ea50000  ............~...
f0008150 : 80008000 80008000 80008000 80008000  ................
f0008160 : c0ff726f b6ca6434 59a7fd75 bb0efefd  ..ro..d4Y..u....
 
SCC RX BDs:
==========
f0000110 : 91000020 00194204 91000020 00194224  ... ..B.... ..B$
f0000120 : 9100001a 00194244 b1000020 00194264  ......BD... ..Bd

SCC TX BDs:
==========
f0000130 : 10000020 00194284 10000020 001942a4  ... ..B.... ..B.
f0000140 : 10000020 001942c4 30000020 001942e4  ... ..B.0.. ..B.


TIA,
Jeff

On Oct 21, 2004, at 3:12 PM, Jeff Angielski wrote:

..... The "Tx interrupt buffer pointer" in the SCC parameter
ram was outside the range of valid buffer addresses.

That's not exactly outside of the range.  It is just one byte past
the end of the last buffer, which will get reset when it reads
the first BD.  Don't confuse yourself by looking at that internal
data.  Without knowledge of the microcode, it can be misleading :-)

There are 4 buffers starting at: 0x00194284, 0x001942a4, 0x001842c4, 
and
0x001842e4.

I hope these are typos.  The last two should be 0x001942c4, and
0x001942e4.  If they aren't, something is really broken.


	-- Dan

On Thu, 2004-10-21 at 16:09, Dan Malek wrote:

On Oct 21, 2004, at 3:12 PM, Jeff Angielski wrote:

quoted

..... The "Tx interrupt buffer pointer" in the SCC parameter
ram was outside the range of valid buffer addresses.

That's not exactly outside of the range.  It is just one byte past
the end of the last buffer, which will get reset when it reads
the first BD.  Don't confuse yourself by looking at that internal
data.  Without knowledge of the microcode, it can be misleading :-)

Ok.  I thought that might be the case since the manuals say they are to
only be used for debugging.

quoted

There are 4 buffers starting at: 0x00194284, 0x001942a4, 0x001842c4, 
and
0x001842e4.

I hope these are typos.  The last two should be 0x001942c4, and
0x001942e4.  If they aren't, something is really broken.

They are typos - I have been staring at too many hex values lately.  

From the mem dump you can see the correct values.

Jeff