UCC UART

[Gary Thomas]

On 06/22/2010 01:01 PM, Chuck Meade wrote:
>>> What BRGs did you choose for tx and rx?
>>
>> BRG1&  BRG2
>
> OK
>
>>> 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.

The driver claims to work with either bus-frequency or brg-frequency set.
I only had bus-frequency; when I set brg-frequency, it has started to work.
Now to test it with a scope to see what else is wrong...

BTW, I use RedBoot - being the original author, how could I not?

Thanks for the help

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------