Thread (13 messages) 13 messages, 3 authors, 2010-06-22

Re: UCC UART

From: Chuck Meade <hidden>
Date: 2010-06-22 19:01:47

quoted
What BRGs did you choose for tx and rx?
BRG1 & BRG2
OK
quoted
Get a scope on the UCC3 tx pin and try to output some chars.  See if
there is
any digital activity on that pin at all.  If you are looking at a
terminal for
output, there are too many things that could be wrong between that tx
pin and
your display (e.g. level translation issue, null modem issue, baud
incompatibility,
terminal program set for XON/XOFF or HW flow control and UART not set
up compatibly).

For now get the probe directly on the CPU's UCC3 Tx pin, output chars
and see
if there is any activity.
We've done all this - nothing on the pins directly at the CPU.

This is behaving very much like there is no clock to the device.
Is there something special that needs to be done to get the BRGs
to work?
If I was doing this, at this point I would do some strategic printk debugging
within ucc_uart.c.  You said that you are using 2.6.33.3, so you already have
all the fixes in ucc_slow.c that I had to backport to my older kernel.

If you question the setup of the BRGs, go to your function that sets them up.
I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in
qe.c.  At the very bottom there is an out_be32().
printk both the address, and the value that is being written to that address.
You may need to cast the values to unsigned longs to printk them.  I will look
at your numbers if you send them to me.  In my implemenation (which again was
a backport, so this may not apply to you) the BRG writes were off by 4 bytes.
But I think that this error was due to the backport -- a logic mismatch I
needed to resolve during the port.

Also in the current Linux kernel, there is a dependence on the correctness
of the "brg-frequency" property from the dts.  Look up above qe_setbrg() at
the qe_get_brg_clk() function.  Before the return (there are multiple return
points) printk the brg_clk being returned.  That must be correct for your
hardware -- must be the actual brg freq.  I assume that you are booting from
U-Boot.  I believe in modern implementations that U-Boot fills in the
brg-frequency in the device tree at boot time.

Let me know how it goes,
Chuck Meade
chuck@ThePTRGroup.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help